Ayant été mordu par le problème « échec de reconstruction du plugin » dès le début de mon auto-hébergement de Discourse, j’apprécie le désir de regrouper dans le cœur des versions connues et fiables. Et potentiellement offrir une sélection plus riche de fonctionnalités.
Une organisation axée sur le client aurait pu organiser un sondage sur la direction des plugins principaux, ou du moins sur le calendrier. Peut-être que je l’ai manqué. En tant que fournisseur d’outils informatiques pour mes clients (c’est-à-dire les utilisateurs finaux) qui essaient d’accomplir un travail réel avec l’informatique, j’ai vu de nombreux produits être révisés dans une surcomplexité et finalement remplacés. Maintenant, nous aurons des auto-hébergeurs qui feront « rm -fr » les plugins dont ils n’ont pas besoin. Je comprends cela et je pourrais rejoindre ce club. D’après mon expérience, un code supplémentaire augmente la complexité de l’intégration, le risque d’erreurs de configuration et la surface d’attaque. Mais tôt ou tard, supprimer quelque chose que le développeur de l’application suppose être là, cassera également quelque chose.
J’aurais beaucoup préféré que les efforts des jedis de Discourse soient consacrés à travailler sur une méthode robuste, maintenue et scriptée pour activer le stockage cloud des images, y compris l’intégration CDN. L’intégration de l’e-mail SMTP est triviale en comparaison, et cela a été cassé par des changements chez MailGun et d’autres, causant des problèmes aux sites auto-hébergés.
En effet, je déconseillerais fortement d’utiliser rm -rf sur ces plugins. Comme vous le dites, il existe des risques d’interdépendances inattendues à l’avenir. Mais en plus, vous créerez une différence dans le dépôt git principal, ce qui signifie que les mises à jour de l’interface utilisateur via docker_manager échoueront presque certainement.
Bien sûr, laisser ces plugins dans leur état « désactivé » par défaut est totalement pris en charge, et garantira qu’ils n’auront aucun impact mesurable sur les performances.
Pour les auto-hébergeurs ou ceux comme moi qui fournissent des services d’hébergement à des clients, voici un simple grep qui listera si l’un des nouveaux plugins groupés est déjà présent dans votre containers/app.yml
Doit être exécuté en tant que root, et affichera toutes les lignes qui doivent être manuellement supprimées de la section des plugins de l’app.yml avant de reconstruire.
Pourriez-vous envisager de le modifier pour faire référence à containers.*.yml afin d’aider également ceux qui ont effectué une installation standard à deux conteneurs où ils seraient plutôt en mode web uniquement ? Vous ne voulez vraiment pas qu’ils soient dans vos définitions de conteneur, après tout.
@david Envisageriez-vous d’ajouter cela au premier message et de le maintenir une fois que vous aurez intégré cakeday ?
Remerciez ChatGPT qui l’a rédigé exactement correctement en une seule fois à partir de cette invite :
Veuillez extraire les URL GitHub de chacun des plugins mentionnés dans ce post https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
Compilez-les dans une liste et créez une commande unix qui me dira si l’un de ces plugins est déjà mentionné dans un ‘git clone’ dans le fichier containers/app.yml de ce Discourse.
En surface, cela me semble une chose raisonnable à envisager à un moment donné – avoir une manière plus déclarative de définir quels plugins sont chargés ou non au démarrage, même si la source est toujours présente sur le disque.
Cela dit, je ne connais pas la faisabilité ou l’ampleur de la tâche.
C’est certainement possible. Mais cela ajoute de la complexité - encore une chose à prendre en charge/maintenir. Et ce ne serait utile que dans des environnements à locataire unique (c’est-à-dire pas dans des environnements d’hébergement partagé, où différents locataires souhaitent des plugins différents).
Au contraire, je pense qu’il serait plus bénéfique de passer du temps à améliorer l’expérience utilisateur et les performances des plugins ‘désactivés’ (ce que nous avons déjà commencé à faire depuis cette fusion majeure dans le cœur).
De plus, je n’ai pas essayé de supprimer les plugins, car j’ai l’impression que cela compromettrait mes rapports de bugs à la métadonnée, tout comme la tentative d’une installation d’hébergement partagé.
Ouf, quelle mise à jour difficile. Identifier le problème dans le journal de reconstruction n’est pas trivial pour commencer. Je l’ai trouvé, j’ai négligé un autre plugin à supprimer de notre configuration deux fois, d’où la 3ème tentative de reconstruction qui a finalement réussi cette partie. Il aurait été vraiment utile de vérifier et d’avertir dès le départ que la configuration doit être ajustée. discourse-doctor vérifie (trop simple, mais peut servir de base) les plugins dans la configuration, donc cela peut être utilisé comme base. Probablement trop tard maintenant, 3 semaines plus tard, peu importe…
Mais ce n’était pas tout, nous avons également rencontré des erreurs db:migrate. Je l’ai réessayé 2 fois, puis j’ai exécuté discourse-doctor, qui a également exécuté la reconstruction, et bizarrement a réussi. J’ai vérifié son code, et il ne fait absolument rien, et appelle la reconstruction exactement de la même manière que nous. Il semble donc que db:migrate ait réussi à la 3ème tentative pour une raison quelconque ? J’ai lu dans le fil de discussion que le grand nombre de plugins ajoutés ajoutent des dépendances, qui peuvent entrer en conflit/être plus anciennes que ce qui était utilisé auparavant. Heureusement, nous n’avons pas eu besoin d’ajouter une étape de suppression manuelle de plugin, d’ajustement de dépendance ou de modification de base de données, comme d’autres semblent l’avoir fait. Est-il en quelque sorte attendu que l’exécution de db:migrate plusieurs fois réussisse finalement ? J’espère juste que rien n’est cassé…
Il a été installé plus tôt, nous l’avions simplement omis de l’interface utilisateur avec le reste des plugins groupés d’avant. Notre interface utilisateur a été améliorée pour afficher correctement tout ce qui existe. (nous avions un tas d’omissions, y compris Chat qui était caché via CSS)
J’ai déjà observé une augmentation de la vélocité de l’équipe de développement interne dans le très court laps de temps où cela a été mis en place. Cela conduit à un produit plus stable, ce dont je suis très heureux.
Aucun plan de retour en arrière ici. Vous devez vous adapter au nouveau monde.
À mon avis, si quelque chose casse parce qu’un plugin n’est pas installé, alors cela est un bug en soi. Le cœur ne devrait pas dépendre de plugins. Les plugins eux-mêmes devraient clairement indiquer leurs exigences sur leurs pages respectives.
Mais oui, cela rendra la version auto-hébergée encore moins stable à l’avenir, car ce seront les auto-hébergeurs qui trébucheront sur ces problèmes. Entre cela et le fil de discussion bifurqué, je n’ai vraiment pas l’impression que la stabilité des auto-hébergeurs soit une priorité élevée pour l’équipe.
Nous n’y avions pas pensé à l’avance, donc certaines approbations ont peut-être été omises. Mais nous avons réussi à en transférer une bonne partie des projets de plugins sur Crowdin vers le cœur. Nous ferons mieux la prochaine fois puisque nous avons maintenant les outils pour transférer les approbations entre les projets.
Non, nous n’avions pas vérifié au préalable, mais j’ai vérifié après. Aucun des plugins n’avait de commentaires sans réponse sur Crowdin. Nous avons un outil interne qui stocke tous les commentaires postés sur nos plugins Crowdin. Nous pourrions même l’utiliser pour republier les commentaires manquants sur Crowdin, par exemple lorsque Crowdin supprime des commentaires parce que la chaîne source a été mise à jour. Cela n’a tout simplement pas été une priorité de le mettre en œuvre.
D’accord. Peut-être une option pour lister les plugins principaux activés installés. Par rapport au simple fait d’afficher tous les plugins. Des options de filtrage supplémentaires sont certainement meilleures.
Je suis d’accord avec le sentiment. À mon avis, la vraie déconnexion est de les garder listés comme des plugins.
Une fois fusionné, cela devrait être déplacé vers quelque chose de marqué comme « Fonctionnalités principales », car les plugins sont considérés comme des composants optionnels qui peuvent être installés. Contrairement à une partie du programme principal. C’est donc un abus de langage à mon avis de continuer à les lister comme des plugins alors que l’intention n’est pas de les désinstaller.
Similaire aux TC qui ont été fusionnés dans le cœur comme « bulles personnelles » n’est pas listé dans les Composants de thème. Certes, dans ce cas particulier, vous ne pouvez pas désactiver l’ancien TC. Si vous vouliez revenir à ce que c’était avant, vous deviez créer un TC pour annuler les modifications
Cela éviterait la liste massive initiale dans Plugins installés.
Je suis tout à fait d’accord avec des options de filtrage supplémentaires. Pour en avoir également une pour les plugins désactivés.
Cependant, après plus de réflexion et de lecture de plus de messages. Si les plugins sont fusionnés avec le cœur. Ils ne devraient vraiment plus être appelés plugins et ne pas être listés dans Plugins. Mais peut-être quelque chose comme Fonctionnalités principales ou Fonctionnalités optionnelles. Puisqu’il n’est plus vraiment prévu de pouvoir les désinstaller.
Il n’y a aucune raison pour qu’un logiciel de forum correctement conçu exige du code publicitaire pour fonctionner.
Si Discourse décide d’intégrer des anti-fonctionnalités, la seule chose qu’il forcera les gens à faire sera soit de forker Discourse, soit de migrer vers autre chose. Ceux d’entre nous qui n’aiment pas la technologie / la publicité ressentent très fortement cela. Discourse ne nous l’imposera PAS, aussi difficilement qu’il soit poussé. (Ubuntu a essayé cela sur nous et maintenant mon dépôt le plus étoilé est quelque chose qui supprime les publicités ;))
Je ne suis pas sûr de comprendre. Si par code publicitaire vous entendez des plugins intégrés au produit principal par opposition à des modules complémentaires/installations facultatifs. Si nous revenons en arrière, vous trouverez une variété de “codes publicitaires” intégrés au cœur du système.
Je peux comprendre du point de vue de l’équipe de développement que bon nombre de leurs plugins ont peut-être commencé comme des plugins pour permettre des tests plus flexibles avant de les intégrer au programme principal.
J’apprécie que, comme pour tout logiciel, il y ait souvent des fonctionnalités que les gens pourraient ne pas utiliser et choisir de désactiver, et qu’il faille trouver des moyens de désinstaller des fonctionnalités.
Bien que je concède qu’il y a beaucoup de plugins récents qui ont été fusionnés et que je n’utiliserais probablement pas. Mais avoir une simple désactivation et les filtrer est une bonne chose pour tous.
Je comprends que, en partie comme l’a indiqué l’équipe, l’intention est de faciliter les choses avec des modules complémentaires pour l’auto-hébergement.
Maintenant, à mon avis, l’interface d’administration devrait être plus personnalisable comme elle l’était autrefois. Cela peut également aider les personnes qui migrent d’une autre plateforme en leur permettant de charger une administration qui a une disposition similaire à celle de la plateforme d’où elles viennent. Un peu comme Linux le fait en imitant d’autres systèmes d’exploitation. Mais c’est un autre sujet.
J’apprécie le sentiment que discourse pourrait commencer à se diriger vers le bloatware. Les réacteurs ont démontré à quel point Windows NT pouvait être plus léger.
