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
Nach Deaktivierung der Plugins funktioniert es wieder normal, aber ich kann nicht feststellen, welches Plugin das Problem verursacht. Können Sie mir dabei helfen?
Das Problem besteht weiterhin, wenn „Nicht-offizielle Client-Plugin-Anpassungen deaktivieren“ im abgesicherten Modus ausgewählt ist, funktioniert es jedoch ordnungsgemäß, wenn „Alle Client-Plugin-Anpassungen deaktivieren“ ausgewählt ist.
Können Sie versuchen, einen Kommandozeilen-Neubau durchzuführen, wie in der obigen Antwort vorgeschlagen? Das wird das Problem wahrscheinlich beheben, ich habe noch nie ein Problem bei Versionssprüngen gesehen.
Welcher Befehl ist das genau? Mein Dienst wird als Docker-Image verpackt und dann in einem entfernten Server-K8s-Cluster bereitgestellt. Die Bereitstellung erfolgt im web_only-Modus.
Außerdem tritt bei einem Fehler auf der Administratorseite folgende Fehlermeldung auf:
Gehen Sie zu dem Ort, an dem Sie Discourse installiert haben, und geben Sie dort ./launcher rebuild app ein – also dort, wo sich discourse_docker befindet. Ich glaube, /var/discourse ist der „empfohlene“ Ort für das Skript, aber das könnte bei Ihnen anders sein.
Das wird nicht unterstützt. Sie müssen etwas tun, um das neueste Image zu laden. Sie müssen die Datenbank migrieren. Normalerweise gibt es kein Problem, mehrere Versionen zu überspringen.
Es scheint, als wäre die Datenbankmigration fehlgeschlagen. Der folgende Fehler wurde gemeldet.
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
Als ich den spezifischen pnpm-Pfad überprüfte, stellte ich fest, dass der Pfad existiert, aber die Datei pnpm.cjs keine Ausführungsberechtigung hatte, was den Fehler verursachte.
Nachdem ich dann in dem Image mit corepack die entsprechende Version von pnpm vorinstalliert hatte, war die Datenbankmigration erfolgreich. Der Dienst läuft jetzt normal.
