Conectando WP Discourse a una instancia de Discourse local que ejecuta una versión específica

[Gregory_Bartholomew]

Acabo de intentar instalar este plugin en WordPress 6.7.2 con php-fpm-8.3.17-1.fc41.x86_64, pero no funciona. Obtengo el siguiente error en el registro cuando hago clic en “Guardar Opciones”.

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Se devolvió una respuesta no válida de Discourse","http_code":"","http_body":""} 

Hay errores correspondientes en /var/log/php-fpm/www-error.log:

[21-Feb-2025 17:14:42 UTC] PHP Warning:  Undefined array key "url" in /wordpress/wp-content/plugins/wp-discourse/lib/discourse.php on line 301

Veo que el mismo error se informa en la “prueba de humo” en Report - WP-Discourse 2.5.9 - PluginTests.com.

Editar: Olvídense del error de url indefinida. Parece que fue solo un error inicial de antes de completar el formulario web. Sin embargo, sigo recibiendo el error wpdc_response_error repetidamente cada vez que hago clic en el botón Guardar Opciones.

Editar2: Estoy viendo un 403 prohibido en el lado de Discourse, pero no está claro por qué la conexión desde mi sitio de WordPress está siendo prohibida. Puedo usar la misma clave API con éxito con curl.

Completed 403 Forbidden in 33ms (Views: 0.3ms | ActiveRecord: 15.1ms (2 queries, 0 cached) | GC: 2.2ms)

Estoy ejecutando Discourse 3.5.0.beta1-dev en modo de desarrollo.

Editar3: Descubrí que hay permisos especiales de WordPress para la clave API en esta versión de Discourse. Usar “Granular” en lugar de “Global” y marcar las casillas debajo de WordPress eliminó los errores 403 Forbidden. Sin embargo, todavía estoy recibiendo respuestas vacías/inválidas enviadas a WordPress.

Delivering messages [] to client d9fbb33f11ed404bbc361c459802c87d for user 1 (chunked)

Supongo que necesito usar una versión anterior de Discourse con el plugin de WordPress. ¿Cuál es la última versión con la que funciona?

[angus (Angus McLeod)]

Hola @Gregory_Bartholomew, veamos si podemos llegar al fondo de tu problema.

@Gregory_Bartholomew

¿Cuál es la última versión con la que funciona?

Funciona con la última versión de Discourse.

@Gregory_Bartholomew

Estoy ejecutando Discourse 3.5.0.beta1-dev en modo de desarrollo.

Cuando dices que estás ejecutando Discourse “en modo de desarrollo”, ¿quieres decir que lo estás ejecutando localmente? Si no, ¿en qué entorno lo estás ejecutando?

Antes de intentar usar una clave con permisos granulares, ¿podrías intentar usar una clave global como se muestra en el video de la primera publicación?

[Gregory_Bartholomew]

Gracias. Ahora estoy intentando reinstalar Discourse. He descargado la versión 3.3.0 para probar.

Estoy intentando instalar Discourse localmente en lugar de usar el contenedor Docker debido a un error en ZFS que impide que el contenedor Docker se construya correctamente en sistemas de archivos ZFS (problema de pnpm 7024). Si instalo Discourse localmente, puedo solucionar el error de ZFS añadiendo package-import-method=hardlink a .npmrc antes de ejecutar pnpm install.

@angus

Cuando dices que estás ejecutando Discourse “en modo de desarrollo”, ¿quieres decir que lo estás ejecutando localmente? Si no es así, ¿en qué entorno lo estás ejecutando?

Me refiero a que tenía RAILS_ENV=development. Ahora voy a intentarlo de nuevo con RAILS_ENV=production.

Además, estoy intentando rehacer la guía que enlacé arriba para que funcione en Fedora Linux.

Editar: No estoy teniendo mucha suerte con la versión 3.3.0.

$ pnpm install
 WARN  El campo "workspaces" en package.json no es compatible con pnpm. Crea un archivo "pnpm-workspace.yaml" en su lugar.
 ERR_PNPM_INVALID_SELECTOR  No se puede analizar el selector "**/unset-value"

Supongo que lo intentaré de nuevo con la 3.4.0 y veré qué tal va.

[Gregory_Bartholomew]

Bueno, reinstalé Discourse en la versión 3.4.0:

Sin embargo, no pude conseguir que funcionara en modo de producción. No estoy seguro de por qué. Simplemente decía “Oops…” y no había mucho que pudiera ver en los registros. Creo que el problema podría haber estado relacionado con algunas configuraciones de proxy, pero no estoy seguro.

