Bonjour, lorsque j’essaie de me connecter à l’interface d’administration, j’obtiens un écran vierge. Je ne peux pas faire de mises à jour, par exemple, même si je suis administrateur.
Que dois-je faire ?
Merci de votre aide.
Muriel
Vous pourriez essayer le mode sans échec. Vous pourriez également faire une mise à niveau en ligne de commande.
Mise à jour : J’ai effectué un amorçage correct, une destruction, un démarrage avec une configuration à 2 conteneurs et maintenant les numéros de version signalés sont mis à jour et l’interface utilisateur d’administration se rend à nouveau.
Le reste du message reste pour la postérité.
Je rencontre ce qui pourrait être un problème similaire. L’interface d’administration se charge, mais n’affiche que les onglets en haut et la section de contenu principale est vide :
Journaux de la console du navigateur
En examinant les journaux de la console du navigateur, je vois des erreurs comme :
[Error] Error: VM BUG: Target must be set before attempting to jump
vendor.xxxxx-xxxx.js
Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
Pile d'erreurs
[Error] Error: VM BUG: Target must be set before attempting to jump
b (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:131956)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:69428)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:156653)
_runExpiredTimers (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:160801)
[Error] Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1310)
h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1311)
(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:3065)
h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1375)
requireModule (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:599)
_extractDefaultExport (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:269780)
resolveOther (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266326)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266888)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262092)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262185)
resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262275)
c (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:260192)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:258815)
getRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:56849)
fetchRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:267571)
_getQPMeta (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63399)
_hydrateUnsuppliedQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:64113)
_prepareQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63271)
normaliseQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38898)
_generateURL (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38990)
eA (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:202925)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49065)
X (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:140358)
T (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49044)
eM (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:80191)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:79868)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:70930)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:65312)
evaluateSyscall (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111047)
evaluateInner (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110609)
evaluateOuter (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110528)
next (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121496)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121359)
handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:112232)
handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:114799)
throw (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111583)
evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:68993)
_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:155980)
Processus de mise à niveau (2 conteneurs)
J’ai d’abord rencontré le problème en essayant d’effectuer la mise à niveau depuis l’interface d’administration de Discourse, où il m’a été indiqué que je devais d’abord mettre à jour le Docker Manager.
Après avoir mis à jour le Docker Manager, j’ai rencontré ce problème, j’ai donc utilisé SSH pour accéder à la machine et j’ai effectué une mise à jour manuelle (2 conteneurs) uniquement pour web_only :
cd /var/discourse
git pull
./launcher bootstrap web_only
./launcher stop web_only && ./launcher start web_only
^^^^^^
⚠️ Ceci est incorrect ! Utilisez destroy comme indiqué ci-dessous. ⚠️
Curieusement, le chemin /about.json indique toujours que j’exécute 3.4.0.beta4-dev, ce qui est ce que je pensais avoir démarré, car l’e-mail original concernait une mise à niveau de 3.4.0.beta4-dev vers 3.5.0.beta1.
J’ai revérifié le journal git et il semble qu’au moins discourse_docker soit sur le dernier commit 3715498fc188d60c0b579443383c4e973cf26f59 au moment de la rédaction de ce message.
Le mode sans échec fonctionne
Je n’étais pas au courant du mode sans échec, mais apparemment, le problème ne se produit pas si je désactive TOUS les plugins côté client.
La désactivation uniquement des personnalisations de plugins non officiels côté client ne résout pas le problème, car j’ai essayé chaque combinaison pour affiner le problème.
| Option | Résultat |
|---|---|
no_unofficial_plugins |
|
no_plugins |
|
no_themes |
La désactivation de docker_manager n’aide pas
J’ai essayé de commenter le plugin docker_manager sous hooks/after_code, puis de reconstruire le conteneur web_only + arrêt et démarrage, mais le message d’erreur côté client mentionné ci-dessus persiste.
Cela introduit un autre message d’erreur indiquant que la visite de la page d’administration de this.class.create n’est pas une fonction, mais c’est peut-être attendu avec le plugin docker_manager sous-jacent désactivé pour ce test :
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
at loader.js:247:1
at h (loader.js:258:1)
at u.findDeps (loader.js:168:1)
at h (loader.js:262:1)
at requireModule (loader.js:24:1)
at f.get (composer.js:874:1)
at push.98673._extractDefaultExport (composer.js:874:1)
at push.98673.resolveOther (composer.js:874:1)
at push.98673.resolve (composer.js:874:1)
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
index.js:78 Uncaught TypeError: this.class.create is not a function
at n.i [as getRoute] (upload-debugging.js:25:1)
at p._getQPMeta (upload-debugging.js:25:1)
Encore une fois, l’utilisation du mode sans échec avec no_plugins contourne temporairement le problème.
Je me souvenais des commandes pour la mise à jour minimale de 2 conteneurs avec temps d’arrêt réduit et apparemment ma mémoire n’est pas fiable ! ![]()
Après avoir utilisé la bonne commande pour détruire puis démarrer le nouveau conteneur après le bootstrap, je vois que les versions sont mises à jour et que l’interface d’administration fonctionne comme prévu.
Avez-vous mis à jour le conteneur de données ? Vous devriez le faire, mais avant, consultez la mise à jour PostgreSQL 15. Ou, si vous détestez vraiment lire, exécutez simplement ./laumcher rebuild data deux fois et tout devrait aller. Ensuite, vous devrez détruire et démarrer le conteneur web (sinon il recherchera l’ancien conteneur de données que vous aurez détruit).
Pas encore, mais merci de vous soucier !
J’envisageais déjà de mettre en place un nouveau serveur plus performant, j’ai donc fait quelques recherches pour voir si je pouvais sauvegarder depuis Discourse 3.5 + PG13 et ensuite restaurer sur Discourse 3.5 + PG15 sur un hôte différent.
Je n’aime pas les temps d’arrêt prolongés et par le passé, j’ai temporairement mis la communauté en lecture seule et effectué une sauvegarde/restauration entre les instances de serveur, ce qui a entraîné un temps d’arrêt quasi nul (à part la période de lecture seule, bien sûr)… j’ai donc pensé rechercher/tester pour voir si cela fonctionnait entre les versions de PG.
Sinon, je me résignerai et je ferai d’abord la mise à niveau PG15 avant la migration du serveur. ![]()
Ça fonctionne. Il est probablement temps de mettre à niveau votre système d’exploitation de toute façon. Démarrez simplement un nouveau serveur et restaurez votre sauvegarde.
J’ai exactement le même problème. Merci de votre aide. Mon webmaster Benjamin vous lira.
Muriel
Voici ce qui m’est arrivé. Démarrer un nouveau serveur et restaurer à partir de la sauvegarde était la seule option.
Il va à l’essentiel. Et ne perdez pas votre temps à déboguer. Ce conseil vous fait avancer en un rien de temps.
J’ai fini par effectuer la sauvegarde et la restauration, et cela a fonctionné comme prévu.
Pour référence, au cas où quelqu’un d’autre rencontrerait un problème similaire…
J’ai rencontré un petit problème au début, car le processus de restauration appelle apparemment uploads:migrate_to_s3 en interne et cela restait bloqué.
2025-02-26 00:24:16] Migrating the database...
[2025-02-26 00:24:24]
[2025-02-26 00:24:24] Reconnecting to the database...
[2025-02-26 00:24:24] Reloading site settings...
[2025-02-26 00:24:24] Disabling outgoing emails for non-staff users...
[2025-02-26 00:24:24] Disabling readonly mode...
[2025-02-26 00:24:24] Clearing category cache...
[2025-02-26 00:24:24] Reloading translations...
[2025-02-26 00:24:24] Remapping uploads...
[2025-02-26 00:24:24] Restoring uploads, this may take a while...
[2025-02-26 00:25:09] EXCEPTION: 12 of 12208 uploads are not migrated to S3. S3 migration failed for db 'default'.
[2025-02-26 00:25:09] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:73:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:383:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:354:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-02-26 00:25:09] Trying to rollback...
[2025-02-26 00:25:09] Rolling back...
[2025-02-26 00:25:10] Cleaning stuff up...
J’ai fini par exécuter quelques requêtes SQL dans le conteneur de données pour voir si je pouvais comprendre ce qui se passait.
./launcher enter data
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%s3%';
Cela n’a renvoyé que des éléments intégrés standard de Discourse, j’ai donc essayé l’inverse :
SELECT url from uploads where url LIKE '%s3%' limit 10;
Cela m’a donné un tas de correspondances dans le format :
//{my-bucket-name}.s3.dualstack.us-east-2.amazonaws.com/original/2X/5/{image-id}.jpeg
J’ai ensuite essayé une requête pour obtenir tout sauf les éléments qui correspondaient à cet hôte s3.dualstack et j’ai découvert qu’il y avait 12 anciennes entrées utilisant un format légèrement différent (correspondant au nombre qui a échoué lors de l’échec du journal de restauration précédent).
//{my-bucket-name}.s3-us-east-2.amazonaws.com/{file-path}.jpeg
Lorsque j’ai vérifié l’existence de ces fichiers dans le bucket réel, ils n’existaient pas, j’ai donc fini par les supprimer avec quelque chose comme :
DELETE FROM uploads where url LIKE '%{my-bucket-name}.s3-us-east-2.amazonaws.com%';
Après cela, la sauvegarde et la restauration ont fonctionné comme prévu !
PS. N’oubliez pas de réactiver les e-mails après avoir restauré la sauvegarde !
/admin/site_settings/category/all_results?filter=disable_email
2 messages ont été déplacées vers un nouveau sujet : Problème de mise à jour d’un site de 10 ans
