loader.js:247 Uncaught (in promise) Error: Could not find module discourse/admin/models/admin-plugin imported from discourse/plugins/docker_manager/discourse/models/repo
at loader.js:247:1
at a (loader.js:258:1)
at s.findDeps (loader.js:168:1)
at a (loader.js:262:1)
at s.findDeps (loader.js:168:1)
at a (loader.js:262:1)
at requireModule (loader.js:24:1)
at n.i [as getRoute] (index.ts:121:18)
at p._getQPMeta (index.ts:101:20)
(anonymous) @ loader.js:247
a @ loader.js:258
(anonymous) @ loader.js:168
a @ loader.js:262
(anonymous) @ loader.js:168
a @ loader.js:262
requireModule @ loader.js:24
i @ index.ts:121
_getQPMeta @ index.ts:101
La désactivation des plugins a résolu le problème, mais je n’arrive pas à identifier quel plugin est en cause. Pourriez-vous m’aider à examiner cela ?
Le problème persiste lorsque « Désactiver les personnalisations des plugins clients non officiels » est sélectionné en mode sans échec, mais fonctionne correctement lorsque « Désactiver toutes les personnalisations des plugins clients » est sélectionné.
Pouvez-vous essayer une reconstruction depuis la ligne de commande comme suggéré dans la réponse ci-dessus ? Cela résoudra probablement le problème, je n’ai jamais vu de problème causé par des sauts de version…
Quelle est la commande exacte ? Mon service est empaqueté dans une image Docker, puis déployé dans un cluster k8s sur un serveur distant. J’utilise le déploiement en mode web_only.
De plus, voici l’erreur qui apparaît lors d’un problème sur la page d’administration :
Allez à l’endroit où vous avez installé Discourse et tapez ./launcher rebuild app - là où se trouve discourse_docker. Je crois que /var/discourse est l’endroit « recommandé » pour placer le script, mais cela pourrait être différent pour vous.
Ce n’est pas pris en charge. Vous devrez faire quelque chose pour charger la dernière image. Vous devrez migrer la base de données. Il n’y a généralement aucun problème à mettre à niveau plusieurs versions.
Il semble que la migration de la base de données ait échoué. L’erreur suivante a été signalée.
> TOP => db:migrate => assets:precompile:asset_processor │
> │ full trace by running task with --trace) │
> │ executing /etc/runit/1.d/00-ensure-links │
> │ executing /etc/runit/1.d/01-cleanup-web-pids │
> │ executing /etc/runit/1.d/anacron │
> │ executing /etc/runit/1.d/cleanup-pids │
> │ stale PID files │
> │ executing /etc/runit/1.d/copy-env │
> │ runsvdir, PID is 1126 │
> │ aborted! │
> │ pnpm -C=frontend/asset-processor node build.js (Discourse::Utils::CommandError) │
> │ Failed to switch pnpm to v10.28.0. Looks like pnpm CLI is missing at "/home/discourse/.local/share/pnpm/.tools/pnpm/10.28.0/bin" or is incorrect │
> │ /home/discourse/.local/share/pnpm/.tools/pnpm/10.28.0/bin/pnpm EACCES
Lorsque j’ai vérifié le chemin spécifique de pnpm, j’ai constaté que le chemin existait, mais que le fichier pnpm.cjs n’avait pas les droits d’exécution, ce qui a provoqué l’erreur.
Plus tard, après avoir préinstallé la version correspondante de pnpm en utilisant corepack dans l’image, la migration de la base de données a réussi. Le service fonctionne maintenant normalement.
