Si l’erreur indique que reactions, data explorer et solved sont toujours dans votre fichier yml, alors c’est probablement le cas. Si vous pensez les avoir commentés, est-il possible qu’ils aient été saisis deux fois ?
Il vaut vraiment la peine de revoir la configuration et de vous assurer que vous avez modifié le fichier yml qui correspond à votre site.
Salut
J’ai réussi à mettre à niveau mon forum vers la dernière version stable 3.4.6. Avant cela, j’utilisais le plugin autonome discourse-oauth2-basic pour l’authentification.
Il n’y a pas de connexion Oauth2 Basic dans /admin/plugins.
Ma version de Discourse est 3.4.6.
INDICE : Le plugin ‘discourse-oauth2-basic’ est maintenant inclus avec Discourse et ne doit pas être inclus dans la configuration de votre conteneur.
Supprimez la ligne ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ de votre fichier containers/app.yml, puis réessayez.
Pour plus d’informations, voir Bundling more popular plugins with Discourse core
J’ai dû supprimer le plugin discourse-oauth2-basic avant la mise à niveau vers la 3.4.6.
Pourriez-vous m’aider à comprendre ce qui a pu mal se passer ?
Merci !
Hmm… est-ce que ce serait le fait que vous êtes sur la version stable ?
Suite à l’invite système, j’ai supprimé le plugin discourse-oauth2-basic avant de réussir à passer à la version stable 3.4.6.
Cependant, j’ai maintenant découvert que les options de configuration pour OAuth 2 Basic sont manquantes dans le tableau de bord administrateur.
Si vous êtes sur la version stable, alors aucun de ces sujets ne s’appliquera avant la prochaine version stable début août. Vous devriez donc rajouter oauth2-basic dans votre app.yml. L’échec initial devait être dû à une autre raison.
Malheureusement, la logique de « hint » n’est pas très intelligente et n’est pas consciente de la distinction entre stable et tests-réussis.
Moi aussi, mais qu’est-ce qu’on peut y faire ? lol Je pense que plus de ressources natives, alias des plugins, même désactivés, ne sont pas une bonne solution pour aider les débutants à s’auto-héberger.
@nat Regarde ça, la traduction de ma citation et ma réponse
Peu importe comment j’ai essayé de commenter les lignes de clonage dans les sections des plugins, mais il lisait ces lignes comme si je voulais installer les plugins. Qu’ai-je fait ? Supprimez la ligne et cela a finalement fonctionné.
Lorsque vous mettez à niveau, vous devez vérifier la liste des plugins inclus dans le cœur de Discourse pour ne pas l’ajouter dans la section des plugins pour installer ou supprimer cette ligne si vous l’avez dans votre fichier app.yml.
Je pense que comme ceux-ci sont préinstallés, il devrait y avoir des options pour les séparer 
de la liste des installés. Car la liste des installés est désinstallable alors que ceux-là ne peuvent qu’être désactivés.
Peut-être que les plugins fusionnés de base devraient être sous quelque chose comme “Plugins mis en avant” ou “Plugins de base”.
Avec bien sûr, peut-être un filtre “Tous”.
Leur suggestion n’est pas idéale, mais elle fonctionne. Exemple :
## Les plugins vont ici
## voir https://meta.discourse.org/t/19157 pour les détails
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
(Ajustez selon vos besoins)
7 messages ont été déplacées vers un nouveau sujet : Dépannage des échecs de démarrage dans Discourse
La réalité est que la branche stable EST une LTS, et plutôt une bonne d’ailleurs. Elle reçoit des mises à jour de sécurité et il est assez clair quelles versions de plugins y sont compatibles (grâce au fichier .discourse-compatibility). J’admets totalement qu’il a fallu beaucoup de temps avant que tout cela ne fonctionne, mais ces deux dernières années environ, c’est le cas – ce qui est une grande réussite de l’équipe.
Passons à la deuxième partie de votre déclaration. Il est vrai que stable est souvent présenté comme quelque chose à éviter. Mais chez Communiteq hosting, nous donnons depuis 2 ans et demi aux clients le libre choix entre stable (« la stabilité avant tout, nouvelles mises à jour deux fois par an, mises à jour de sécurité une fois par mois ») et tests-validés (« toujours à la pointe, nouvelles fonctionnalités une fois par mois ») et 85% choisissent la version stable.
Je comprends. Mais n’est-ce pas un problème de développement et non un problème de production ? Je peux tout à fait comprendre que vous fassiez cela en développement. Mais ajouter ces plugins dans une installation de production par défaut va un peu à l’encontre de l’idée d’avoir un plugin (qui est par définition quelque chose de non-défaut).
Le seul avantage réel en production que je vois est le problème très, très marginal de désinstaller des plugins et des hôtes multisites. (Encore une fois, c’est une bonne chose, tous les autres problèmes de production ont été résolus au fil du temps !)
Cela aurait également pu être résolu dans le script d’installation en affichant une liste de plugins que les utilisateurs peuvent cocher, puis en les ajoutant à app.yml.
Mais vous proposez toujours différents (sous-)ensembles de plugins pour différents niveaux, n’est-ce pas ?
J’aurais également préféré l’approche de décommenter app.yml.
Tous ces plugins sont installés sur tous nos plans en libre-service. Certains niveaux n’ont pas accès, mais ils restent installés même s’ils n’ont pas accès.
Nous ne changerons pas cette décision, c’est donc simplement quelque chose que les gens devront accepter. Je comprends que certaines personnes soient contrariées, que certaines personnes soient contre cela, mais cela ne changera tout simplement pas.
Cela nous donne de la vélocité pendant le développement, cela définit nos préférences, cela garantit que Discourse, tel qu’utilisé par la grande majorité des gens, est plus stable.
Il existe d’autres plugins… les plugins principaux ne sont pas les seuls plugins.
Une publication a été divisée en un nouveau sujet : Discourse n’expédie pas de version LTS
Je suis tout à fait d’accord qu’il est logique d’intégrer les plugins populaires et leurs fonctionnalités dans l’image principale. Surtout s’ils proviennent des mêmes développeurs (CDCK) que le cœur lui-même. C’est une pratique courante même pour d’autres projets logiciels. Mais nous devrions résoudre les problèmes de démarrage - je reste optimiste 
C’est la raison pour laquelle vous ne pouvez pas reconstruire.
Ce serait certainement la meilleure voie. Cela peut toujours être implémenté en utilisant le code de suppression de plugin dans le message précédent.
Ajouter cela au script d’installation offre de bien meilleures options dès le départ et il est assez courant dans les programmes de vous permettre de choisir si vous souhaitez installer certaines fonctionnalités optionnelles ou non.
Le fichier de comparabilité est intéressant. Bien qu’à mon avis, des informations de comparabilité devraient être ajoutées aux sujets. Avec un lien ou des instructions pour savoir si le TC/plugin est disponible pour les instructions d’installation Stable et Tests-validés.
Merci pour le guide ; cela fonctionne très bien à l’exception du plugin « automation », qui ne peut pas être supprimé, car il semble que le plugin de discussion en dépende.
Le plugin d’automatisation est quelque chose qui ne devrait vraiment pas être supprimé, pour être honnête. Il a tellement d’utilisations potentielles utiles. Il faut y investir plus de temps, à mon humble avis, pour obtenir plus d’options d’automatisation.
Mais oui, c’est bien qu’il y ait une option pour désencombrer en supprimant les modules complémentaires qui, comme l’a souligné @RGJ, les extras vraiment récents qui ont été fusionnés soulèvent la question de savoir si ces options sont souhaitables à installer. Peut-être même un script séparé pour après l’installation juste pour rendre les choses plus conviviales pour l’auto-hébergement afin que certains qui pourraient vouloir éviter d’avoir à modifier le fichier app.yml.