Connecting WP Discourse to a local Discourse Instance running a specific version

I just tried installing this plugin on WordPress 6.7.2 with php-fpm-8.3.17-1.fc41.x86_64, but it doesn’t work. I get the following error in the log when I click “Save Options”.

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

There are corresponding errors 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

I see that the same error is being reported in the “smoke test” at Report - WP-Discourse 2.5.6 - PluginTests.com.

Edit: Nevermind about the undefined url error. It appears that was just an initial error from before the web form was completed. I am still getting the wpdc_response_error repeatedly, however, every time I click the Save Options button.

Edit2: I’m seeing a 403 forbidden on the discourse side, but it isn’t clear to me why the connection from my WordPress site is being forbidden. I can use the same API key successfully with curl.

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

I’m running Discourse 3.5.0.beta1-dev in development mode.

Edit3: I found that there are special WordPress permissions for the API key in this version of Discourse. Using “Granular” instead of “Global” and checking the boxes under WordPress got rid of the 403 Forbidden errors. However, I’m still getting empty/invalid replies sent to WordPress.

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

I guess I need to use an older version of Discourse with the WordPress plugin. What is the latest version that it works with?

Hey there @Gregory_Bartholomew, let’s see if we can get to the bottom of your issue.

It works with the latest version of Discourse.

When you say you’re running Discourse “in development mode”, do you mean you’re running it locally? If not, what environment are you running it on?

Before trying to use a key with Granular permissions, could you please have a go at using a Global key as shown in the video in the first post.

Thanks. I’m trying to reinstall Discourse now. I checked out version 3.3.0 for testing.

I’m trying to install Discourse locally instead of using the Docker container due to a bug in ZFS that prevents the Docker container from building successfully on ZFS file systems (pnpm issue 7024). If I install Discourse locally, I can workaround the ZFS bug by adding package-import-method=hardlink to .npmrc before running pnpm install.

I mean I had RAILS_ENV=development. I’m going to retry with RAILS_ENV=production now.

Also, I’m trying to rework the guide I linked above to work on Fedora Linux.

Edit: I’m not having much luck with version 3.3.0.

$ pnpm install
 WARN  The "workspaces" field in package.json is not supported by pnpm. Create a "pnpm-workspace.yaml" file instead.
 ERR_PNPM_INVALID_SELECTOR  Cannot parse the "**/unset-value" selector

I guess I’ll try again with 3.4.0 and see how that goes. :confused:

Well, I reinstalled Discourse at version 3.4.0:

However, I couldn’t get it to run in production mode. I’m not sure why. It just said “Oops …” and there wasn’t much that I could see in the logs. I think the problem might have been something to do with some proxy settings, but I’m not sure.

Anyway, I set RAILS_ENV back to “development” and it started. However, I’m still getting the same error when I try to connect from WordPress:

[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":""} 

I can see the queries hitting Discourse though, so I don’t understand why it isn’t working.

GET "/site.json" for 000.123.456.789 at 2025-02-21 16:11:05 -0600
10:11 pm
Processing by SiteController#site as 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
Completed 200 OK in 256ms (Views: 0.3ms | ActiveRecord: 116.4ms (15 queries, 0 cached) | GC: 94.6ms)

I think I’m going to take a break from this for a while, but if you have some idea about what might be going wrong, I’d appreciate some hints. :slightly_smiling_face:

I’ve moved this conversation to an independent topic as the issues you’re dealing with may confuse other folks running standard setups.

Ok, so to recap,

  1. You’re running Discourse on your local machine.
  2. You’re running specific versions. You’re currently running 3.4.0.
  3. You’re trying to connect your local instance to a remote Wordpress instance.

Is any of that incorrect? Also, could you clarify the following:

  1. How are you connecting to the remote Wordpress instance from your local machine? Are you using ngrok?
  2. Why are you running specific versions of Discourse instead of the latest version?
  3. What is your overall goal here?
2 Likes

Yes.

Yes.

My test WordPress instance is also running locally.

No, everything is local. I have two instances of httpd running and listening on different IP addresses (one for WordPress and the other for Discourse). The WordPress instance is running directly on my host system and the Discourse instance is running in a systemd-nspawn container. Both the host system and the container are running Fedora Linux 41.

I initially tried the Docker instance, but it wouldn’t build on my test machine. Researching the error message lead me to an open bug report indicating the problem was with the ZFS filesystem. I don’t know how to modify the Docker image to apply the workaround, so I found instructions for cloning the source repo and building Discourse with that.

I initially built the latest version (3.5.0.beta1-dev), but the behavior seemed different to what your video was showing. I would see 403 Forbidden in the Discourse logs when WordPress tried to connect with the API key (when the permissions were set to “Global”). Changing the permissions to “Granular” and checking all the boxes for WordPress would allow the queries to proceed further, but WordPress was receiving empty/invalid responses. I then noticed on https://blog.discourse.org/ that the latest version being promoted was 3.4, so I concluded that some of the problems I was encountering might have been because I was trying to run a pre-release. I tried git checkout v3.3.0 thinking it would be old enough to be fully compatible with the WordPress plugin I’m trying to test, but it wouldn’t build on my system, so I checked out version 3.4.0 and that seems to be working (albeit in “development” mode).

Really I just want to experiment with and familiarize myself with the WordPress Discourse plugin. I don’t really care about Discourse at all. I just need something to test against. Once I’m comfortable with how it all works, I might try to install the plugin on a production site (fedoramagazine.org) and have the comments redirected to the production Discourse instance at discussion.fedoraproject.org.

1 Like

That’s the saddest thing I’ve ever read on this forum! :lolsob:

1 Like

The issue will be something to do with your local setup and network. It will not be due to the version of Discourse, or the difference between global and granular keys. It’ll be hard for me to debug your local app interconnectivity issues, particularly due to the variety of ways and environments you can run both Wordpress and Discourse locally with. Here’s a few tips to help you.

  1. Always run the latest version of Discourse, Wordpress and the WP Discourse plugin.
  2. Use port 3000 instead of port 4200 in the localhost Discourse URL in WP Discourse.
  3. Make sure the key you create can be used by the admin username you’ve set as the Publishing Username.

This is what my local setup looks like with my local Wordpress and Discourse connected to each other. I use MAMP Pro to run Wordpress locally.


3 Likes

It worked!!!

Thank you for the tip about connecting directly to port 3000. That appears to be what made the difference.

One thing of note (at least in my local configuration) is that I also needed to set ALLOW_EMBER_CLI_PROXY_BYPASS=1 before starting ember-cli.

3 Likes