Connecter WP Discourse à une instance locale de Discourse exécutant une version spécifique

J’ai juste essayé d’installer ce plugin sur WordPress 6.7.2 avec php-fpm-8.3.17-1.fc41.x86_64, mais ça ne fonctionne pas. J’obtiens l’erreur suivante dans le journal lorsque je clique sur « Enregistrer les options ».

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Une réponse invalide a été retournée par Discourse","http_code":"","http_body":""} 

Il y a des erreurs correspondantes dans /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

Je vois que la même erreur est signalée dans le « test de fumée » sur Report - WP-Discourse 2.5.9 - PluginTests.com.

Modifier : Laissez tomber l’erreur d’URL indéfinie. Il semble que ce n’était qu’une erreur initiale avant que le formulaire web ne soit complété. Cependant, je reçois toujours le wpdc_response_error à plusieurs reprises, chaque fois que je clique sur le bouton Enregistrer les options.

Modifier2 : Je vois un 403 Forbidden du côté de Discourse, mais il n’est pas clair pourquoi la connexion de mon site WordPress est interdite. Je peux utiliser la même clé API avec succès avec curl.

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

J’exécute Discourse 3.5.0.beta1-dev en mode développement.

Modifier3 : J’ai découvert qu’il existe des autorisations WordPress spéciales pour la clé API dans cette version de Discourse. L’utilisation de « Granulaire » au lieu de « Global » et la coche des cases sous WordPress ont supprimé les erreurs 403 Forbidden. Cependant, je reçois toujours des réponses vides/invalides envoyées à WordPress.

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

Je suppose que je dois utiliser une version plus ancienne de Discourse avec le plugin WordPress. Quelle est la dernière version avec laquelle il fonctionne ?

Salut @Gregory_Bartholomew, voyons si nous pouvons résoudre votre problème.

Cela fonctionne avec la dernière version de Discourse.

Quand vous dites que vous exécutez Discourse “en mode développement”, voulez-vous dire que vous l’exécutez localement ? Sinon, sur quel environnement l’exécutez-vous ?

Avant d’essayer d’utiliser une clé avec des permissions granulaires, pourriez-vous essayer d’utiliser une clé globale comme montré dans la vidéo du premier message.

Merci. J’essaie de réinstaller Discourse maintenant. J’ai extrait la version 3.3.0 pour tester.

J’essaie d’installer Discourse localement au lieu d’utiliser le conteneur Docker en raison d’un bug dans ZFS qui empêche la construction réussie du conteneur Docker sur les systèmes de fichiers ZFS (pnpm issue 7024). Si j’installe Discourse localement, je peux contourner le bug ZFS en ajoutant package-import-method=hardlink à .npmrc avant d’exécuter pnpm install.

Je veux dire que j’avais RAILS_ENV=development. Je vais réessayer avec RAILS_ENV=production maintenant.

De plus, j’essaie de retravailler le guide que j’ai lié ci-dessus pour qu’il fonctionne sur Fedora Linux.

Edit : Je n’ai pas beaucoup de succès avec la version 3.3.0.

$ pnpm install
 WARN  Le champ "workspaces" dans package.json n'est pas pris en charge par pnpm. Créez plutôt un fichier "pnpm-workspace.yaml".
 ERR_PNPM_INVALID_SELECTOR  Impossible d'analyser le sélecteur "**/unset-value"

Je suppose que je vais réessayer avec la version 3.4.0 et voir comment cela se passe. :confused:

Eh bien, j’ai réinstallé Discourse en version 3.4.0 :

Cependant, je n’ai pas réussi à le faire fonctionner en mode production. Je ne sais pas pourquoi. Il disait juste “Oups…” et il n’y avait pas grand-chose que je pouvais voir dans les journaux. Je pense que le problème était peut-être lié à certains paramètres de proxy, mais je ne suis pas sûr.

Quoi qu’il en soit, j’ai rétabli RAILS_ENV à “development” et cela a démarré. Cependant, j’obtiens toujours la même erreur lorsque j’essaie de me connecter depuis WordPress :

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Une réponse invalide a été retournée par Discourse","http_code":"","http_body":""} 

Je peux voir les requêtes atteindre Discourse cependant, donc je ne comprends pas pourquoi cela ne fonctionne pas.