De todos modos, volví a configurar RAILS_ENV en “development” y funcionó. Sin embargo, sigo recibiendo el mismo error cuando intento conectarme desde WordPress:

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Se devolvió una respuesta no válida desde Discourse","http_code":"","http_body":""}

Sin embargo, puedo ver que las consultas llegan a Discourse, así que no entiendo por qué no funciona.

GET "/site.json" para 000.123.456.789 a las 2025-02-21 16:11:05 -0600
10:11 pm
Procesando SiteController#site como JSON
10:11 pm
ApiKey Load (9.0ms) SELECT "api_keys".* FROM "api_keys" WHERE (revoked_at IS NULL) AND "api_keys"."key_hash" = '3f27a89fedae42123b9ad596fae6c06d36748f53bd241213941083af49cf5e46' ORDER BY "api_keys"
10:11 pm
ApiKeyScope Load (10.6ms) SELECT "api_key_scopes".* FROM "api_key_scopes" WHERE "api_key_scopes"."api_key_id" = 1
10:11 pm
User Load (8.1ms) SELECT "users"."id", "users"."username", "users"."created_at", "users"."updated_at", "users"."name", "users"."last_posted_at", "users"."active", "users"."username_lower", "users".
10:11 pm
UserOption Load (6.1ms) SELECT "user_options"."user_id", "user_options"."mailing_list_mode", "user_options"."email_digests", "user_options"."external_links_in_new_tab", "user_options"."enable_quoti
10:11 pm
Group Load (8.6ms) SELECT "groups"."id", "groups"."name", "groups"."flair_icon", "groups"."flair_upload_id", "groups"."flair_bg_color", "groups"."flair_color" FROM "groups" ORDER BY groups.name ASC
10:11 pm
(7.0ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = FALSE
10:11 pm
(10.7ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = TRUE
10:11 pm
Topic Count (4.1ms) SELECT COUNT(*) FROM (SELECT 1 AS one FROM "topics" WHERE "topics"."deleted_at" IS NULL LIMIT 16) subquery_for_count
10:11 pm
(6.1ms) SELECT "users"."id" FROM "users" INNER JOIN "user_auth_tokens" ON "user_auth_tokens"."user_id" = "users"."id" WHERE "users"."admin" = TRUE AND (users.id > 0) ORDER BY user_auth_tokens.crea
10:11 pm
(8.5ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."topic_featured_link_allowed" = TRUE
10:11 pm
ColorScheme Load (6.8ms) SELECT "color_schemes".* FROM "color_schemes" WHERE (color_schemes.id NOT IN (SELECT color_scheme_id FROM theme_color_schemes)) AND "color_schemes"."id" = 1 LIMIT 1
10:11 pm
ColorSchemeColor Load (7.8ms) SELECT "color_scheme_colors".* FROM "color_scheme_colors" WHERE "color_scheme_colors"."color_scheme_id" = 1 ORDER BY id ASC
10:11 pm
(6.0ms) SELECT "group_users"."group_id" FROM "group_users" WHERE "group_users"."user_id" = -1
10:11 pm
(8.0ms) SELECT "category_users"."category_id", "category_users"."notification_level" FROM "category_users" WHERE "category_users"."user_id" = -1
10:11 pm
UserField Load (9.5ms) SELECT "user_fields"."id", "user_fields"."name", "user_fields"."created_at", "user_fields"."updated_at", "user_fields"."editable", "user_fields"."description", "user_fields".
10:11 pm
Completado 200 OK en 256ms (Vistas: 0.3ms | ActiveRecord: 116.4ms (15 consultas, 0 en caché) | GC: 94.6ms)

Creo que me tomaré un descanso de esto por un tiempo, pero si tienes alguna idea de lo que podría estar saliendo mal, agradecería algunas pistas.

[angus (Angus McLeod)]

He movido esta conversación a un tema independiente ya que los problemas con los que estás lidiando pueden confundir a otras personas que ejecutan configuraciones estándar.

Ok, para recapitular,

1. Estás ejecutando Discourse en tu máquina local.
2. Estás ejecutando versiones específicas. Actualmente estás ejecutando la 3.4.0.
3. Estás intentando conectar tu instancia local a una instancia remota de Wordpress.

¿Algo de eso es incorrecto? Además, ¿podrías aclarar lo siguiente?

1. ¿Cómo te estás conectando a la instancia remota de Wordpress desde tu máquina local? ¿Estás usando ngrok?
2. ¿Por qué estás ejecutando versiones específicas de Discourse en lugar de la última versión?
3. ¿Cuál es tu objetivo general aquí?

[Gregory_Bartholomew]

@angus

1. Estás ejecutando Discourse en tu máquina local.

Sí.

@angus

2. Estás ejecutando versiones específicas. Actualmente estás ejecutando la versión 3.4.0.

Sí.

@angus

3. Estás intentando conectar tu instancia local a una instancia remota de WordPress.

Mi instancia de prueba de WordPress también se está ejecutando localmente.

@angus

1. ¿Cómo te estás conectando a la instancia remota de WordPress desde tu máquina local? ¿Estás usando ngrok?

No, todo es local. Tengo dos instancias de httpd ejecutándose y escuchando en diferentes direcciones IP (una para WordPress y la otra para Discourse). La instancia de WordPress se está ejecutando directamente en mi sistema anfitrión y la instancia de Discourse se está ejecutando en un contenedor systemd-nspawn. Tanto el sistema anfitrión como el contenedor están ejecutando Fedora Linux 41.

@angus

2. ¿Por qué estás ejecutando versiones específicas de Discourse en lugar de la última versión?

Inicialmente probé la instancia de Docker, pero no se compiló en mi máquina de prueba. La investigación del mensaje de error me llevó a un informe de error abierto que indicaba que el problema estaba con el sistema de archivos ZFS. No sé cómo modificar la imagen de Docker para aplicar la solución, así que encontré instrucciones para clonar el repositorio fuente y compilar Discourse con eso.

Inicialmente compilé la última versión (3.5.0.beta1-dev), pero el comportamiento parecía diferente a lo que mostraba tu video. Veía 403 Forbidden en los registros de Discourse cuando WordPress intentaba conectarse con la clave API (cuando los permisos estaban configurados como “Global”). Cambiar los permisos a “Granular” y marcar todas las casillas para WordPress permitía que las consultas avanzaran, pero WordPress recibía respuestas vacías/inválidas. Luego noté en https://blog.discourse.org/ que la última versión promocionada era la 3.4, así que concluí que algunos de los problemas que estaba encontrando podrían deberse a que estaba intentando ejecutar una versión preliminar. Probé git checkout v3.3.0 pensando que sería lo suficientemente antigua como para ser totalmente compatible con el plugin de WordPress que estoy intentando probar, pero no se compiló en mi sistema, así que hice checkout de la versión 3.4.0 y esa parece estar funcionando (aunque en modo “desarrollo”).

@angus

3. ¿Cuál es tu objetivo general aquí?

En realidad, solo quiero experimentar y familiarizarme con el plugin de Discourse para WordPress. Realmente no me importa Discourse en absoluto. Solo necesito algo contra lo que probar. Una vez que me sienta cómodo con cómo funciona todo, podría intentar instalar el plugin en un sitio de producción (fedoramagazine.org) y redirigir los comentarios a la instancia de producción de Discourse en discussion.fedoraproject.org.

[Canapin (Coin-coin le Canapin)]

@Gregory_Bartholomew

Realmente no me importa Discourse en absoluto

¡Eso es lo más triste que he leído en este foro!

[angus (Angus McLeod)]

El problema tendrá que ver con tu configuración local y tu red. No se deberá a la versión de Discourse ni a la diferencia entre claves globales y granulares. Me resultará difícil depurar los problemas de interconexión de tu aplicación local, especialmente debido a la variedad de formas y entornos en los que puedes ejecutar tanto Wordpress como Discourse localmente. Aquí tienes algunos consejos para ayudarte.

1. Ejecuta siempre la última versión de Discourse, Wordpress y el plugin WP Discourse.
2. Utiliza el puerto 3000 en lugar del puerto 4200 en la URL de Discourse local en WP Discourse.
3. Asegúrate de que la clave que creas pueda ser utilizada por el nombre de usuario administrador que has establecido como Nombre de usuario de publicación.

Así es como se ve mi configuración local con mi Wordpress y Discourse locales conectados entre sí. Utilizo MAMP Pro para ejecutar Wordpress localmente.

[Gregory_Bartholomew]

¡Funcionó!

Gracias por el consejo de conectarme directamente al puerto 3000. Parece que eso fue lo que marcó la diferencia.

Algo a tener en cuenta (al menos en mi configuración local) es que también necesité establecer ALLOW_EMBER_CLI_PROXY_BYPASS=1 antes de iniciar ember-cli.