Je n’ai pas reçu cette invite. Mais j’ai suivi le journal d’erreurs et supprimé les lignes. Je reconstruis à nouveau maintenant.
Modification : Outre l’introduction de bogues et 20 minutes d’indisponibilité, si ces lignes de plugins ne sont pas supprimées avant la mise à niveau ; Pourquoi avons-nous vraiment besoin de ce surplus de plugins préinstallés ?
Je suis curieux de la vue d’ensemble. Quelle est la raison de regrouper ces plugins par défaut ?
Personnellement, cela ressemble un peu à la direction que Windows, les systèmes d’exploitation mobiles et certains logiciels ont prise en ajoutant plus de composants préinstallés par défaut (BLOAT) que beaucoup d’entre nous essaient généralement d’éviter.
Je suis sûr que ce changement a probablement été discuté avec la communauté avant d’être mis en œuvre. Si c’est le cas, pas besoin d’une réponse répétitive, incluez simplement un lien vers la discussion ou l’annonce pertinente afin que je puisse lire comment et pourquoi cette décision a été prise.
Le regroupement de plugins plus courants permet également à plus de sites de bénéficier du fait de ne pas avoir à compiler leur propre JS, réduisant ainsi les temps de compilation et les coûts de ressources.
Je n’ai donc pas encore appuyé sur le bouton de mise à niveau car j’utilise certains des plugins qui sont maintenant regroupés. Je n’ai pas peur, j’ai survécu à la mise à niveau de la base de données il y a quelques mois.
Est-il préférable de mettre à jour mon fichier app.yml à partir de la liste dans le message initial (sauvegardé d’abord, évidemment) ou recevrai-je un message d’erreur significatif dans l’interface utilisateur qui me dira lesquels supprimer et comment procéder ?
Cela est en quelque sorte répondu dans le titre du sujet. Populaire signifie souvent couramment installé et utilisé. Les regrouper pour les “Self Hipsters” signifie que vous n’avez pas besoin de perdre du temps à les installer. De nombreux plugins et TC ont finalement été fusionnés avec le programme principal.
L’avantage d’avoir ces éléments comme plugins permet de disposer de temps de développement pour tester les préférences des consommateurs et les développer pleinement.
Bien sûr, il y aura une variété de communautés qui n’utiliseront aucun des éléments nouvellement regroupés avec le cœur. Mais la métrique la plus importante montre probablement que ce sont souvent ceux qui sont installés après la configuration. Ensuite, bien sûr, ils ont également les métriques de leur hébergement payant des plugins utilisés et non utilisés dans le niveau de base.
J’ai raté 2 plugins avant ma reconstruction. Le journal d’erreurs, cependant, était bien mieux amélioré pour identifier cela facilement par rapport à avant, où il fallait faire défiler vers le haut et identifier le problème.
Je pense que la requête que David a mentionnée est soit l’erreur de reconstruction, soit elle se trouve sur votre page de plugins pour la mise à jour web.
Pas de souci, il n’est pas toujours facile de voir une réponse avant de poser la question.
J’ai moi-même mis à jour mon app.yml.
En utilisant des commentaires, j’ai organisé le mien par fournisseurs de plugins pour un tri plus facile. Cela dit, cela a quand même été un peu pénible. Quelques messages plus haut, je crois que quelqu’un a posté une méthode pour vérifier avant de reconstruire.
Pour être honnête, comme il s’agissait du fil d’annonce, je suis venu ici et j’ai commencé un commentaire car la mise à jour a échoué et je n’ai pas reçu de notification indiquant que je devais d’abord modifier. Ensuite, une fois que cela a été résolu, j’ai modifié le message. Mais si c’est la seule discussion publique, merci.
Je peux comprendre les avantages, mais il y a certainement des inconvénients. Je pense donc que tous les propriétaires de forums Discourse ne seront pas de grands fans des plugins. Il aurait donc été agréable de l’offrir en option. Peut-être lors de la mise à jour une seule invite, ou peut-être dans la zone d’administration un réglage ou une notification qui vous rappelle de définir votre préférence avant la prochaine mise à jour.
Existe-t-il une page qui liste les plugins incorporés par date. Je n’aime pas mettre à jour via l’administrateur web pour échouer ensuite. Je suis sur la version 3.5.0.beta9-dev (04dbc622ab).
Peut-être ai-je manqué la page avec les dates / versions sur lesquelles les mises à jour sont installées. Merci.
L’idée est probablement qu’il s’agit des plugins les plus populaires, et que la plupart des gens en utilisent déjà une combinaison (comme vous-même). Ce n’est pas vraiment du “bloat” car ils n’ont pratiquement aucune empreinte, et vous n’avez pas à en utiliser un seul. C’est très différent d’avoir 20 programmes que je ne veux pas installés sur Windows, ce sont des interrupteurs marche/arrêt (la plupart des gens ne les verront pas, et vous, en tant qu’administrateur, les aurez dans une liste de 300 autres choses que vous n’utilisez/modifiez déjà pas) et non quelque chose qui apparaît constamment/prend de la place/est configuré pour faire des choses par défaut. Avoir un programme de notes installé par défaut dont je ne veux pas signifie que j’en aurai deux. Avoir un plugin dont je ne veux pas signifie qu’il y a juste une option dans un panneau.
Il est également beaucoup plus facile d’avoir des interrupteurs marche/arrêt que de devoir chercher sur un forum tiers (ou des githubs sans fin) quelque chose dont on ne sait même pas qu’il existe en premier lieu. C’était d’ailleurs la première fois que j’étais au courant d’une poignée d’entre eux.
J’ai enfin eu le temps de mettre à jour vers la version 3.5.0.beta9-dev (df03ef6d05)
Je suis auto-hébergé avec une installation standard
J’ai modifié mon fichier app.yml pour supprimer les lignes de plugins (selon les conseils de Dan ci-dessus), puis j’ai procédé au lancement du processus de mise à jour. J’ai dû mettre à jour le gestionnaire Docker avant tout le reste, comme d’habitude, et cela s’est déroulé normalement. Une fois le gestionnaire Docker mis à jour, j’ai été accueilli par un nouveau message (pour moi).
J’avais déjà effectué une reconstruction auparavant, donc je savais comment faire et comme Putty était toujours ouvert sur mon serveur, ce n’était pas un inconvénient, mais j’ai été un peu surpris de ne pas pouvoir utiliser l’interface utilisateur pour effectuer la mise à jour. Je publie ceci juste pour avertir d’autres noobs auto-hébergés comme moi. En dehors de cela, la mise à jour s’est bien déroulée, tout fonctionne. Merci à l’équipe et à la communauté.
Pour solved, topic-voting et templates, vous avez raison, les plugins eux-mêmes sont activés. Mais ces plugins ne font rien tant que les fonctionnalités ne sont pas activées pour une catégorie particulière.
J’aimerais que vous vous souciez davantage de maintenir la compatibilité et que vous ne nous fassiez pas perdre une demi-journée chaque fois que nous mettons à jour nos sites. Ranger légèrement votre code ne vaut pas la peine de casser les sites des gens et de leur faire perdre du temps.
Franchement, je commence à chercher des alternatives à Discourse car j’en ai marre que mon site entier se casse tous les quelques mois et que je doive trouver comment le réparer alors que rien de tout cela ne fait partie de mes compétences.
Désolé d’apprendre votre frustration - bien que je ne sois pas sûr des problèmes que vous avez rencontrés spécifiquement avec les plugins groupés ici ?
Nous essayons de rendre les mises à niveau aussi faciles/simples que possible, mais avec des changements majeurs comme celui-ci, cela causera inévitablement des frictions. Dans ce cas, nous avons ajouté des sorties d’erreur spécifiques sur la façon de modifier la configuration de votre site pour que la correction soit aussi simple que possible.
Un problème, à mon avis, est que Discourse_docker n’est pas très doué pour savoir quand une reconstruction en ligne de commande est nécessaire. Et cela rend facile de casser votre site en cliquant sur mettre à niveau dans le panneau d’administration. (du moins, c’est ce que je pense que les gens se plaignent)
Je pense que j’avais l’habitude de voir des commits qui disaient qu’ils faisaient cela et je pense que je ne les vois plus autant. Je n’utilise pas discourse_docker (beaucoup ?) moi-même, donc je n’ai pas prêté une attention particulière.
Si cet utilisateur avait exécuté une reconstruction et non la mise à niveau depuis l’interface utilisateur, il aurait simplement pu faire un
./launcher start app
Et attendre de traiter la mise à niveau quand cela lui conviendrait.
