À mon avis, je pense que le tag Customization > Theme component servirait mieux son objectif en tant que sous-catégorie. Du moins pour moi, ils sont plus faciles à trouver que les tags, et ces dernières années, les composants de thème sont devenus de plus en plus importants par rapport à leurs équivalents Customization > Plugin (dont beaucoup sont convertis en composants de thème pour une utilisation plus facile). Par manque de meilleur terme, ils méritent un traitement « égal ». Après tout, ils sont extrêmement populaires et constituent désormais une partie intégrante de Discourse.
J’espère que vous en tiendrez compte. Je ne suis pas un locuteur natif de l’anglais, alors désolé pour mon manque de clarté.
Dans un souci de simplicité, je me demanderais s’il ne serait pas judicieux d’aller plus loin en nommant la catégorie personnaliser puis en utilisant ces quatre étiquettes.
Je suis d’accord que les composants de thèmes ont une valeur un peu plus grande pour la plupart des sites Discourse de nos jours.
Je pense que cette formulation va créer de la confusion. Admin → Personnaliser est réservé aux thèmes et aux composants de thème. Customization > Theme regroupe tout ce qui peut être ajouté à un site via cette interface.
On constate déjà occasionnellement des problèmes lorsque des utilisateurs placent des thèmes dans leur fichier YML et tentent d’ajouter des dépôts Git pour les plugins via l’interface. Supprimer cette distinction ne fera qu’augmenter la probabilité de ce type d’erreurs.
Les plugins doivent vraiment rester dans leur propre catégorie, non ?
La différence entre un composant de thème et un plugin est déjà floue dans ma tête. Je suis sûr que tout ce que nous pouvons faire pour faciliter la tâche des gens afin qu’ils sachent distinguer l’un de l’autre sera très utile.
C’est un peu amusant, car pendant longtemps, les développeurs WordPress devaient décider où intégrer leurs fonctionnalités, et des débats avaient lieu sur la quantité de code qui devait appartenir à un « thème » plutôt qu’à un « plugin ». Ce débat semble presque quaint aujourd’hui, où tout et n’importe quoi est un bloc JS, mais en raison de sa relation avec le logiciel de base, nous devons toujours déterminer où placer le code : dans un « plugin » ou dans un « modèle de bloc ».
Je n’ai jamais ressenti cela avec les plugins dans Discourse, principalement parce que les gens ont inventé au fil des ans certaines astuces brillantes avec les composants de thème. Si quelqu’un me demandait quelle est la différence entre « plugins » et « composants de thème », ma première pensée serait : l’un nécessite un champ URL pour l’installation, et l’autre exige une reconstruction du site.
Et elle le sera, car la différence est basée sur la façon d’installer quelque chose. Pas sur le but. C’est un style de développeur de voir le monde qui l’entoure
Juste une note sur le marquage : Il semble plus facile d’oublier de marquer un sujet que d’oublier de choisir la catégorie. Il y a déjà des thèmes non marqués.
Je suis tout à fait partant pour faire un bilan de santé des catégories et des tags. Il y a eu plusieurs bonnes suggestions récemment concernant une légère modification de la structure, donc je vais rassembler tout cela et voir où cela nous mène. Je pense que tout ce qui rend Meta plus intuitif pour les nouveaux venus ou les utilisateurs occasionnels ne peut être qu’une bonne chose.
Cela devrait être moins problématique maintenant qu’il y a un Modérateur Communautaire dédié. () Je pense que le fait que je trie et organise au fur et à mesure devrait couvrir une grande partie de cela. Et nous avons un bon nombre de membres TL3 et TL4, donc j’espère que renforcer une pratique cohérente rendra plus facile pour les autres de participer aussi.
Je continue de le voir comme des modifications Frontend versus Backend, mais la mise à niveau vers Ember a aussi obscurci pour moi ce que cela signifie maintenant. Il semble que cela ait rendu beaucoup plus de choses possibles dans un thème ou un composant de thème qu’auparavant (ce qui est formidable si vous êtes hébergé et n’avez pas un accès facile pour ajouter un plugin ).
Je pense que c’est une distinction assez utile pour les non-développeurs. Rouge = /admin/customize, Jaune = app.yml. Je pense que c’est probablement tout ce dont vous avez vraiment besoin de savoir si vous êtes un administrateur installant une personnalisation existante, plutôt qu’un développeur souhaitant en créer une nouvelle.
Merci pour la suggestion @Decorbuz Je vais rassembler quelques idées et voir ce que nous pouvons faire.
Même question que : les smartphones sont-ils des ordinateurs ou non ? Les frontières ne sont plus aussi nettes.
C’est pourquoi chaque forum doit faire un choix logique sur la façon d’organiser les choses : quelque part, cela doit être par idée ou par utilisation (l’expérience utilisateur et la cible comptent), ou la solution technique est-elle plus importante (pensée basée sur le développement/le code).
Il n’y a pas de bonnes ou de mauvaises solutions, tant que les utilisateurs trouvent ce qu’ils cherchent.
Eh bien, il y a parfois de mauvaises solutions. Mélanger des plugins/thèmes/composants sains avec des éléments défectueux de telle sorte que vous deviez trouver la bonne balise est une très, très mauvaise idée
Et en général, il y a une autre erreur que les administrateurs commettent assez souvent et à propos de laquelle, si je me souviens bien, même le tag-doc ou similaire de Meta met en garde : la catégorie ne génère pas la création de contenu, mais les catégories vides ou à faible trafic rendent simplement les choses désordonnées.
L’absence de clarté ne signifie pas automatiquement qu’il failles les fusionner, en particulier sous le nom suggéré par Justin ci-dessus. Nous pourrions également ajouter des explications plus détaillées à chaque catégorie et résoudre une partie de l’ambiguïté de cette manière.
Les sujets Customization > Plugin nécessitent une reconstruction et ne peuvent être effectués que par des utilisateurs disposant d’un accès root. Il s’agit de modifications à plus haut risque qui affectent la disponibilité du site.
Je pense aussi comme ça. Si cela nécessite une modification du backend (code ruby) que ce soit pour stocker quelque chose dans la base de données ou modifier le comportement d’une API, vous aurez très probablement besoin d’un plugin.
Si le changement concerne uniquement l’interface utilisateur, il est préférable de commencer par un composant de thème et de recourir à un plugin plus tard si les choses s’intensifient, deviennent plus compliquées et que des changements dans le backend s’avèrent nécessaires.
J’aime cette idée. C’est un peu plus compliqué qu’une seule catégorie avec différentes étiquettes, mais j’aime une séparation plus nette entre ces différents éléments de personnalisation.
Un thème peut concerner uniquement l’apparence, tandis qu’un plugin nécessite un accès au système d’exploitation de la machine pour être installé. Ce sont des choses très différentes et des catégories appropriées permettent, par exemple, au premier sujet de la catégorie de fournir un contexte aux nouveaux utilisateurs sur les différences entre eux. Comment installer, documentation de développement, etc.
Je suis sûr que tout ce que nous pouvons faire pour faciliter la tâche des gens afin qu’ils sachent distinguer l’un de l’autre sera très utile.
Je pense que tout ce qui rend Meta plus intuitif pour les nouveaux venus ou les utilisateurs occasionnels ne peut être qu’une bonne chose.
