Latest WP-Discourse Update is causing some unexpected behaviour

Support WordPress
1

The latest commit to the WP-Discourse plugin is causing all the custom posts (made through EventON Plugin) to be attributed to system user despite the user existing on both discourse and WordPress.

If we roll back to 2.3.7, it works as expected but updating to 2.3.8 causes this bug to happen.

We receive this error via emails:

Reason for failure:
 A 400 response code was returned from Discourse.
 param is missing or the value is empty: post
 Did you mean? post
        post[raw]
        controller
        title

I thought it might be helpful in identifying the probable cause.

2

Hey, could you share a link to the plugin you’re referring to? Also are you seeing anything in the WP Discourse logs?

3

Hi @angus

Here is the plugin: https://www.myeventon.com/

Do you need logs from v2.3.7 or v2.3.8 of the plugin?

1 Like
4

Both if possible. Please turn on Verbose Publication Logs.

5

v2.3.7:

[2022-02-21 08:07:11] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""} 
[2022-02-21 08:07:11] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}

The post was correctly linked to my user account on both wordpress and discourse with 2.3.7

v2.3.8:

[2022-02-21 08:10:15] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""} 
[2022-02-21 08:10:15] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}

The post was linked to my user on wordpress and system user on discourse on 2.3.8

1 Like
6

Can you just confirm a few things for me

  1. Your custom post types (i.e. the events) are being published to Discourse successfully
  2. You haven’t see the 400 error before
  3. What type of users (whose discourse usernames you’re expecting to be used) are publishing posts (i.e. are they admins or not)
  4. What type of API key are you’re using to connect Wordpress to Discourse
7

Yes, the posts are being published successfully but incorrect user (system) is being attributed with v2.3.8

No, We haven’t see any 400 errors on any prior versions of wp-discourse plugin.

These users are non-admin registered users on wordpress and so far it has worked for us. any users were correctly linked on discourse.

It is a Global API key
image

1 Like
8

When this PR is merged (and the version pushed to Wordpress.org), the functionality will work as you expect it to.

https://github.com/discourse/wp-discourse/pull/437

2 Likes
9

I’m experiencing the same error, and can confirm that it started after upgrading WP Discourse to the version 2.3.8.

With this version, topics are created, but with the default user.

To confirm, i rolled back WP Discourse to 2.3.7, and it’s working again.

2 Likes
10

Thanks, it will be addressed when the PR is merged. Could you just confirm these two questions as well

  • What type of users (whose discourse usernames you’re expecting to be used) are publishing posts (i.e. are they admins or not)
  • What type of API key are you’re using to connect Wordpress to Discourse
11

Same problem here. Not a custom post type.

not an admin user, but a moderator
An “all users” api key.

12
  • Users are moderators and some admins
  • API “All Users”
13

Hey guys, version 2.3.9 is now live with a fix for this issue. Please update and let me know how you go.

1 Like
14

We are seeing the same issue with 2.3.9, and are rolling back to 2.3.7, and disabling auto-update of this plugin going forward.

1 Like
15

Hi @angus

Sorry for the noise, My issue seems to have been fixed on WordPress 5.9.1 & WP Discourse 2.3.9

But, it seems like discourse is now doing some extra work on each published post and the ownership is being transferred from System user to the publishing user after the fact?

1 Like
16

Hey @orenwolf, I’m sorry to hear you’re still having an issue. Could you confirm that the users you’re expecting to be publishing under their own name have a Discourse Username in their Wordpress profile?

Generally guys, thanks for your patience on this. On my own testing on various sites (and in the plugin’s own unit tests), the Discourse Username feature is now functioning as expected on 2.3.9. If you’re still having an issue please confirm you’re on the latest version of the plugin and that the user you’re expecting to be the author of the post has a Discourse Username.

You might be wondering why this issue arose at all. I think it’ll be helpful if I give a bit of background (which will also answer your question @itsbhanusharma). Previously, the way this feature worked is that it used different users in the Api-Username header (see here). The reason this was seen as necessary was because the relevant endpoint in Discourse does not support setting a creator of the post different from the user performing the API request.

The upshot of this was that the only way this feature would work is if you have a “All Users” API key with a “Global” scope. I’ll just note that for some time the standard instructions for creating an API key for the WP Discourse plugin are as follows

If you haven’t yet created an API key, Click ‘New API Key’, set User Level to ‘Single User’, set ‘User’ to an admin account, select ‘Global Key’ and click ‘Save’. Copy and paste the API key here.

Following these instructions would mean that this (undocumented) feature would not work, and it has caused issues for various sites.

Moreover, for various security reasons, I’ve progressively been making changes to the plugin to allow for much more specific API keys to be used. This will require a change to Discourse, and (when it gets merged) will allow plugin admins to issue themselves a new, much more limited, API key. I’ll be making an announcement about that when the time comes.

https://github.com/discourse/discourse/pull/15366

Yes @itsbhanusharma the way the feature now works is by making a second request to change the owner of the post after it is created (if a Discourse Username is present). That is actually currently the only proper way to arbitrarily set the owner of a post via the Discourse API (without needing to use the Api-Username and an All Users Global Key in the way described above). Considering the type of operation this is, this should not be a performance concern.

4 Likes
17

It’s not a performance concern, just a nuisance to explain less savvy people that the pencil icon on top of their post is normal and that’s how It’s going to be.

It’ll take some time but eventually we’ll get used to it.

18

It is somewhat offputting that posts are shown as edited, but that’s fine as long as everything works.

However, it’s a problem that notifications are wrong. They show the new post being created by the system user.

So far this just feels like a hack, not a solution. It’s certainly a big step backwards to not be able to simply post as the proper user automatically. I’m not sure I understand what caused this to break in the first place.

19

The short version is that I’ve been slowly changing the way the plugin handles all of its requests to discourse for various reasons, particularly testing and security. The full context and rationale for the changes is too long to get into here. I appreciate that in the context of this particular feature it may feel like “if it ain’t broke don’t fix it”, however there’s a broader context here.

These changes have been going on for some time (months), however the reason they’re coming to the surface now is because I made a mistake in the 2.3.8 release. So I included the change that should have been in that release in 2.3.9.

That said, @jtbayly @itsbhanusharma I hear your feedback on the different approach to this particular feature. I understand it may feel like a hack. It’s not. Nevertheless, given your feedback, I’m going to add the existing way back in to the plugin behind a setting you can use if you wish (it will go live in 2.4.0). I’ll follow up with note when that’s merged in the next few days.

I hope to be able to remove this approach entirely when I’ve addressed the issues you’ve both raised, most likely with some further changes to discourse/discourse. As mentioned, I’m going to be making a larger announcement about changes to how the plugin handles API keys within the next month (depending on when changes get merged to discourse/discourse), which will cover aspects of this.

4 Likes
20

When I said this it was meant to acknowledge that I wasn’t sure if there was any other way forward. Wasn’t meant to be a “why’d you go and break it!” comment.

Very thankful for your work keeping the WP plug-in working with an updated core Discourse. And very happy there are (likely) coming changes to core that will allow for improvement in this area.

1 Like