Je ne pense pas que cela soit possible en raison de la manière dont les plugins sont intégrés aux ressources de l’application, ce qui doit être fait lors de la compilation, d’autant plus que certains éléments des plugins ont un impact sur le back-end.
Plusieurs solutions d’atténuation :
Personnalisez autant que possible avec des composants de thème. Ceux-ci peuvent être remplacés et mis à jour en ligne.
Choisissez un ensemble de plugins et respectez cette liste. Pourquoi devez-vous modifier la configuration si souvent ?
Si vous avez simplement besoin de mettre à jour un plugin, utilisez l’outil de mise à jour en ligne.
Planifiez l’ajout de nouveaux plugins lors des périodes où vous êtes obligé de procéder à une reconstruction en raison d’autres modifications fondamentales dans l’application principale.
La seule vraie recommandation que nous puissions faire ici est de planifier à l’avance. Rien ne la remplace.
Utilisez une petite instance pour tester et valider les modifications de plugin que vous souhaitez apporter, puis prévoyez une fenêtre chaque semaine ou chaque mois pour déployer l’ensemble de ces modifications sur votre site en production.
De cette façon, vos utilisateurs ne seront pas significativement affectés par ces opérations, et vous réduirez considérablement le risque de temps d’arrêt supplémentaire dû à des problèmes de compatibilité.
Avec une configuration comportant plusieurs conteneurs web, les temps d’arrêt pendant une reconstruction peuvent certainement être évités en reconstruisant et en déployant un conteneur web à la fois.
Je suis désolé @Faizan_Zahid, mais tu aurais vraiment pu faire mieux avec ce titre. Peut-être voulais-tu dire « plugins » et non « Discourse ». Ici, je m’attendais à ce que quelqu’un demande une fonctionnalité pour supprimer Discourse d’un serveur
Tu souhaites pouvoir installer/désinstaller des plugins sans avoir à reconstruire. Malheureusement, cela semble impossible
Tu aimerais ensuite minimiser les temps d’arrêt lors des reconstructions. C’est déjà un sujet qui a été abordé récemment : Aide pour une configuration « zéro temps d’arrêt » (ce qui n’a pas vraiment abouti là où il aurait fallu).
Ce dont nous aurions besoin ici, c’est d’un tutoriel bien fait sur la configuration d’une installation à deux conteneurs web et sur son utilisation. Cela semble être la configuration la plus efficace (et probablement aussi la plus complexe). Je n’ai pas assez de connaissances pour rédiger un tel tutoriel, sinon je l’aurais fait. Y a-t-il quelqu’un de disposé à le faire ?
Je compte prendre en charge la tâche de créer des guides simples pour diverses cas d’utilisation avancés, y compris celui mentionné ci-dessus. C’est déjà dans la liste des tâches à venir
Bien qu’il fonctionne encore aujourd’hui, à ma connaissance, Procourse a cessé de servir ses clients. Je serais très réticent à le recommander sans une feuille de route de maintenance claire.
Je n’étais pas au courant de cela. Cependant, tant que la structure de Discourse ne change pas de manière significative, cela devrait continuer à fonctionner. Accent mis sur le devrait. Je me demande si l’auteur permettrait à quelqu’un d’autre de reprendre le projet s’il a arrêté.
Au fil du temps, tous les plugins doivent être mis à jour. Même de petits changements occasionnels peuvent causer des problèmes pour les plugins Discourse en développement actif. Il n’est tout simplement pas possible de prédire cela, et ce n’est certainement pas quelque chose sur quoi l’un d’entre nous puisse compter.
Un plugin qui gère lui-même l’installation d’autres plugins et qui n’est plus maintenu est une proposition très risquée. Compter sur l’optimisme pour continuer à l’utiliser semble être une très mauvaise idée.
Je n’ai travaillé qu’avec deux clients qui ont exprimé leur intérêt pour son utilisation. Une fois qu’il est devenu clair que Procourse n’existait plus, tous deux étaient enthousiastes à l’idée de migrer vers une autre solution.
Cela revient à dire que les Développeurs devraient envisager d’intégrer ce type de fonctionnalité directement dans Discourse, même en tant qu’option activable via la ligne de commande, si la sécurité peut être une préoccupation.
AFAIK, les défis sont plus fondamentaux que cela. Tel qu’il est, l’approche ne fonctionne pas du tout avec les sites multiples.
Vous ne pouvez pas non plus désinstaller directement les plugins si vous installez par inadvertance quelque chose qui s’avère incompatible. Cela nécessite un accès SSH.
J’ai lu la question concernant les sites multiples. On pourrait simplement ajouter une vérification et n’autoriser que les installations qui ne sont pas des sites multiples utilisant Docker.
Donc oui, cela pourrait nécessiter quelques ajustements. Cependant, c’est quelque chose qu’ils devraient examiner pour les installations non multi-sites.
Même si cela était adopté en tant que plugin officiel pour les conteneurs de site unique.
Si vous lisez plus loin dans le sujet, vous verrez à quel point le dépannage de base des problèmes de compatibilité des plugins devient plus difficile.
Juste quelque chose qui doit figurer dans la feuille de route. Ce n’est pas très différent, parfois, d’utiliser une interface graphique sous Linux pour installer plutôt que la ligne de commande ; cependant, certains ont réussi à faire fonctionner cela correctement.
Chaque fois que vous utilisez des installations non officielles, il y a un risque de dysfonctionnement. Par conséquent, par exemple, la possibilité d’activer ou de désactiver un plugin comme un thème ou un composant de thème serait idéale.
Récemment, j’ai rencontré un problème où il semble que les icônes de catégories aient causé des dysfonctionnements. Même avec un thème de base sans autres modifications CSS ou composants. Cela a pris un certain temps pour identifier la cause.
Le côté étrange, c’est que cela fonctionne sur notre installation de test distincte qui exécute la dernière version bêta de Discourse.