Funciones de administrador

Hola, cuando intento conectarme a la interfaz de administración, obtengo una pantalla en blanco. No puedo hacer actualizaciones, por ejemplo, aunque soy administrador.
¿Qué debo hacer?
Gracias por tu ayuda.
Muriel

1 me gusta

Es posible que intentes el modo seguro. También podrías hacer bien en realizar una actualización desde la línea de comandos.

3 Me gusta

Actualización: Realicé un bootstrap adecuado, destruí e inicié con una configuración de 2 contenedores y ahora los números de versión informados se han actualizado y la Interfaz de Administración se está renderizando de nuevo.

El resto de la publicación queda para la posteridad.


Estoy experimentando lo que puede ser un problema similar. La interfaz de Administración se carga, pero solo muestra las pestañas en la parte superior y la sección de contenido principal está en blanco:

Registros de la Consola del Navegador

Al revisar los registros de la consola del navegador, veo errores como:

[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`
Pila de Errores
[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)

Proceso de Actualización (2 contenedores)

Originalmente comencé a experimentar el problema después de intentar completar la actualización desde la interfaz de Administración de Discourse, donde se me indicó que necesitaba actualizar primero el Administrador de Docker.

Después de actualizar el Administrador de Docker, comencé a experimentar ese problema, así que me conecté por SSH a la máquina e hice una actualización manual (de 2 contenedores) solo para web_only:

cd /var/discourse
git pull
./launcher bootstrap web_only
./launcher stop web_only && ./launcher start web_only
           ^^^^^^
    ⚠️ ¡Esto es incorrecto! Usa destroy como se indica abajo. ⚠️

Curiosamente, la ruta /about.json todavía muestra que estoy ejecutando 3.4.0.beta4-dev, que es lo que pensé que había iniciado, ya que el correo original era para una actualización de 3.4.0.beta4-dev a 3.5.0.beta1.

Verifiqué el registro de git y parece que al menos discourse_docker está en el último commit 3715498fc188d60c0b579443383c4e973cf26f59 en el momento de escribir esto.

El Modo Seguro Funciona

No era consciente del modo seguro, pero aparentemente el problema no ocurre si deshabilito TODOS los plugins del lado del cliente.

Deshabilitar solo las personalizaciones de plugins no oficiales del lado del cliente no resuelve el problema, ya que probé cada combinación para acotar el problema.

Opción Resultado
no_unofficial_plugins :cross_mark:
no_plugins :white_check_mark:
no_themes :cross_mark:

Deshabilitar docker_manager no ayuda

Intenté comentar el plugin docker_manager en hooks/after_code, luego reconstruir el contenedor web_only y detener e iniciar, pero el mensaje de error del lado del cliente mencionado anteriormente todavía permanece.

Introduce otro mensaje de error que al visitar la página de Administración de this.class.create no es una función, pero quizás eso sea esperado con el plugin docker_manager subyacente deshabilitado para esta prueba:

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)

De nuevo, usar el modo seguro con no_plugins soluciona temporalmente el problema.

Estaba recordando los comandos para la actualización mínima de tiempo de inactividad de 2 contenedores y, al parecer, ¡mi memoria no se puede confiar! :flushed_face:

Después de usar el comando adecuado para destruir y luego iniciar el nuevo contenedor después del bootstrap, veo que las versiones están actualizadas y la Interfaz de Administración funciona como se esperaba.

¿Actualizaste el contenedor de datos? Deberías hacerlo, pero primero, consulta Actualización de PostgreSQL 15. O, si realmente odias leer, simplemente ejecuta ./laumcher rebuild data dos veces y deberías estar bien. Luego, deberás destruir e iniciar el contenedor web (de lo contrario, buscará el contenedor de datos antiguo que habrás destruido).

Todavía no, ¡pero gracias por estar pendiente!

Ya estaba considerando configurar un nuevo servidor más potente, así que solo estaba investigando para ver si podía hacer una copia de seguridad desde Discourse 3.5 + PG13 y luego restaurarla en Discourse 3.5 + PG15 en un host diferente.

No me gusta el tiempo de inactividad prolongado y, en el pasado, temporalmente puse la comunidad en modo de solo lectura e hice una copia de seguridad/restauración entre instancias de servidor y fue efectivamente sin tiempo de inactividad (aparte del período de solo lectura, por supuesto)… así que pensé en investigar/probar para ver si funciona entre versiones de PG.

De lo contrario, simplemente asumiré el problema y haré primero la actualización de PG15 antes de la migración del servidor. :slight_smile:

1 me gusta

Sí funciona. Probablemente ya sea hora de actualizar tu sistema operativo. Simplemente inicia un nuevo servidor y restaura tu copia de seguridad.

2 Me gusta

Tengo exactamente el mismo problema. Gracias por tu ayuda. Mi webmaster, Benjamin, te leerá.
Muriel

Esto fue lo que me pasó a mí. Crear un nuevo servidor y restaurar desde la copia de seguridad fue la única opción.
Es directo al grano. Y no pierdas tiempo en depurar. Este consejo te hace avanzar en muy poco tiempo.

Al final hice la copia de seguridad y la restauración y funcionó como esperaba.


Como referencia, en caso de que alguien más se encuentre con un problema similar…

Al principio tuve un pequeño problema, ya que el proceso de restauración aparentemente llama internamente a uploads:migrate_to_s3 y se quedó colgado.

[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...

Terminé ejecutando algunas consultas SQL en el contenedor de datos para ver si podía averiguar qué estaba pasando.

./launcher enter data
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%s3%';

Eso solo devolvió algunos elementos integrados estándar de Discourse, así que probé lo contrario:

SELECT url from uploads where url LIKE '%s3%' limit 10;

Eso me dio un montón de coincidencias en el formato:

  • //{my-bucket-name}.s3.dualstack.us-east-2.amazonaws.com/original/2X/5/{image-id}.jpeg

Así que luego probé una consulta para obtener todo excepto los elementos que coincidían con ese host s3.dualstack y descubrí que había 12 entradas antiguas que usaban un formato ligeramente diferente (coincidiendo con el número que falló del registro de restauración anterior).

  • //{my-bucket-name}.s3-us-east-2.amazonaws.com/{file-path}.jpeg

Cuando verifiqué la existencia de esos archivos en el bucket real, no existían, así que terminé eliminándolos con algo como:

DELETE FROM uploads where url LIKE '%{my-bucket-name}.s3-us-east-2.amazonaws.com%';

¡Después de eso, la copia de seguridad y la restauración funcionaron como se esperaba!

PD. ¡No olvides reactivar los correos electrónicos después de restaurar la copia de seguridad!

/admin/site_settings/category/all_results?filter=disable_email
4 Me gusta

2 publicaciones se dividieron en un nuevo tema: Problemas al actualizar un sitio de 10 años