آخر تحديث لـ WP-Discourse يسبب بعض السلوك غير المتوقع

[itsbhanusharma (Bhanu Sharma)]

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.

[angus (Angus McLeod)]

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

[itsbhanusharma (Bhanu Sharma)]

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?

[angus (Angus McLeod)]

Both if possible. Please turn on Verbose Publication Logs.

[itsbhanusharma (Bhanu Sharma)]

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

[angus (Angus McLeod)]

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

[itsbhanusharma (Bhanu Sharma)]

@angus

Your custom post types (i.e. the events) are being published to Discourse successfully

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

@angus

You haven’t see the 400 error before

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

@angus

What type of users (whose discourse usernames you’re expecting to be used) are publishing posts (i.e. are they admins or not)

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

@angus

What type of API key are you’re using to connect Wordpress to Discourse

It is a Global API key

[angus (Angus McLeod)]

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

[Thiago_Mobilon]

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.

[angus (Angus McLeod)]

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

[jtbayly]

Same problem here. Not a custom post type.

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

[Thiago_Mobilon]

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

[angus (Angus McLeod)]

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

[orenwolf (Ken Snider)]

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.

[itsbhanusharma (Bhanu Sharma)]

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?

[angus (Angus McLeod)]

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.

[itsbhanusharma (Bhanu Sharma)]

@angus

Considering the type of operation this is, this should not be a performance concern.

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.

[jtbayly]

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.

[angus (Angus McLeod)]

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.

[jtbayly]

@jtbayly

I’m not sure I understand what caused this to break in the first place.

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.