GET "/site.json" pour 000.123.456.789 à 2025-02-21 16:11:05 -0600
22:11
Traitement de SiteController#site en JSON
22:11
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"
22:11
ApiKeyScope Load (10.6ms) SELECT "api_key_scopes".* FROM "api_key_scopes" WHERE "api_key_scopes"."api_key_id" = 1
22:11
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".
22:11
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
22:11
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
22:11
(7.0ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = FALSE
22:11
(10.7ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = TRUE
22:11
Topic Count (4.1ms) SELECT COUNT(*) FROM (SELECT 1 AS one FROM "topics" WHERE "topics"."deleted_at" IS NULL LIMIT 16) subquery_for_count
22:11
(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
22:11
(8.5ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."topic_featured_link_allowed" = TRUE
22:11
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
22:11
ColorSchemeColor Load (7.8ms) SELECT "color_scheme_colors".* FROM "color_scheme_colors" WHERE "color_scheme_colors"."color_scheme_id" = 1 ORDER BY id ASC
22:11
(6.0ms) SELECT "group_users"."group_id" FROM "group_users" WHERE "group_users"."user_id" = -1
22:11
(8.0ms) SELECT "category_users"."category_id", "category_users"."notification_level" FROM "category_users" WHERE "category_users"."user_id" = -1
22:11
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".
22:11
Terminé 200 OK en 256ms (Vues : 0.3ms | ActiveRecord : 116.4ms (15 requêtes, 0 mises en cache) | GC : 94.6ms)

Je pense que je vais faire une pause là-dessus pendant un moment, mais si vous avez une idée de ce qui pourrait clocher, j’apprécierais quelques indices. :slightly_smiling_face:

J’ai déplacé cette conversation vers un sujet indépendant car les problèmes que vous rencontrez pourraient embrouiller d’autres personnes qui utilisent des configurations standard.

Ok, pour résumer,

  1. Vous exécutez Discourse sur votre machine locale.
  2. Vous utilisez des versions spécifiques. Vous utilisez actuellement la version 3.4.0.
  3. Vous essayez de connecter votre instance locale à une instance distante de Wordpress.

Est-ce que l’un de ces points est incorrect ? De plus, pourriez-vous clarifier les points suivants :

  1. Comment vous connectez-vous à l’instance distante de Wordpress depuis votre machine locale ? Utilisez-vous ngrok ?
  2. Pourquoi utilisez-vous des versions spécifiques de Discourse au lieu de la dernière version ?
  3. Quel est votre objectif général ici ?
2 « J'aime »

Oui.

Oui.

Mon instance WordPress de test s’exécute également localement.

Non, tout est local. J’ai deux instances de httpd en cours d’exécution et écoutant sur différentes adresses IP (une pour WordPress et l’autre pour Discourse). L’instance WordPress s’exécute directement sur mon système hôte et l’instance Discourse s’exécute dans un conteneur systemd-nspawn. Le système hôte et le conteneur exécutent tous deux Fedora Linux 41.

J’ai d’abord essayé l’instance Docker, mais elle ne parvenait pas à compiler sur ma machine de test. La recherche du message d’erreur m’a conduit à un rapport de bug ouvert indiquant que le problème venait du système de fichiers ZFS. Je ne sais pas comment modifier l’image Docker pour appliquer la solution de contournement, j’ai donc trouvé des instructions pour cloner le dépôt source et compiler Discourse avec.

J’ai d’abord compilé la dernière version (3.5.0.beta1-dev), mais le comportement semblait différent de ce que votre vidéo montrait. Je voyais 403 Forbidden dans les logs de Discourse lorsque WordPress essayait de se connecter avec la clé API (lorsque les permissions étaient définies sur “Global”). Changer les permissions sur “Granular” et cocher toutes les cases pour WordPress permettait aux requêtes de progresser davantage, mais WordPress recevait des réponses vides/invalides. J’ai ensuite remarqué sur https://blog.discourse.org/ que la dernière version promue était la 3.4, j’ai donc conclu que certains des problèmes que je rencontrais pouvaient être dus au fait que j’essayais d’exécuter une pré-version. J’ai essayé git checkout v3.3.0 en pensant qu’elle serait assez ancienne pour être entièrement compatible avec le plugin WordPress que j’essaie de tester, mais elle ne compilait pas sur mon système, j’ai donc vérifié la version 3.4.0 et cela semble fonctionner (bien qu’en mode “développement”).

En fait, je veux juste expérimenter et me familiariser avec le plugin WordPress Discourse. Je ne me soucie pas vraiment de Discourse. J’ai juste besoin de quelque chose pour tester. Une fois que je serai à l’aise avec son fonctionnement, je pourrais essayer d’installer le plugin sur un site de production (fedoramagazine.org) et rediriger les commentaires vers l’instance Discourse de production à l’adresse discussion.fedoraproject.org.

1 « J'aime »

C’est la chose la plus triste que j’aie jamais lue sur ce forum ! :lolsob:

1 « J'aime »

Le problème sera lié à votre configuration locale et à votre réseau. Il ne sera pas dû à la version de Discourse, ni à la différence entre les clés globales et granulaires. Il me sera difficile de déboguer les problèmes d’interconnexion de votre application locale, en particulier en raison de la variété des méthodes et des environnements dans lesquels vous pouvez exécuter Wordpress et Discourse localement. Voici quelques conseils pour vous aider.

  1. Exécutez toujours la dernière version de Discourse, Wordpress et du plugin WP Discourse.
  2. Utilisez le port 3000 au lieu du port 4200 dans l’URL Discourse locale dans WP Discourse.
  3. Assurez-vous que la clé que vous créez peut être utilisée par le nom d’utilisateur administrateur que vous avez défini comme nom d’utilisateur de publication.

Voici à quoi ressemble ma configuration locale avec mon Wordpress et Discourse locaux connectés l’un à l’autre. J’utilise MAMP Pro pour exécuter Wordpress localement.


3 « J'aime »

Ça a marché !!!

Merci pour le conseil de se connecter directement au port 3000. Cela semble être ce qui a fait la différence.

Une chose à noter (du moins dans ma configuration locale) est que j’ai également dû définir ALLOW_EMBER_CLI_PROXY_BYPASS=1 avant de démarrer ember-cli.

3 « J'aime »