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.
3 « 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.
Je ne suis pas sûr que ce soit intentionnel, mais je voulais le signaler :
Nous sommes sur une version stable obsolète v3.5.4 et utilisions le plugin cakeday. Cependant, les reconstructions (de la même version de Discourse) ont cessé de fonctionner car cakeday avait été fusionné dans le cœur. J’ai donc désactivé le plugin dans le fichier yml et… eh bien, il a disparu. Maintenant, il se reconstruit à nouveau, mais nous n’avons plus de jours de gâteau car l’interface d’administration n’affiche aucun signe que la fonctionnalité soit installée.
Je suppose que c’est parce que nous sommes sur une version stable obsolète, mais c’était tout de même un résultat inattendu pour une reconstruction de la même version de Discourse.
Le plugin cakeday n’est pas inclus dans la version 3.5.4, c’est pourquoi vous ne le voyez plus.
Êtes-vous sûr que c’est la raison pour laquelle elles ont commencé à échouer ? Si vous avez vu quelque chose comme :
HINT: The plugin ‘$plugin’ is now bundled with Discourse and should not be included in your container configuration
(INDICATION : Le plugin ‘$plugin’ est maintenant inclus avec Discourse et ne doit pas être inclus dans votre configuration de conteneur)
Alors je crains que cela ne soit affiché pour toute reconstruction échouée lorsque le plugin cakeday est inclus dans le fichier de configuration. C’était la manière la plus efficace que nous ayons trouvée pour avertir les gens du problème, mais cela peut prêter à confusion pour ceux qui utilisent des versions plus anciennes du cœur.
Donc, si vous avez besoin du plugin cakeday, je pense que vous devriez pouvoir le rajouter à votre fichier app.yml et reconstruire. Je soupçonne que l’échec a été causé par autre chose, que vous avez maintenant résolu.
Par ailleurs : je vous recommanderais fortement de passer à une version supportée. La version 3.5 ne reçoit plus de mises à jour de sécurité et pourrait être vulnérable aux attaques.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Rajouter le plugin à app.yml provoque l’erreur ci-dessus. Le supprimer immédiatement permet à la construction de fonctionner à nouveau. Ce plugin semble être le seul problème.
Je suis conscient que nous utilisons une version obsolète et que sa mise à niveau est prévue. Je voulais juste souligner que, même si nous n’avons pas changé la version que nous utilisons, 3.5.4 passait de la construction réussie (avec le plugin) à ne plus construire avec le plugin, et nous ne semblons avoir aucun moyen de récupérer la fonctionnalité du plugin (via un plugin ou dans le cœur).
Intéressant ! Je me demande si c’est parce que notre image docker inclut maintenant discourse-cakeday, et que lorsque le cœur est « rétrogradé » à la version 3.5, il laisse un répertoire vide derrière lui.
Si vous ajoutez rm -rf discourse-cakeday avant la ligne git clone https://.../discourse-cakeday, cela devrait nettoyer. Cela ressemblerait donc à ceci :
Désolé de dévier légèrement du sujet, mais je ne pense pas qu’il y ait de sujet plus approprié et c’est quelque peu lié au problème précédent.
Depuis mon message précédent, je pense qu’il y a eu d’autres changements effectués sur discourse/docker_manager qui cassent davantage de choses lors des constructions de versions plus anciennes. Après une reconstruction aujourd’hui, toute la section admin de Discourse a cessé de fonctionner avec des erreurs comme celle-ci :
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
J’ai réussi à corriger la construction en utilisant ceci dans le yml :
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
Je ne sais pas quel était le commit fautif, mais cela a suffi pour que cela fonctionne à nouveau.
Je sais, je sais, je dois mettre à jour (je le pense vraiment). Mais il y a probablement d’autres personnes comme nous qui sont bloquées sur des versions plus anciennes plus longtemps que prévu pour une raison ou une autre, et que les anciennes constructions se cassent sans changer la version est un peu inattendu.
Enfin, j’ai déjà trouvé une solution de contournement en attendant la mise à jour, donc je partage ceci au cas où cela serait utile à d’autres dans la même situation.
