Plugin tries to re-publish to Discourse after every update

Hello,
I noticed an issue on our website with the WP Discourse plugin.
Basically after we publish a blog post and being successfully published on the Discourse forum, after let’s say 1 week if we do a slight change to the post and update it, the WP Discourse plugin tries to publish it again to the forum.
I receive then an email “Discourse Publishing Failure” saying that the embed url has already been taken.

I noticed this also when updating very old posts in Wordpress, they are popped up in the default category “News” of the Discourse forum, confusing the readers.

Is there any setting that I’m missing to avoid this?
Thanks a lot!

Thanks for the report. I’ll take a closer look at this scenario soon, hopefully tomorrow, and at the latest by early next week.

2 Likes

Hey @npm0912 could you do a test for me?

Could you try to re-create this issue, but before you do the change (after a week, or whatever normal time lapse there is) please check the Discourse post status in the Wordpress utility bar on the right in the post edit screen. Tell me what is shown there at the point at which you’re doing the edit, and then whether you get the behaviour you’ve just described after the edit.

Please also share a download of your WP Discourse logs with me.

so when I try to edit a post published first 10 days ago or so, i see this Discourse post status:

Tried to update the post and the same error happened. I got also the same email about the failure.
Last error from the logs is:

[2024-05-13 18:02:53] publish.ERROR: create_post.post_error {"wp_title":"Nextcloud exhibiting at global events in May 2024","wp_author_id":"9","wp_post_id":209030,"response_message":"Embed url has already been taken","http_code":422} 

Shouldn’t be there an option on the Settings page which disables the re-publishing attempt when the post is already on Discourse?

thanks!

Ok, this means that your Wordpress instance isn’t letting the WP Discourse plugin save post meta fields correctly, most likely due to another plugin or theme on your site. Could you share the WP Discourse log download? That’ll include a list of plugins which could suggest a culprit.

Normally what happens is that the plugin saves the publication details after first publication. That isn’t happening on your site. That’s what we need to figure out :slight_smile:

oh ok, that’s weird… i thought it had to be a bug. I’m attaching the metadata file. Let me know if that is enough

wp-discourse-logs-metafile-2024-04-17-2024-05-13.txt (2.5 KB)

Let me know if there is a know plugin which could interfere with the Discourse plugin.

thanks a lot for taking the time to investigate this!

You have a few plugins that could be the culprit. As a first measure, could you please enable this setting in WP Discourse’s “Publishing” settings.

It changes how the plugin saves custom fields and could effect the behaviour in your case. It probably won’t fix the issue but it may give us more insight. Once you’ve enabled it, please try to recreate the same circumstances.

After we’ve tried that, we’ll then move to disabling individual plugins to see if we can isolate the issue. Do you have a staging site by any chance (i.e. a site with your themes and plugins, but without real data)?

I’m also going to add more logging into the publication logic in the plugin to help illuminate this class of issue (i.e. the storage of metadata in Wordpress after publication to Discourse). That’ll take a bit of time though and we can perform some tests like the above in the meantime.

Hello and thank you for your time again!

I enabled that setting but the issue is still there.
We actually use a staging website and the funny thing is that, even if the plugins, themes and files are exactly the same, it behaves differently - meaning that after I publish a test post, it goes on Discourse correctly, and then if I come back to the same post, i don’t see the “Embed url has already been taken” error in the Discourse sidebar settings. Instead I see it like this:

So the server differences are:
Staging site:
WordPress - 6.5.3
PHP - 8.1.27
MySQL - 10.6.16

Live site:
WordPress - 6.5.3
PHP - 8.1.2-1ubuntu2.17
MySQL - 5.5.5

Hey @npm0912, this demonstrates that the issue is one to do with your environment.

  1. Could you share the full “meta” file from the WP Discourse log viewer from both instances.
  2. What are the differences between the Discourse you’re using with staging and the one you’re using in production?
  3. Do you use any caching, CDN or load balancing solutions in Wordpress production that you don’t use in staging?

Hey @angus ,

  1. Sure, here are the logs:
    Staging:
    Staging wp-discourse-logs-metafile-2023-04-13-2024-05-28.txt (2.4 KB)
    Live site:
    LIVE wp-discourse-logs-metafile-2024-05-13-2024-05-28.txt (2.4 KB)

  2. the Discourse instance is the same, the only difference being that from staging I am posting in another forum category.

  3. I use WP Rocket and Redis cache on both instances so I guess this wouldn’t be affecting.

Thank you!

There are some slight differences between the two. Probably not the cause, but it’s worth keeping your staging and production sites identical, to eliminate the possibility of that being the cause, both here and for other issues.

Aside from that, I’d recommend you checking your WP Rocket settings closely (e.g. are they actually the same between your two sites). While it works well for it’s particular purposes, WP Rocket is often the cause of issues with Wordpress plugins.

Note that Wordpress currently requires MySQL version 8.0 or later. You need to upgrade your production database.

cross reference: Could not update the meta value of discourse_post_id in database - #2 by angus

actually, WP Discourse got that info about the DB wrong. the correct version of the database is 10.6.16-MariaDB-0ubuntu0.22.04.1

The version printed in that file is the output of a core Wordpress function:

$wpdb->db_version()

See here in the code, and see further

That is what version Wordpress thinks it’s using. This is your issue it seems.

you’re right. I checked again the db_version() function inside the theme and indeed I got 5.5.5 as result. But on the “Site health” backend page I see version 10.6.16-MariaDB - same as the version the sysadmins have mentioned to me… I mean that should be also the version WP sees, right?

Screenshot 2024-05-28 174111

Sorry but there could be a number of things going on here and it’s not really possible to say with any confidence without looking at your server.

Given the issues you’ve reported I’d suggest investigating this angle thoroughly.