Verbinden von WP Discourse mit einer lokalen Discourse-Instanz, die eine bestimmte Version ausführt

[Gregory_Bartholomew]

Ich habe gerade versucht, dieses Plugin unter WordPress 6.7.2 mit php-fpm-8.3.17-1.fc41.x86_64 zu installieren, aber es funktioniert nicht. Ich erhalte die folgende Fehlermeldung im Log, wenn ich auf “Optionen speichern” klicke.

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Eine ungültige Antwort wurde von Discourse zurückgegeben","http_code":"","http_body":""} 

Es gibt entsprechende Fehler in /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

Ich sehe, dass derselbe Fehler im “Rauchtest” unter Report - WP-Discourse 2.5.9 - PluginTests.com gemeldet wird.

Bearbeiten: Vergessen Sie den Fehler “Undefined url”. Es scheint, dass dies nur ein anfänglicher Fehler war, bevor das Webformular ausgefüllt wurde. Ich erhalte jedoch immer wieder die wpdc_response_error, jedes Mal, wenn ich auf die Schaltfläche “Optionen speichern” klicke.

Bearbeiten2: Ich sehe eine 403 Forbidden-Meldung auf der Discourse-Seite, aber es ist mir nicht klar, warum die Verbindung von meiner WordPress-Site verboten wird. Ich kann denselben API-Schlüssel erfolgreich mit curl verwenden.

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

Ich betreibe Discourse 3.5.0.beta1-dev im Entwicklungsmodus.

Bearbeiten3: Ich habe festgestellt, dass es in dieser Version von Discourse spezielle WordPress-Berechtigungen für den API-Schlüssel gibt. Die Verwendung von “Granular” anstelle von “Global” und das Ankreuzen der Felder unter WordPress hat die 403 Forbidden-Fehler beseitigt. Ich erhalte jedoch immer noch leere/ungültige Antworten, die an WordPress gesendet werden.

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

Ich schätze, ich muss eine ältere Version von Discourse mit dem WordPress-Plugin verwenden. Was ist die neueste Version, mit der es funktioniert?

[angus (Angus McLeod)]

Hallo @Gregory_Bartholomew, mal sehen, ob wir Ihr Problem lösen können.

@Gregory_Bartholomew

Mit welcher neuesten Version funktioniert es?

Es funktioniert mit der neuesten Version von Discourse.

@Gregory_Bartholomew

Ich betreibe Discourse 3.5.0.beta1-dev im Entwicklungsmodus.

Wenn Sie sagen, dass Sie Discourse „im Entwicklungsmodus“ betreiben, meinen Sie dann, dass Sie es lokal ausführen? Wenn nicht, in welcher Umgebung führen Sie es aus?

Könnten Sie bitte versuchen, einen globalen Schlüssel zu verwenden, wie im Video im ersten Beitrag gezeigt, bevor Sie versuchen, einen Schlüssel mit granularen Berechtigungen zu verwenden?

[Gregory_Bartholomew]

Danke. Ich versuche jetzt, Discourse neu zu installieren. Ich habe Version 3.3.0 zum Testen ausgecheckt.

Ich versuche, Discourse lokal zu installieren, anstatt den Docker-Container zu verwenden, aufgrund eines Fehlers in ZFS, der den Docker-Container auf ZFS-Dateisystemen am Erstellen hindert (pnpm issue 7024). Wenn ich Discourse lokal installiere, kann ich den ZFS-Fehler umgehen, indem ich package-import-method=hardlink zu .npmrc hinzufüge, bevor ich pnpm install ausführe.

@angus

Wenn Sie sagen, Sie führen Discourse „im Entwicklungsmodus“ aus, meinen Sie, dass Sie es lokal ausführen? Wenn nicht, in welcher Umgebung führen Sie es aus?

Ich meine, ich hatte RAILS_ENV=development. Ich werde es jetzt mit RAILS_ENV=production erneut versuchen.

Außerdem versuche ich, die obige Anleitung zu überarbeiten, damit sie unter Fedora Linux funktioniert.

Bearbeiten: Ich habe mit Version 3.3.0 nicht viel Glück.

$ pnpm install
 WARN  Das Feld "workspaces" in package.json wird von pnpm nicht unterstützt. Erstellen Sie stattdessen eine "pnpm-workspace.yaml"-Datei.
 ERR_PNPM_INVALID_SELECTOR  Kann den Selektor "**/unset-value" nicht parsen

