WP Discourse Version 1.8.2: Instead of my custom filters I’m getting “Comments are not currently available for this post.” inside a div that includes the class “discourse-no-connection-notice.” This is regardless of whether the post is using the Classic or Block Editor. The posts do publish to Discourse.
Didn’t help. Unlinking and relinking to the existing topic results in an empty div with the class “wpdc-comments-loading” (at least in the context of no replies in my playing with it). Adding a comment on Discourse didn’t populate over to WP, still the same empty div. Removing my custom filters entirely does show default “Start the conversation at _.” Any tips on how to get my old custom filters working with the newest version?
is what I started with. @madrush noticed it before the update to WP Discourse Version 1.8.2, but I thought maybe it was a related issue the new version would solve. And you’re right, my example modification broke existing posts where the replies/no replies were just fine, and which were restored when I went back to my original custom filters (in use since 2016). So the issue seems reserved to publishing new posts.
Interestingly, if I create the topic on Discourse first , then link a post with that existing topic, the replies/comment area works as expected on WP. If I publish the same post type to a new topic in Discourse, I get the “Comments are not currently available for this post.”
Do you know if this is working correctly with regular post types? The ‘Comments are not currently available’ template that you are seeing is only displayed when the discourse_permalink post_metadata is not set for a post.
No, I just tried a brand new WP-native post; using the Block Editor. This is also happening on our ‘event’ CPT that is using the Classic Editor, and which is a post type that was working previously with these filters as well. (Our ‘groups’ CPT is new since updating to Wordpress 5, it has same issue but no pre-existing comparisons.) Previously published-to-Discourse replies/no_replies seem fine for both regular posts and events, it’s just when trying to publish new content/not yet linked to Discourse.
Now that I’m back to using the original filter, this also works: posting to a new topic, then unlinking the post from that topic, then linking it back to the existing topic that was created when first posting to Discourse. Not an ideal workflow, but it might help the picture of what might be going on.
So far I haven’t been able to reproduce this. From what you’re describing, it seems like there is an error when posts are published to Discourse - when a post is published, a call is made to:
When comments are displayed, if the discourse_permalink metadata isn’t set, the (poorly named) bad_response_html template is displayed.
When you unlink and then relink the post to Discourse, the discourse_permalink metadata is added through another route, so it makes sense that it works when you do that.
If you are developing this locally, you could try logging errors to a debug.log file. See Debugging in WordPress « WordPress Codex for details. My guess is that you will see an error when you are publishing posts. Any details you can give about this would be great.
One thing to try would be to comment out all your custom templates, and then add them back one by one. Add back the discourse_publish_format_html template last. If you have no custom templates, and publish a post normally, are you still seeing the ‘Comments are not currently available for this post’ message?
I went to look at the error logs available in our wpengine account, and I did see some in regards to my template file, but I think it’s from when I did that wonky modification with the ( $input, $post_id ):
[php7:error] PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function cosmos_custom_discourse_replies(), 1 passed and exactly 2 expected in /nas/content/live/theoryofe/wp-content/mu-plugins/cosmos-discourse-templates.php:9
Line 9 is function cosmos_custom_discourse_replies( $input ) { , and I got a similar error referring to the line function cosmos_custom_discourse_no_replies( $input ) {.
I didn’t see anything more recent than these referring to the templates, so I’ll do some more work as you suggest and see if I can find anything helpful. Thanks!
Thanks for all your help with this issue, @simon. I found the source of the error we were seeing. It was a misconfigured webhook. We recently changed the primary domain of our Wordpress multisite, which means the existing webhook set up on the Discourse end was no longer correct. Once I updated it, I was able to successfully create new posts in Wordpress (including in custom post types), which now properly create and connect to a new topic in Discourse.