|
Andrea
|
June 5, 2023 at 11:20 am
I’m using the Members plugin to limit access to certain information based on user role. I’m running into a couple issues. First, when the Members plugin is active these warnings show at the top of the event page:
Warning: Attempt to read property “name” on null in /home/xxx/wp-content/plugins/members/admin/class-meta-box-content-permissions.php on line 146
Warning: Attempt to read property “public” on null in /home/xxx/wp-content/plugins/members/admin/class-meta-box-content-permissions.php on line 146
Warning: Attempt to read property “name” on null in /home/xxx/wp-content/plugins/members/admin/class-meta-box-content-permissions.php on line 148
If I need to use a different plugin, I can. But I also have a question about the user integration setup — from what I can see in the documentation, the access to tickets is set by capability, not by role. Instead of “subscriber” in the “Ticket Capability Requirement” box, you suggest “read” — but what if all of your roles have the same capabilities and the only difference IS the name of the role.
Is there something I can use to equate the roles I already have so I can enter roles in the box instead of capabilities?
For example, I only want a certain ticket to be available to people with the role “X” or “Y” but not “Z” — can I limit just based on the role itself? All of the roles are already set up and in use for other things on the site.
|
|
Tony
|
June 6, 2023 at 5:29 am
Hi there,
Warning: Attempt to read property “name” on null in /home/xxx/wp-content/plugins/members/admin/class-meta-box-content-permissions.php on line 146
Warning: Attempt to read property “public” on null in /home/xxx/wp-content/plugins/members/admin/class-meta-box-content-permissions.php on line 146
Warning: Attempt to read property “name” on null in /home/xxx/wp-content/plugins/members/admin/class-meta-box-content-permissions.php on line 148
Hmm, so this is because they are using $type = get_post_type_object( get_current_screen()->post_type ); to get the post type object and I don’t think the event editor sets it post at the point they are running the above.
I’ll check with our developers on this.
If I need to use a different plugin, I can. But I also have a question about the user integration setup — from what I can see in the documentation, the access to tickets is set by capability, not by role. Instead of “subscriber” in the “Ticket Capability Requirement” box, you suggest “read” — but what if all of your roles have the same capabilities and the only difference IS the name of the role.
The short answer to that question is the above is using roles ‘incorrectly’.
A role is a collection of capabilities, it’s the capability that gives you the access, not the role. For example, if I create an Administrator role with nothing more than the read capability, is it an Administrator because of the name?
WordPress muddies the water a little because it DOES actually support passing the role name to the capability check, but it’s NOT the correct way to do it and will likely eventually stop working. For more details see here:
https://core.trac.wordpress.org/ticket/22624
Usually, when I tell people the above the response is something along the lines of “But it’s working great everywhere” to which my answer is for now it is sure and that’s great for you… until it doesn’t.
Now, having said all that there is nothing stopping you from using the role name within the ticket capability section right now, it just uses current_user_can() in the background so it supports whatever WordPress does.
So yes it works, but its not recommended 🙂
|
