Skip Navigation

[Resolved] Access plugin interferes with wordpress native functions?

This support ticket is created 7 years, 9 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 -
- 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 14:00 – 18:00 13:00 – 18:00 -

Supporter timezone: America/Jamaica (GMT-05:00)

This topic contains 5 replies, has 2 voices.

Last updated by EmmanuelF2728 7 years, 9 months ago.

Assisted by: Shane.

Author
Posts
#418445

I may be missing something obvious here but:

• is the Access plugin interfering in any way with wordpress native functions such as current_user_can() and is_admin()?
• is the Access plugin interfering in any way with wordpress default roles and capabilities definition?

My problem is: the two functions below work OK when Access is not activated and current_user_can( 'edit_posts' ) returns the right value. As soon as I activate Toolset Access, current_user_can('edit_posts') returns false and, as a result of the two functions below, I have no top admin bar nor access to wp-admin when logged in as a user with an Author role.

I have defined three new level_0 roles in Access but I have no other control options set.

I have two functions in my theme to:

1/ restrict access to wp-admin depending on user capabilities:

add_action( 'init', 'blockusers_init' );
function blockusers_init() {
	if ( is_admin() && ! current_user_can( 'edit_posts' ) && ! ( defined( 'DOING_AJAX' ) && DOING_AJAX ) ) {
		wp_redirect( home_url() );
		exit;
	}
}

2/ show the top admin bar depending on user capabilities:

add_action('after_setup_theme', 'hide_admin_bar_if_cannot_edit_post');
function hide_admin_bar_if_cannot_edit_post() {
  if (!current_user_can('edit_posts')) {
    show_admin_bar(false);
  }
}

I also added the following code in the footer php template for debugging purposes:

if (current_user_can( 'edit_posts' )) echo "debug info: user can edit post";

Thanks in advance.

#418463

NB: replacing

current_user_can('edit_posts')

by

current_user_can('level_2')

This does suggest that Toolset Access interferes with current_user_can when using a capability as parameter. Is this by design? If so, this may cause issues with a number of plugins and code snippets out there ...

#418516

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Emmanuel,

Thank you for contacting our support forum.

Let me see how best I can assist with this inquery.

Access does not interfere now modify any of the default wordpress functionality.

What access does is to use these functions to restrict content baed on a users role. You are also able to create custom roles.

It could be that you might have edited your author role in our Access plugin which may be causing this.

Would you mind providing me a screenshot of your roles in access so that I can have a look ?

Thanks,
Shane

#418715
level 2 - author - role permission.JPG
Access Roles.JPG

Hi Shane,

Thanks for this. This is really strange behaviour then.

As mentionned, the only thing I've done in toolset Access is to create three level 0 roles. I haven't set any other access restrictions / role permissions. The level 2 / Author role has edit_posts enabled. Please note I do not seem to be able to edt the capabilities for WordPress roles and permission levels via Access

NB: operating all latest versions of wordpress and the toolset suite.

I'm using permission levels instead of capabilities as noted in message #418463 above, so not urgent - just wondering if you could shed light on this for future reference.

Thank you and very best wishes,

Manu

#418800

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Emmanuel,

That is correct, Access does not allow you to edit the default wordpress roles.

Also when access is enabled it reads what level each role is based on capabilities. So instead of saying Authors can edit post, Create posts etc. It says Author is a level 2 role and level 2 roles can do the following.
https://codex.wordpress.org/User_Levels#User_Level_2

So using permission levels would be best to gain basic roles of that level pre-enabled and then you can add additional responsibilities to your custom role.

Please let me know if this helps.
Thanks,
Shane

#418813

Hi Shane,

I understand your point. My only concern is that I've seen lots of plugins and themes using the following function with the capability as a parameter, and from my testing, it seems that activating Access results in this function returning false when it should return true. If this is the case, then it would potentially trigger compatibility issues between Access and third party thems or plugins.

current_user_can('edit_posts');

I am marking this as resolved but it may be worth for your development team to test this behaviour and assess any potential compatibility issues.

Best wishes and thanks again for your response.

Manu

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.