[Resuelto] What is the Toolset Access priority for comments_template filter hook?

[Autor]

Mensajes

[marcoM-5]

We are using Discourse instead of the WP comments. We have a CPT under access control that posts to a private Discourse category. We ran into an issue: Discourse comments still show even if a visitor/user does not have the proper permissions. The CPT content itself is replaced with our custom content template message; it's an issue of the comments section. The WP Discourse plugin is using a priority of 20 for calling the function that hooks into the WP comments_template filter. Does Toolset Access hook into this filter with a lower priority?

[Waqar]

Hi,

Thank you for contacting us and I'd be happy to assist.

When a separate content template is set to show for visitors without the access permission, the Access plugin only replaces the normal content template part and not the other elements on the page.

As the "comments_template" part is loaded after the content template and not inside it, the comments template still shows and it doesn't matter if you're using WordPress or Discourse comments.

You'll need a custom shortcode, that can check whether the current visitor has the right permission to access the current post, using the "toolset_access_api_get_post_permissions" function.
( ref: https://toolset.com/documentation/programmer-reference/access-api-filters/#toolset_access_api_get_post_permissions )

Example:

add_shortcode('allowed', function () {
 
    $userid = get_current_user_id();
    global $post;
 
    $allowed = apply_filters( 'toolset_access_api_get_post_permissions', true, $post, 'read', $userid, ICL_LANGUAGE_CODE );
 
    $return = ( $allowed ) ? 1:0;
 
    return $return;
    
});

This shortcode will return '1' for the "allowed" and '0' for the "not allowed" case.

After that, you'll be able to wrap the call to load the comments section ( i.e. comments_template() ) in your theme's file, in a conditional check using this new shortcode's output.

Example from default Twenty Twenty theme:
( you can check your active theme's template for the single posts to see how it loads the comments_template() function )

<?php
	$allowed = do_shortcode('[allowed]');
	if ($allowed == 1) {
?>
	<div class="comments-wrapper section-inner">
		<?php comments_template(); ?>
	</div><!-- .comments-wrapper -->
<?php
	}
?>

As a result, the comment section will only be loaded, when the visitor is allowed to view the current post.

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

[marcoM-5]

https://toolset.com/forums/topic/access-control-can-posts-groups-contain-all-posts/#post-1203859 suggests that post comments would not show if a user was not allowed to view the contents of the post per access rules. But as you clarify, (please put this somewhere in the documentation) the comments do not show only if we select to display the default error (which is really a redirect).

Consider this a feature request, then. We ended up going with a different content restriction solution in this case, so we could redirect to a page with a custom message other than the default “page not found.”

Even after we made this decision, I did try to see about using this code to hide the comments on a dev environment while choosing "Show Content Template." I did get it to work on a Genesis-based theme using:

function access_remove_genesis_comments() {
  $allowed = do_shortcode('[allowed]');
  if ($allowed == 0) {
    remove_action( 'genesis_after_entry', 'genesis_get_comments_template' );
  }
}
add_action( 'genesis_before_entry', 'access_remove_genesis_comments' );

However, please note that the shortcode bit is returning "Warning: Use of undefined constant ICL_LANGUAGE_CODE - assumed 'ICL_LANGUAGE_CODE' (this will throw an Error in a future version of PHP)"

[Waqar]

Thanks for the update and I'll pass on this feedback internally.

About the warning related to the "ICL_LANGUAGE_CODE", that constant is defined when the WPML plugin is active.
( ref: https://wpml.org/documentation/support/wpml-coding-api/ )

When the WPML plugin is not active, you can either leave the "$language_code" parameter (since it is optional) or add the language code (e.g. "en") manually.
( ref: https://toolset.com/documentation/programmer-reference/access-api-filters/#toolset_access_api_get_post_permissions )

[marcoM-5]

Thanks for clarifying the issue about the ICL_LANGUAGE_CODE bit. I left it off and all is well. Hoping this thread helps another with a similar misunderstanding with the comments visibility, and that they can indeed fulfill their expectations as long as they are willing to dig into their theme layer (for Genesis-based themes, both bits of code are added to functions.php).