Au cours des prochaines semaines, nous allons intégrer un certain nombre de plugins Discourse populaires dans le dépôt principal. Cela signifie que Discourse sera livré avec un plus grand nombre de plugins par défaut, et il nous sera plus facile de les maintenir tous testés et à jour.
Tous ces plugins resteront désactivés par défaut, de sorte que cela n’aura aucun impact visible sur les communautés existantes. Si vous utilisez un service d’hébergement géré comme discourse.org, vous n’avez rien à faire.
Communautés auto-hébergées
Si vous auto-hébergez Discourse et que vous utilisez déjà l’un de ces plugins, vous serez invité à supprimer la ligne correspondante de votre fichier app.yml avant votre prochaine reconstruction.
Environnement de développement
Si vous avez déjà l’un des plugins installé localement, puis que vous récupérez la dernière version de Discourse core, l’une des deux choses suivantes se produira.
Si vous utilisez des liens symboliques pour vos plugins, vous obtiendrez une erreur lors de git pull. Pour résoudre le problème, supprimez le lien symbolique, puis exécutez à nouveau git pull.
Si vous clonez les plugins directement, le git pull du cœur réussira, mais vous aurez des ‘modifications non enregistrées’ surprenantes causées par les dépôts git imbriqués. La meilleure façon de procéder est de supprimer le répertoire affecté, puis de le restaurer à partir de main. Par exemple :
Merci. Avec mes faibles connaissances en développement et en programmation, j’aimerais quand même vous poser une question. Ces plugins, qui sont à l’origine des composants destinés à être ajoutés à une installation de base, pourraient-ils un jour perdre leur caractère de plugin pour devenir une partie intégrante d’une installation de base, sans être appelés du tout des plugins ?
Ils pourraient le faire, oui. En particulier, les plugins d’authentification (par exemple, apple-auth) sont très susceptibles d’être intégrés au cœur, tout comme nos autres méthodes d’authentification intégrées (par exemple, Google, Facebook, etc.).
Mouvement intéressant qui stimule encore plus le discours par défaut et facilite les nouvelles installations.
Une question concernant :
vous serez invité à supprimer la ligne pertinente de votre fichier app.yml avant votre prochaine reconstruction.
Y aura-t-il également une invite ou un message d’avertissement avant/lorsque vous cliquerez sur le bouton de mise à niveau depuis la page de mise à niveau de l’administrateur ?
Si je me souviens bien de mon expérience, vous ne pourrez d’abord mettre à jour que docker. Une fois que vous aurez mis à jour docker, un message s’affichera dans l’interface utilisateur de mise à jour expliquant que vous devez mettre à jour via la ligne de commande, et comment le faire.
Ensuite, lorsque vous mettrez à jour sur la ligne de commande, vous verrez l’INDICE pour chaque plugin que vous devrez supprimer de app.yml comme expliqué dans le premier message ci-dessus.
C’est une bonne mise à jour, mais était-ce vraiment nécessaire ? Un échec de reconstruction me semble un peu sévère… un avertissement d’interface utilisateur, une mise à jour automatisée (ou simplement les ignorer complètement) aurait été plus agréable que de me mettre un pistolet sur la tempe et de dire « supprimez-les maintenant »
Cela m’a eu la semaine dernière lorsque j’ai essayé de mettre à jour via la ligne de commande et que cela a échoué (plugin de réactions).
Cela m’a eu à nouveau ce matin lorsque ma mise à jour en ligne de commande a échoué à nouveau (plugin d’explorateur de données).
J’apprécierais grandement un avertissement sur la ligne de commande avant le début du processus de mise à jour, qui échoue ensuite inévitablement.
Deux fois en deux semaines, mes mises à jour ont échoué, ce qui a signifié que mon Discourse était hors service pendant le temps qu’il me fallait pour déboguer le problème, modifier les configurations, réessayer, etc. - tout cela dans un état de panique légère parce que tout est cassé.
Une mesure que nous allons bientôt suivre est de supprimer les lignes de gemmes dans les plugins principaux et de passer au fichier de gemmes monolithique.
Je suis curieux, avez-vous obtenu cette liste de plugins à partir d’installations Discourse en production ? Elle correspond à près de 50 % de ma propre installation principale !
Je me demande si le fait d’avoir tous ces plugins regroupés dans le cœur n’alourdirait pas les forums ? Par exemple, il y aura probablement quelques plugins que les administrateurs ne voudront pas sur leur forum (par exemple, Discourse AI), mais qu’ils n’auront pas le choix d’ajouter. Ils peuvent être désactivés, bien sûr, mais je me demande si les fichiers et autres éléments ajoutés ne ralentiront pas les forums ?
Côté client, Discourse ne sert aucun actif JavaScript pour les plugins désactivés, il n’y aura donc aucun impact de ce côté.
Côté serveur, pour les plugins correctement implémentés (ce qui est le cas de tous ceux-ci), les personnalisations des plugins sont ignorées lorsqu’ils sont désactivés. Donc oui, techniquement, il pourrait y avoir une légère surcharge pour vérifier l’état activé/désactivé, mais elle devrait être minime.
Les plugins que nous fusionnons ici sont ceux que nous exécutons sur chaque instance de Discourse sur notre hébergement discourse.org. Ils sont donc tous très bien testés à grande échelle.
Y a-t-il une raison pour laquelle vous faites tout cela en même temps peu avant la sortie ? Pour les traducteurs qui font cela pendant leur temps libre, 3 000 chaînes supplémentaires en deux semaines, c’est beaucoup. Et même dans les langues où les plugins étaient auparavant traduits, les 3 000 textes doivent être relus. De temps en temps, 300 seraient probablement plus gérables que 3 000.
Pour les communautés auto-hébergées qui exécutent déjà un ou plusieurs de ces plugins, les plugins perdront-ils leurs données de configuration lorsqu’ils seront supprimés de app.yml et intégrés au cœur ?
J’ai configuré le plugin IA exactement comme je le souhaite ; si je dois le reconfigurer (ou du moins noter les options de configuration afin de pouvoir les rajouter), ce serait bien de le savoir maintenant.
Nous avons essayé de rendre cela aussi fluide que possible pour les traducteurs en utilisant la mémoire de traduction dans Crowdin, afin que les traductions n’aient pas à être refaites à partir de zéro. Mais quand même, je suis d’accord, il y a beaucoup à relire.
Je me demande s’il y a plus de choses que nous pouvons automatiser ici, par exemple, peut-être pouvons-nous « approuver automatiquement » toutes les chaînes de ces plugins, au lieu d’exiger une relecture :yeux:
Toute la configuration/les données seront maintenues.
Ce sujet méta n’est pas vraiment ce que vous voudriez voir.\n\nLa difficulté réside dans le fait de savoir quels plugins vous devriez supprimer de votre app.yml et lesquels vous ne devriez pas.
