I’d love to provide more details, but unfortunately I’ve only got the least helpful error message possible to work from:
There has been an error publishing this post to Discourse.
Nothing in any error logs I can see on either the site or Discourse.
I can link to an existing topic, but that’s little more help than updating post meta directly.
Is there a debug switch I missed in the settings? Or some other way to get a useful error message?
Hi @invisnet
Did you open your web dev console (in the browser) and check for errors in the JS console there?
Have now - nothing of note, certainly nothing about Discourse.
After much digging into things I shouldn’t need to look at, I have an error message:
Can’t verify CSRF token authenticity.
Which is just about as helpful as the original.
From this I conclude:
embed_url for a topic manuallyI guess that’s a solution of sorts…
Sorry for the late reply. I am watching the wordpress category, but I’m fairly sure I didn’t get a notification for this topic.
The easiest way to get a detailed error message is to install Query Monitor – The developer tools panel for WordPress – WordPress plugin | WordPress.org English (Canada) and then try publishing a post to Discourse. The WP Discourse plugin used to save all errors to a log file, but stopped doing that because it goes against WordPress recommendations.
Do you get an error when you attempt to publish any post to Discourse, or is the problem just happening with a particular post?
It seems unlikely that upgrading the Discourse 2.6.0.beta1 is the cause of the issue. Were there any changes made to your WordPress site around the time that the plugin stopped working for you?
The error only shows up in production.log in the docker container - nothing else anywhere in any log or console (I already run Query Monitor).
Any new post.
Only updating the plugin to 2.0.6. However, it’s not the plugin - I’ve stepped back through the git tags with no joy.
I’m surprised that the Query Monitor plugin isn’t showing an error. I’d expect to see something like this, but with a different error message:
It might be worth generating a new API key from your Discourse Admin / API page. Make sure the key is a Global Key (allows all actions.) Also make sure that the Publishing Username is set correctly on the WP Discourse Connection settings tab. Since you are able to link to existing Discourse topics, but not publish new topics to Discourse, it seems possible the issue is related to API permissions.
One final thing to check is to see what values are getting set for the post custom fields when you attempt to publish a post from WordPress to Discourse. If you enable custom fields in the editor, you should see something similar to this at the bottom of the editor:
If you can let me know what fields are getting set, I may be able to figure out the cause of the problem.
So am I, but it really isn’t showing anything at all. If it were it would be a 400 error (as that’s what’s reported in production.log), but it’s not.
Update: having grovelled through the code I can see there won’t be an error - it’s all caught; if you enable email reports (email but no error_log()?) it tells you:
Reason for failure:
A 400 response code was returned from Discourse.
Bad Request
but that’s it.
Already done that, no difference. It was a last resort - the “last used” timestamp got updated on the previous key when I tried to publish so I knew that hadn’t changed somehow, but I thought it was worth a go.
publish_post_category: 23
update_discourse_topic: 0
wpdc_publishing_error: Bad Request
wpdc_unlisted_topic: 1
That’s it. Oh, and before you ask, it does the same if I don’t set “Publish as Unlisted” but with the expected difference in post meta.
Thanks for the details. I’ll take another look at this when I get back to work on Monday.
I’m not sure what could be causing the 400 response. Could you try installing Health Check & Troubleshooting – WordPress plugin | WordPress.org English (Canada) and see if it reports any issues with your WordPress site. When that plugin is activated a “Site Health” entry will be added to the Tools section of your WordPress dashboard. Clicking that link then going to the Status tab might show some useful details.
The Health Check plugin also allows you to temporarily disable plugins for just your own session. This could be useful to see if the issue is related to conflict with another plugin - if you have any security related plugins installed on your site, it might be worth seeing if disabling them fixes the issue.
Unfortunately I’ve hit a dead-end. The Health Check plugin suggested nothing useful (unsurprising), and everything else is working perfectly.
I’ve run into the CSRF error when I was automating sending invites and it means you made a mistake in your code; however, in this case the plugin hasn’t changed, so my conclusion is that 2.6.0.beta1 is broken.
I know that’s not a popular conclusion, but it’s the only one I have right now.
Edited to add: I used the Health Check plugin to disable all other plugins - no difference.
Problem persists with 2.6.0.beta2 and 2.1.2.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
