Je constate que les utilisateurs tentent souvent d’activer le mode sans échec dès qu’un problème survient, surtout lorsqu’ils utilisent des personnalisations tierces. C’est logique : on ne sait pas d’où vient le problème.
Cependant, le mode sans échec désactive uniquement JavaScript. S’il s’agit d’un problème lié à du code côté serveur, la solution immédiate consiste généralement à décommenter tous les plugins dans le fichier app.yml. C’est faisable, mais cela nécessite une reconstruction et reste relativement « technique ». Pour un utilisateur non technique, modifier manuellement le fichier app.yml n’est pas une décision qu’il prend à la légère.
Je me demande si une demande d’intégration (PR) visant à ajouter la désactivation des plugins côté serveur en mode sans échec serait viable. J’imagine quelque chose de ce genre dans le contrôleur de mode sans échec :
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
Bien sûr, le même résultat pourrait être obtenu en désactivant manuellement les plugins via les paramètres du site, mais j’observe que les utilisateurs le font rarement.
Le mode sans échec actuel ne s’applique qu’à la page en cours et disparaît dans un nouvel onglet ou après un rafraîchissement. Il est donc parfaitement sûr pour les tests.
Votre proposition modifierait sa signification en basculant un paramètre de manière persistante, ce qui affecterait l’ensemble du site. Cela signifie également qu’il doit être restreint aux administrateurs.
Je comprends votre proposition, mais cela représente un changement majeur de comportement.
Je pense que l’essentiel est que les administrateurs de site non techniques recherchent une solution pour remettre leur site en état de marche lorsqu’il est dysfonctionnel. Un « mode sans échec » est souvent perçu comme pouvant y parvenir (à juste titre ou non). Peut-être qu’une façon de procéder serait d’ajouter des contrôles supplémentaires pour le mode sans échec dans l’administration.
Vous pourriez ajouter un gros bouton sur le chemin /admin/plugins pour désactiver automatiquement tous les plugins de la même manière, mais je me demande si cela aurait le même effet. Peut-être que oui.
Je suis également attiré par cette idée car elle est tout à fait réalisable dans l’architecture actuelle des plugins de Discourse.
Habituellement, ce qui fait planter les plugins, ce sont des modifications incompatibles au niveau du cœur. Souvent, l’application ne démarre même pas si vous incluez un plugin problématique ou si le bootstrap échoue.
Une fonctionnalité permettant de désactiver tous les plugins devrait redémarrer l’application d’une manière ou d’une autre pour être correcte.
Je serais ouvert à une modification du plugin de gestion Docker qui permettrait de désactiver/activer facilement les plugins en déplaçant des éléments dans et hors du répertoire des plugins, puis en redémarrant l’application. Cela pourrait accélérer le débogage.
Je pense que cela serait également une bonne idée.
Cependant, je constate qu’un nombre non négligeable d’erreurs proviennent de code encapsulé dans l’API du plugin côté serveur, ce qui serait géré par cette mesure (je suppose ?).
Actuellement, le « mode sécurisé » (ou quelque chose de similaire) ne constitue pas non plus une solution complète aux problèmes de rupture. L’ajout d’une désactivation automatique des plugins rendrait cette solution légèrement meilleure, réduisant le nombre de cas où un redémarrage complet ou une modification de la configuration est nécessaire, et reflétant mieux la perception des administrateurs de sites non techniques.
Je cherche en fait des étapes progressives et relativement simples. Peut-être que le changement du gestionnaire Docker est tout aussi simple d’un point de vue technique.
Oui, si possible un jour, il serait très bien d’avoir un seul booléen « désactiver tous les plugins » dans les paramètres d’administration, qui fonctionne sans aucune reconstruction de conteneur. Cependant, n’étant pas développeur de Discourse (ayant seulement une année d’expérience en développement d’applications node.js et vuejs), mon intuition me dit que ce n’est pas un changement facile et qu’il s’agirait d’une modification très importante de l’architecture.
Notre ancien forum LAMP disposait de cette fonctionnalité, et nous ne pouvons pas compter le nombre de fois où nous avons utilisé ce booléen pour identifier rapidement une erreur liée aux plugins. Cependant, l’architecture logicielle est si différente qu’il n’est même pas utile de faire une comparaison.
Je suis personnellement confiant que l’équipe de Discourse trouvera une solution. De nombreux utilisateurs sont accros aux plugins, et il y aura de plus en plus de défis à relever avec le temps.
Un facteur important pour moi est que cette fonctionnalité serait 100 % destinée aux auto-hébergeurs. Je ne souhaite pas vraiment intégrer un mode sans échec pour les plugins dans le cœur du système ; ce n’est certainement pas quelque chose que nous utiliserions, car coordonner un redémarrage sur 5 clusters est complexe.
Le gestionnaire Docker est le bon véhicule ici. Il prend déjà en charge le redémarrage de l’application, ce dont votre proposition a besoin pour fonctionner, et il peut effectuer toutes les opérations requises sans modifier le cœur de Discourse.