Ich werde es wohl noch einmal mit 3.4.0 versuchen und sehen, wie das läuft.

[Gregory_Bartholomew]

Nun, ich habe Discourse in Version 3.4.0 neu installiert:

Ich konnte es jedoch nicht im Produktionsmodus zum Laufen bringen. Ich bin mir nicht sicher, warum. Es sagte nur „Hoppla …“ und in den Protokollen gab es nicht viel zu sehen. Ich glaube, das Problem hatte etwas mit Proxy-Einstellungen zu tun, aber ich bin mir nicht sicher.

Auf jeden Fall habe ich RAILS_ENV wieder auf „development“ gesetzt und es startete. Ich erhalte jedoch immer noch denselben Fehler, wenn ich versuche, von WordPress aus eine Verbindung herzustellen:

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""} 

Ich kann jedoch sehen, dass die Abfragen Discourse erreichen. Daher verstehe ich nicht, warum es nicht funktioniert.

GET "/site.json" für 000.123.456.789 um 2025-02-21 16:11:05 -0600
22:11 Uhr
Processing by SiteController#site as JSON
22:11 Uhr
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 Uhr
ApiKeyScope Load (10.6ms) SELECT "api_key_scopes".* FROM "api_key_scopes" WHERE "api_key_scopes"."api_key_id" = 1
22:11 Uhr
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 Uhr
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 Uhr
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 Uhr
(7.0ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = FALSE
22:11 Uhr
(10.7ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = TRUE
22:11 Uhr
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 Uhr
(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 Uhr
(8.5ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."topic_featured_link_allowed" = TRUE
22:11 Uhr
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 Uhr
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 Uhr
(6.0ms) SELECT "group_users"."group_id" FROM "group_users" WHERE "group_users"."user_id" = -1
22:11 Uhr
(8.0ms) SELECT "category_users"."category_id", "category_users"."notification_level" FROM "category_users" WHERE "category_users"."user_id" = -1
22:11 Uhr
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 Uhr
Completed 200 OK in 256ms (Views: 0.3ms | ActiveRecord: 116.4ms (15 queries, 0 cached) | GC: 94.6ms)

Ich denke, ich mache eine Pause davon, aber wenn Sie eine Idee haben, was schief gehen könnte, würde ich mich über ein paar Hinweise freuen.

[angus (Angus McLeod)]

Ich habe dieses Gespräch in ein unabhängiges Thema verschoben, da die Probleme, mit denen Sie zu kämpfen haben, andere Personen, die Standardkonfigurationen verwenden, verwirren könnten.

Okay, um das zusammenzufassen:

1. Sie führen Discourse auf Ihrem lokalen Rechner aus.
2. Sie verwenden bestimmte Versionen. Sie verwenden derzeit 3.4.0.
3. Sie versuchen, Ihre lokale Instanz mit einer Remote-Wordpress-Instanz zu verbinden.

Ist davon etwas falsch? Könnten Sie außerdem Folgendes klären:

1. Wie verbinden Sie sich von Ihrem lokalen Rechner aus mit der Remote-Wordpress-Instanz? Verwenden Sie ngrok?
2. Warum verwenden Sie bestimmte Versionen von Discourse und nicht die neueste Version?
3. Was ist Ihr Gesamtziel hier?

[Gregory_Bartholomew]

@angus

1. Sie führen Discourse auf Ihrem lokalen Rechner aus.

Ja.

@angus

2. Sie führen bestimmte Versionen aus. Sie führen derzeit 3.4.0 aus.

Ja.

@angus

3. Sie versuchen, Ihre lokale Instanz mit einer Remote-WordPress-Instanz zu verbinden.

Meine Test-WordPress-Instanz läuft ebenfalls lokal.

@angus

1. Wie verbinden Sie sich von Ihrem lokalen Rechner mit der Remote-WordPress-Instanz? Verwenden Sie ngrok?

Nein, alles ist lokal. Ich habe zwei Instanzen von httpd laufen, die auf unterschiedlichen IP-Adressen lauschen (eine für WordPress und die andere für Discourse). Die WordPress-Instanz läuft direkt auf meinem Host-System und die Discourse-Instanz läuft in einem systemd-nspawn-Container. Sowohl das Host-System als auch der Container laufen unter Fedora Linux 41.

@angus

2. Warum führen Sie bestimmte Versionen von Discourse anstelle der neuesten Version aus?

Ich habe zunächst die Docker-Instanz ausprobiert, aber sie ließ sich auf meiner Testmaschine nicht erstellen. Die Recherche nach der Fehlermeldung führte mich zu einem offenen Bug-Report, der darauf hindeutete, dass das Problem beim ZFS-Dateisystem lag. Ich weiß nicht, wie ich das Docker-Image ändern kann, um den Workaround anzuwenden. Daher habe ich Anleitungen zum Klonen des Quell-Repositorys und zum Erstellen von Discourse damit gefunden.

Ich habe zunächst die neueste Version (3.5.0.beta1-dev) erstellt, aber das Verhalten schien anders zu sein als das, was Ihr Video zeigte. Ich erhielt 403 Forbidden in den Discourse-Protokollen, wenn WordPress versuchte, sich mit dem API-Schlüssel zu verbinden (wenn die Berechtigungen auf “Global” gesetzt waren). Das Ändern der Berechtigungen auf “Granular” und das Ankreuzen aller Felder für WordPress ermöglichte es den Abfragen, weiter fortzufahren, aber WordPress erhielt leere/ungültige Antworten. Ich bemerkte dann auf https://blog.discourse.org/, dass die neueste beworbene Version 3.4 war, also schloss ich, dass einige der Probleme, auf die ich stieß, möglicherweise darauf zurückzuführen waren, dass ich eine Vorabversion ausführen wollte. Ich habe git checkout v3.3.0 versucht, in der Annahme, dass sie alt genug sein würde, um vollständig mit dem WordPress-Plugin kompatibel zu sein, das ich testen möchte, aber es ließ sich auf meinem System nicht erstellen. Daher habe ich Version 3.4.0 ausgecheckt, und das scheint zu funktionieren (wenn auch im “Entwicklungs”-Modus).

@angus

3. Was ist Ihr übergeordnetes Ziel?

Eigentlich möchte ich nur mit dem WordPress Discourse-Plugin experimentieren und mich damit vertraut machen. Discourse ist mir eigentlich egal. Ich brauche nur etwas zum Testen. Sobald ich mich mit der Funktionsweise vertraut gemacht habe, werde ich vielleicht versuchen, das Plugin auf einer Produktionsseite (fedoramagazine.org) zu installieren und die Kommentare an die Produktions-Discourse-Instanz unter discussion.fedoraproject.org weiterzuleiten.

[Canapin (Coin-coin le Canapin)]

@Gregory Bartholomew

Ich kümmere mich wirklich nicht um Discourse

Das ist das Traurigste, was ich je in diesem Forum gelesen habe!

[angus (Angus McLeod)]

Das Problem wird mit Ihrem lokalen Setup und Netzwerk zusammenhängen. Es liegt nicht an der Version von Discourse oder dem Unterschied zwischen globalen und granularen Schlüsseln. Es wird für mich schwierig sein, Probleme mit der lokalen App-Interkonnektivität zu debuggen, insbesondere aufgrund der Vielzahl von Möglichkeiten und Umgebungen, in denen Sie sowohl WordPress als auch Discourse lokal ausführen können. Hier sind ein paar Tipps, die Ihnen helfen sollen.

1. Führen Sie immer die neueste Version von Discourse, WordPress und dem WP Discourse-Plugin aus.
2. Verwenden Sie Port 3000 anstelle von Port 4200 in der lokalen Discourse-URL in WP Discourse.
3. Stellen Sie sicher, dass der von Ihnen erstellte Schlüssel vom Admin-Benutzernamen verwendet werden kann, den Sie als Publishing Username festgelegt haben.

So sieht mein lokales Setup aus, mit meinem lokalen WordPress und Discourse, die miteinander verbunden sind. Ich verwende MAMP Pro, um WordPress lokal auszuführen.

[Gregory_Bartholomew]

Es hat funktioniert!!!

Vielen Dank für den Tipp, direkt mit Port 3000 zu verbinden. Das scheint den Unterschied gemacht zu haben.

Eine Sache, die zu beachten ist (zumindest in meiner lokalen Konfiguration), ist, dass ich auch ALLOW_EMBER_CLI_PROXY_BYPASS=1 setzen musste, bevor ich ember-cli gestartet habe.