Fixed! Unfortunately, this is a bug in (I think) the discourse plugin that somehow unchecks the automatic “post to discourse” option. I already requested a “force posts to discourse” option for the plugin from @codinghorror, but until then just report them here and I’ll fix them as they come.
I’ll also remind the Authors to double-check that checkbox when they post. Thanks!
I checked with the (very talented) developer we have working on WP-Discourse and he said
Is there a chance that they are posting through a blogging app, for example the wordpress.com app? Posts published through XML-RPC are not published to Discourse. This is because when a post is published through XML-RPC there is no way to tell if it’s supposed to be published to Discourse or not. There are a couple of workarounds for this, but I think that adding a ‘force post to Discourse’ option will cause problems.
So: are they posting through an app? That is the key question. If so “force to Discourse” could maybe work but would not be without risks of its own.
Hopefully the problem with posts not being published to the forum has to do with them being published through blogging software. XML-RPC publishing was disabled in the plugin to fix this problem: Rogue time travel issue on Boing category posts.
The only other issue I’ve seen where some posts were not being published to Discourse was a conflict with a scheduling plugin. In that case the problem was solved by disabling the scheduling plugin (it wasn’t needed), but I think we can safely add a ‘force publish’ option to the plugin to deal with all cases except for posts that are published through XML-RPC.
The one commonality I’ve been able to find is that they seem to be scheduled posts, but I’m not 100% certain yet. Obviously, not all scheduled posts are failing, so I’m wondering if there’s some crazy combination of saving as draft, multiple authors, and scheduling that is leading to the post option and category being removed.
Scheduling, in this case, is being done by WP directly, not a plugin.
In our case, we just want all posts to be published out, so a “force” option may well be the easier solution than trying to figure out what specific set of circumstances is leading to the loss of discourse metadata for these posts.
On the site where they had the problem with scheduled posts, they were scheduling the posts through WordPress, but using a Missed Schedule plugin combined with a cron job plugin to actually publish the posts.
I haven’t added a force publish option to the wp-discourse plugin yet, but you can force all posts to publish to Discourse by adding something like this to your functions.php file. This will publish everything, including old posts that someone edits.
add_filter( 'wpdc_publish_after_save', 'my_namespace_publish_all_posts' );
function my_namespace_publish_all_posts() {
return true;
}
One other thing that will cause posts to not publish to Discourse is if the Discourse username isn’t set correctly. But if that was the case, then the author wouldn’t be able to publish any posts to Discourse - it wouldn’t be intermittent.
I’ll look at this some more and see if I can find a way to reproduce it.
I’m adding a success/failure notice to the plugin that will appear on the new-post page after an attempt has been made to publish a post to Discourse. That might give you some information about what’s going on, but if the issue is that the ‘publish to Discourse’ checkbox is not checked for the post, then it won’t help. It will be in the next update, hopefully later today.
In terms of displaying the comments link at the bottom of the WordPress posts, you could check for the post’s discourse_post_id before displaying the comments link: get_post_meta( $post_id, 'discourse_post_id', true ); You could even set it up to send you an email if a post is published to WordPress without a discourse_post_id.
I’m still trying to figure out what’s going on with this. Is it possible that the posts that are failing have the status ‘pending’ (require approval) when then are first published?
I’m not sure if it’s what’s causing the problem here, but I found a problem that happens when the Discourse Categories list that’s shown on the new_post/edit_post page returns an error. It will return an error if the categories list transient has expired or isn’t present, and the call to Discourse to fetch new categories times out.
When this happens, the value of the ‘Publish to Discourse’ checkbox on the new_post/edit_post page is set to 0, and the value of the publish category is set to null. If a post is edited in this state, it won’t be published to Discourse.
I’m going to store the categories list in an option, instead of in a transient, so that it will always be available. This will mean that if categories are added to a forum, they will need to be updated by selecting the ‘Force Category Update’ checkbox on the plugin’s options page.
I’ll also make it so that if an error is returned when fetching the categories, the publish status will default to the value of the ‘auto publish’ option, and the publish category will be set to the default category. I should have set it up that way in the first place.
A fix for this will be in the next update. The time for that update keeps getting delayed, but it will definitely be available by Monday.
This may we’ll be the issue, as 90% of the time when I go to look at the post, the publish box is unchecked and category is set to “general” (which I assume is the default), despite us defaulting to another category.
The latest update (1.3.6) has been out for a few days with no reports of problems, so you should be safe to update to it. There are some details about the changes here.
The notices and email notifications are being triggered in the functions that are used to publish posts to Discourse. If posts are still failing to be published and you’re not receiving any notifications about them, then we can at least know that the problem is that those functions are not being called.