Je pense que ce qu’ils suggèrent, c’est que si un plugin déjà inclus dans le cœur était listé dans app.yaml, il serait simplement ignoré. Avec une notification indiquant que l’inclusion dans app.yaml était redondante et que le propriétaire pouvait la supprimer.
Je trouve aussi un peu agaçant que tant que j’ai des plugins listés dans mon app.yaml, je cours toujours le risque d’une mise à jour échouée. Donc, chaque fois que je fais la mise à jour, je dois vérifier si l’un de mes plugins a été ajouté au cœur.
Pourquoi ne pas simplement avoir un script qui le fait pour le Sysop ?
J’organise moi-même les plugins par équipe ou par auteur pour me faciliter la vie, afin de savoir quels plugins sont officiels et ainsi de suite. Mais si l’idée est de rendre Discourse plus convivial, cela doit être fait du côté de l’équipe.
Ce n’est pas vraiment différent lorsque tu conseillais des gens quand un utilisateur a une mise à niveau cassée en raison d’un échec de mise à niveau Postreq (donc ?)
Avec les plugins, c’est exactement là que le concept du Procourse Installer était une excellente idée pour simplifier l’installation et la désinstallation des plugins sans avoir à utiliser la ligne de commande.
Certes, je comprends qu’il aurait peut-être fallu un peu plus de polissage en cas de problème. Mais cela aurait pu être aussi simple avec un fichier journal ou un simple repli si nécessaire depuis la ligne de commande. J’apprécie que cela puisse le rendre plus attrayant pour l’auto-hébergement par rapport à un plan payant. Cependant, il y a suffisamment d’avantages pour un plan payant pour continuer dans cette voie.
Ce type de gestionnaire de plugins pourrait également être conçu ou adapté pour permettre aux plans hébergés d’installer des plugins dans leur niveau hébergé, car certains plugins peuvent ne pas être nécessaires dans le plan spécifique.
En effet, j’avais manqué un message il y a longtemps concernant le chat qui était inclus et j’avais essayé de l’installer. Je ne pense pas que le tag ait été mis à jour sur le plugin. Bien sûr, cela a fait planter le site car il n’a pas aimé qu’on essaie d’installer le plugin alors qu’en théorie, il aurait peut-être pu ignorer l’entrée avec une reconstruction complète indiquant qu’elle était inutile.
Je pense que nous pouvons clore ce sujet maintenant - je vais régler une minuterie pour donner aux collègues une chance de répondre s’ils le souhaitent.
Avec l’initiative récente de regrouper davantage de plugins officiels dans le cœur du système, je me demandais si le plugin Who’s Online était envisagé pour inclusion.
J’ai remarqué qu’il est disponible sur les plans d’hébergement officiels (comptant dans le quota de plugins), je suis donc curieux de savoir si cela indique une évolution vers une adoption plus large.
Je comprends tout à fait si les contraintes de performance ou l’adéquation philosophique signifient qu’il doit rester désactivé par défaut, sauf indication contraire dans app.yml.
Nous ne prévoyons actuellement pas d’intégrer d’autres plugins dans le noyau. Cakeday a été le dernier, et a dû être traité séparément du lot principal en raison de certaines complications liées à la manière dont il était précédemment activé par défaut.
Je comprends tout à fait la frustration concernant le processus ici - ce n’est certainement pas aussi fluide que je le souhaiterais. Pour donner un peu de contexte : le problème fondamental est que les fichiers app.yml ne sont pas des fichiers de configuration Discourse. Ce sont des fichiers de configuration pups, et les lignes d’installation des plugins ne sont que des commandes shell.
Intégrer une logique spécifique à Discourse dans pups, et lui faire ignorer certaines commandes shell, n’est pas vraiment une option. Cet outil n’est pas seulement utilisé pour Discourse. De plus, je soupçonne qu’un certain nombre de personnes seraient mécontentes que nous modifiions les commandes shell exécutées pendant le démarrage sans leur connaissance.
Nous avons donc opté pour la solution la plus propre que nous ayons pu trouver avec les outils disponibles : forcer une reconstruction en ligne de commande, puis afficher un message demandant aux utilisateurs de supprimer la ligne concernée de leur configuration.
Je pense que « installer » pourrait être mieux formulé par « activer » là – si c’est techniquement correct.
La formulation actuelle pourrait donner l’impression que le fait d’avoir des plugins groupés supplémentaires est une préoccupation philosophique ou de performance – alors qu’il s’agit seulement de savoir s’ils sont activés. Étant donné qu’un nouveau plugin principal qui n’était pas activé auparavant est désactivé par défaut après la reconstruction, le risque ne réside pas dans le fait de l’avoir installé avec le cœur, mais dans le fait de l’activer.
Maintenant, ce problème spécifique a été résolu (dans la plupart des cas) pour les plugins groupés, mais cela peut encore se produire ici et là pour d’autres plugins.
Le plugin discourse-categories-suppressed ajoute une interface utilisateur simple et facultative pour masquer des catégories sélectionnées du flux “Latest”. Il s’intègre via une seule liste déroulante dans :
Admin → Paramètres → Catégories
« catégories supprimées de la page d’accueil »
Cela semble être un paramètre de base très naturel — d’autant plus que :
• Il est officiel et activement maintenu
• Il reste désactivé par défaut, sauf si un administrateur l’active
• De nombreuses communautés (y compris la mienne) s’appuient sur « Latest » comme vue d’atterrissage principale et souhaitent un contrôle plus fin sur ce qui y apparaît
L’équipe envisagerait-elle d’intégrer ce plugin (toujours désactivé par défaut), afin que les administrateurs puissent utiliser cette bascule sans avoir besoin d’installer quoi que ce soit de plus ?
Merci de votre considération — cela semble être une préférence d’interface utilisateur mineure dont de nombreux sites bénéficieraient s’ils l’avaient disponible dès le départ.
2 « J'aime »
tobiaseigen
(Tobias Eigen)
A fermé ce sujet ()
162
Ce sujet a été automatiquement fermé après 2 jours. Les nouvelles réponses ne sont plus autorisées.
