We are using Discourse instead of WP comments (“Remove WordPress Comments Template” is checked, as well as Ajax). I have Toolset Access control on a custom post type that is posting to Discourse (to a private category that aligns with the access control). Normally this type of control would also affect visibility of the post comments, but it’s not affecting the display of the Discourse comments. Any ideas?
1 Like
Perhaps I can add some further context here:
We have a private custom post type on our Wordpress site, whose posts should be connected with topics in a private Discourse category. The same users who have access to the Discourse category have access to the post on Wordpress. We are handling this by assigning these users to the Editor role in Wordpress, while in Discourse they belong to a group which gives them access to the private category.
In no case should unauthenticated users see either the posts in Wordpress or the topic threads in Discourse. This is working as intended through role and group access controls, respectively. On the Wordpress side, as noted above, we are using Toolset Access to restrict access to all posts of this custom post type.
However, private discussion threads from Discourse are displaying to the public via embedding in Wordpress, even though the post content itself is hidden. In other words, the embedded Discourse comments are not being hidden by access control. We are trying to figure out what might be placing this output outside the control loop, and how to rectify.
The WP Discourse plugin displays comments by loading a custom comments template. It uses the WordPress comments_template filter to load the custom template. I’m not sure why the comments are still loading when you have Toolset Access control configured for a post type. I’ll look into what is going on with that.
I think the plugin should add an option to not load comments for posts that have been published to a private Discourse category. When enabled, just a link to the Discourse topic would be displayed. I’m not sure that would solve the issue you’re dealing with though.
2 Likes
Hi Simon, I’m working with@Kayla on this. What you describe here would solve our issue.
It still would be good to know, too, how to include the Discourse comments template within our more granular access control. Thanks!
1 Like
Great! I don’t think there will be a problem to get that into the next update of the plugin. I’ll try to have that done by the end of the week. I’ll keep you posted about progress on that.
I think the issue that you’re running into is related to the priority that WP Discourse is hooking into the WordPress comments_template filter hook. The WP Discourse plugin is using a priority of 20 for calling the function that hooks into this filter. The Toolset plugin is probably hooking into that filter with a lower priority to prevent the comment template from being loaded for protected pages.
3 Likes
I got in touch with Toolset about this and I was mistaken about the expected behavior. The Toolset Access plugin doesn’t hook into the comments template at all. Hiding comments on restricted content requires custom code to hook into their toolset_access_api_get_post_permissions filter to suppress/allow the rendering of the comments template at the theme level. I apologize that I did not realize their content restriction is quite literally about the content template itself. 
2 Likes
This option has been added to the plugin in version 2.0.7. It is available in the WordPress repo now.
When you select the plugin’s Enable Discourse Comments option, you will now see three options for comment types:
Select the “Display comments for public topics” option to only have comments displayed for topics that are in public Discourse categories. If a topic is published to a private category, a link to the topic and its comment count will be displayed.
If a topic that has been published from WordPress to Discourse is moved from a public to a private category on Discourse, comments will be removed from WordPress and replaced with a link. This change will take up to 10 minutes to occur because the WP Discourse plugin caches comment data that’s returned from Discourse. You can break the category cache immediately by selecting the Force Category Update option from the plugin’s Publishing Settings page and saving that settings page.
To allow the plugin to access category permissions for Discourse subcategories, you need to select the Display Subcategories option from the plugin’s Publishing Settings tab. If that option is not enabled and the “Display comments for public topics” option has been enabled, subcategories on Discourse will all be considered to be private and a link will be displayed instead of comments.
Note: having the plugin recognize category changes that are made directly on Discourse only available if your site is on a recent version of Discourse.
To programmatically control which users have Discourse comments displayed for them, you can completely bypass loading the WP Discourse comments for a user with the wpdc_load_comments_template_for_user filter hook. That hook is passed three arguments: $load_template (defaults to true), $current_user, and $post_id. Return false from a function that hooks into the filter to prevent comments from being loaded for a particular user.
3 Likes
Changes I’m seeing with this update are that while discourse_replies_html loads and looks as expected, it seems to be failing to load discourse_no_replies_html (seeing
“Join Discussion Link: no Comments” text link, but not our template). Also, if the post has not been published to Discourse, there’s a new message is appearing: “Comments are not currently available for this post.” These are all public posts to public Discourse categories.
For posts published to private Discourse category, it seems to be loading the default WP comments form. No link to Discourse topic.
“Display comments for public topics” is set, as well as “Display Subcategories.” I updated Clear Cached Comment HTML + Force Category Update. Am I overlooking anything?
2 Likes
Thanks for reporting that! The issue should be fixed in WP Discourse version 2.0.8.
I’m going to be making a few changes to the plugin later today or tomorrow that should take care of the other issues you are reporting. Failing to load the WordPress comments template for posts that have not been published to Discourse had to get fixed right away.
3 Likes
Here’s what I’m seeing when I select the " Display comments for public topics" option and the “Show Existing WP Comments” option, then publish a post with existing WordPress:
From a user’s point of view, this doesn’t seem very clear (that could be fixed with some WordPress customization), but the link to the Discourse comments exists.
If you have enabled the “Cache Comment HTML” site setting, try disabling it. That setting shouldn’t cause an issue, but unchecking it will simplify debugging this.
Send me any more details that you have about the issue. I’ll be pushing a small update to the WordPress repo later today fo fix an issue with the “Unlink Topic” button that’s happening with the WordPress 5.5 release.
We’re at version 2.1.1 with WP 5.5. We don’t have comment caching turned on, and we are not using WP comments (but now no longer seeing the default form load, so that is good).
However, sometimes the custom templates load and sometimes they do not. We reverted to show comments for all posts regardless of whether the Discourse topic is private or not, but that didn’t help. I can’t figure out the why, but it seems persistent for the individual posts. Examples for public posts in public topics:
no commments, not loading discourse_no_replies_html:
no comments, is loading discourse_no_replies_html:
has comments, not loading discourse_replies_html
has comments, is loading discourse_replies_html
It’s possible that the issue is related to the custom templates, but there’s another report of an issue with the comment template not loading and the comment link being displayed instead. I can’t reproduce the issue on my development site, but I’m going to make a small change to the plugin that should fix the problem. I’ll have that ready by early tomorrow. Thanks for your patience with this!
1 Like
Can you try updating the plugin to version 2.1.2 and let me know if that fixes the issue?
2 Likes
I can confirm that updating to 2.1.2 fixed the template-loading issue for us. Thank you!
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.