À mon avis, je pense que le tag Theme component remplirait mieux sa fonction 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 thématiques sont devenus de plus en plus importants par rapport à leurs homologues Plugin (dont beaucoup sont convertis en composants thématiques pour une utilisation plus facile). À défaut d’un meilleur terme, ils méritent… un traitement « égal ». Après tout, ils sont extrêmement populaires et font partie intégrante de Discourse de nos jours.
J’espère que vous en tiendrez compte. Je ne suis pas un locuteur natif de l’anglais, alors désolé pour mon manque d’articulation.
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 ce langage va créer de la confusion. Admin->Customize est uniquement destiné aux thèmes et aux composants de thèmes. Theme contient tout ce qui peut être introduit sur un site via cette interface utilisateur.
Nous constatons déjà des problèmes occasionnels avec des utilisateurs qui placent des thèmes dans leur YML et essaient d’ajouter des dépôts git pour des plugins via l’interface utilisateur. L’élimination de la délimitation rend ces erreurs plus probables.
Les plugins doivent vraiment rester dans leur propre catégorie, n’est-ce pas ?
La différence entre un composant de thème et un plugin est déjà floue dans ma tête. Tout ce que nous pouvons faire pour aider les gens à savoir lequel est lequel fera beaucoup, j’en suis sûr.
C’est un peu drôle, pendant longtemps, les développeurs WordPress ont dû faire un choix quant à l’endroit où inclure les fonctionnalités, et des débats ont eu lieu sur la quantité de code appartenant à un « thème » par rapport à un « plugin ». Ce débat est presque désuet, maintenant, 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ù va le code, dans un « plugin » ou un « bloc pattern ».
Je n’ai jamais eu un tel sentiment avec les plugins dans Discourse, principalement parce que les gens ont trouvé des hacks de composants de thème brillants au fil des ans. 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 prend un champ URL pour l’installation, et l’autre nécessite 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 des catégories et des balises. Il y a eu quelques bonnes suggestions concernant l’amélioration de la structure récemment, donc je vais tout rassembler et voir où nous en sommes. Je pense que tout ce qui rend Meta plus intuitif pour les nouveaux utilisateurs/utilisateurs occasionnels ne peut être que bénéfique.
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 nombre décent de TL3 et TL4, donc j’espère que le renforcement d’un schéma cohérent facilitera la participation des autres également.
Je pense toujours en termes de changements Frontend versus Backend, mais la mise à niveau vers Ember a également brouillé ce que cela signifie pour moi maintenant. Il semble que cela ait rendu beaucoup plus de choses possibles dans un thème/composant de thème qu’auparavant (ce qui est formidable si vous êtes hébergé et que vous n’avez pas un accès facile pour ajouter un plugin ).
Je pense que c’est une distinction très utile pour les non-développeurs. Rouge = /admin/customize, Jaune = app.yml. Je pense que c’est probablement tout ce que 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.
Le manque de clarté ne signifie pas automatiquement qu’ils doivent être fusionnés, en particulier sous le nom suggéré par Justin ci-dessus. Nous pourrions tout aussi bien ajouter de meilleures explications à chaque catégorie et résoudre une partie de l’ambiguïté de cette façon.
Theme et Theme component encapsulent les personnalisations pré-emballées qui peuvent être effectuées à l’exécution.
Les sujets Plugin nécessitent une reconstruction et ne peuvent être effectués que par des utilisateurs ayant un accès root. Ce sont des changements à 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.
Tout ce que nous pouvons faire pour aider les gens à savoir lequel est lequel fera beaucoup, j’en suis sûr.
Je pense que tout ce qui rend Meta plus intuitif pour les nouveaux utilisateurs/utilisateurs occasionnels ne peut être que bénéfique.
