Je souhaite passer à la dernière version, mais je rencontre des problèmes avec certains composants de thème.
Ce sont tous mes propres composants, et je les ai déplacés de GitHub vers GitLab. Maintenant, lorsque je souhaite mettre à jour Discourse (pas depuis l’interface de Discourse), j’obtiens des erreurs car ils ne sont plus disponibles. J’ai essayé de les supprimer depuis Discourse, mais ils ne disparaissent pas.
Ma question est donc : où se trouve le chemin pour les supprimer directement sur le serveur ? Je n’arrive pas à les trouver.
J’ai essayé le mode sans échec, mais je ne peux pas accéder au forum dans ce mode.
MODIFICATION :
Existe-t-il un fichier, similaire à app.yml, où tous les thèmes et composants sont stockés, afin que je puisse supprimer la liste et reconstruire Discourse sans eux ?
Je pense que c’est le problème que vous devez résoudre. La bonne approche consiste à supprimer tous les thèmes et composants de thème provenant de l’ancien emplacement, puis à en importer de nouveaux depuis leurs nouveaux emplacements.
Ce n’est pas possible, car Discourse se retrouverait alors dans une boucle infinie. C’est la raison pour laquelle j’ai demandé comment les supprimer autrement.
Je ne peux même pas accéder au mode sans échec.
Une réinstallation n’est pas non plus possible, car la sauvegarde est trop ancienne.
Après avoir exécuté ./launcher rebuild app, j’ai constaté que le forum n’est pas accessible aux invités.
Alors, comment puis-je le faire fonctionner à nouveau ?
Je pense que désactiver manuellement les composants dans la base de données est une solution qui pourrait constituer un dernier recours ici. C’est très risqué, mais réalisable s’il n’y a pas d’autres options.
Les composants désactivés permettront au moins à la reconstruction de réussir, ce qui, à son tour, permettra d’accéder à l’interface d’administration pour supprimer et réinstaller les composants depuis GitLab.
Ils ne sont pas stockés dans la base de données, mais leur état d’activation/désactivation l’est.
Je ne me souviens pas exactement des étapes, mais j’ai récemment réparé une installation présentant un problème similaire.
Le plus important ici est de savoir si votre conteneur est toujours en cours d’exécution. Si c’est le cas, je pourrai peut-être vous conseiller sur la manière de désactiver depuis la base de données les composants problématiques.
Bon, d’accord, c’est un problème.
Est-il possible d’utiliser quelque chose comme pgAdmin pour accéder directement à la base de données ?
Je ne connais pas l’ID du thème et des composants, car je n’ai plus accès à l’interface d’administration.
Édition :
J’ai trouvé le thème et les composants.
Le désactiver ne fonctionne pas, alors comment les supprimer avec rails c ?
J’ai même essayé de m’en débarrasser avec rake, mais rake ne peut pas non plus les supprimer.
rake themes:uninstall https://github.com/link/to/git.git
rake aborted !
La tâche 'themes:uninstall' est inconnue (consultez la liste des tâches disponibles avec `rake --tasks`)
Vouliez-vous dire ? themes:install
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
(Voir la trace complète en exécutant la tâche avec --trace)
Ou quelle est la bonne commande pour supprimer des éléments avec rake ?
J’obtiens une liste de commandes avec rake --tasks et rake -AT, mais il n’y a pas de commande pour supprimer un thème ou un composant.
Avec rails c, je peux désactiver un thème, mais après un rechargement, c’est toujours l’ancien thème corrompu qui s’affiche.
Salut @Osama. Je m’inquiète récemment de la problématique des composants de thème pouvant casser une reconstruction.
Je pense qu’il nous faut un howto pour y remédier.
Je crois que cette correction ne traite que le cas où « la construction échoue parce que l’URL GitHub est cassée », n’est-ce pas ?
Pour les constructions qui échouent à cause d’une erreur dans le JavaScript, existe-t-il une méthode similaire pour désactiver ou supprimer les thèmes en ligne de commande que nous devrions inclure dans un howto ?
EDIT : comme l’échec lorsque « Alternative Logos » est inclus…
Je réfléchis à cela depuis un moment également, et mon avis est que cela a du sens pour certaines communautés mais pas pour toutes. Certaines communautés considèrent leurs personnalisations/thèmes comme une partie fondamentale de l’identité de leur site et elles aimeraient vraiment savoir s’il y a des problèmes avec leurs personnalisations lorsque leur site est déployé. D’autres communautés utilisent une installation vanilla de Discourse avec quelques personnalisations ou composants ajoutés par-dessus et elles pourraient facilement se passer de ceux-ci pendant quelques jours.
Peut-être que la case à cocher « Mettre à jour automatiquement lors de la mise à jour de Discourse » devrait être désactivée par défaut lors de l’installation d’un nouveau thème ou composant ? Elle est actuellement activée par défaut et je pense qu’elle devrait être désactivée par défaut, mais cela nécessite une discussion plus large…
Non, l’extrait de code ci-dessus (en particulier la deuxième ligne) désactive la mise à jour automatique lors du déploiement pour tous les thèmes/composants actuellement installés. Cela devrait donc corriger toutes les constructions cassées dues à la mise à jour automatique des thèmes, y compris les erreurs JS/CSS. Le howto ne devrait inclure que la deuxième ligne.
Je viens tout juste de rencontrer ce problème aussi. Si vous avez un composant lié à un dépôt public et que vous rendez ensuite ce dépôt privé, les reconstructions échouent. C’est désagréable car les utilisateurs peuvent apporter des modifications qui peuvent casser le site des mois plus tard pour les administrateurs système.
Les commandes sur Path of theme components - #16 by Osama ont très bien fonctionné pour moi. J’ajouterais des instructions sur la façon d’accéder à la console Rails.
