Add Compatibility for Paid Memberships Pro Membership Manager Add On

[tictag]

The Paid Memberships Pro Membership Manager Add On (https://www.paidmembershipspro.com/add-ons/pmpro-membership-manager-role/) enables non-admins to access Paid Memberships Pro, which is great, however with the Remove Dashboard Access plugin active, access to Paid Memberships Pro is denied even though the menu is visible. These two plugins appear to be mutually exclusive; you can have one but not the other.

Is there a way to make these two plugins play nicely together?

OR

Could the Remove Dashboard Access plugin be refactored to select roles from a list rather than just having the three options (Administrators Only, Editors & Administrators, Authors, Editors, and Administrators)?

OR

Is there a way to enable certain plugins i.e. bypass the plugin? For example, Paid Memberships Pro in this case.

[DrewAPicture]

Is there a way to make these two plugins play nicely together?

I can look to see if there's a reasonable path toward adding PMP compat, sure.

Could the Remove Dashboard Access plugin be refactored to select roles from a list rather than just having the three options (Administrators Only, Editors & Administrators, Authors, Editors, and Administrators)?

Each of those options just serve as an easy way to define the fourth option (a specific capability). Perhaps PMP has a custom capability you could enter directly instead.

Is there a way to enable certain plugins i.e. bypass the plugin? For example, Paid Memberships Pro in this case.

See the previous two answers, but there's also a few hooks scattered about, such as the rda_allowed_pages filter that would allow you to whitelist PMP-specific admin pages (based on their $pagenow values).

Roles are typically governed by certain capabilities, so my best suggestion most of the time is to find the best suited capability to match whatever role you're trying to align with. In fact, this is exactly the approach I already took with adding the Administrators, Administrators & Editors, and Administrators, Editors, & Authors settings.

They're all pinned to specific individual capabilities, which are exposed via the fourth "Specific Capability" choice when you save the settings (you select one of those and the capability tied to it gets saved in the fourth option and that capability is what's used to determine access. It's not super complicated. 😉)

[tictag]

RE playing nicely together ... thank you.

RE selecting roles ... I understand from your response that the radio selections are there to automate the selection of capabilities but ultimately it's the capabilities that are used to process access. That's great but misses my point. This feature request would be to remove the radio-button options and instead have a multi-select list where the customer could simply select individual roles e.g. Administrator, Editor, Membership Manager etc. Just thought that this would give your customers greater flexibility. I am, of course, assuming that there is an easy way to 'lookup capabilities' for a given role.

I am not clever enough to know what capabilities an Administrator (role) has but I do know that PMPro has the pmpro_edit_memberships capability. So, if I wanted to grant admin dashboard access to all Administrators and accounts with the pmpro_edit_memberships capability, what should be selected?

RE bypassing the plugin ... thank you, perhaps a workaround if we are unable to solve this via the user access settings.

[DrewAPicture]

I am not clever enough to know what capabilities an Administrator (role) has but I do know that PMPro has the pmpro_edit_memberships capability.

The settings screen links to the Roles & Capabilities article in the Codex, which spells out which capabilities are tied to which roles in WordPress. And as I said, tying access to roles is a misnomer. Access isn't tied roles anywhere in WordPress, it's tied to the capabilities that define the roles.

So, if I wanted to grant admin dashboard access to all Administrators and accounts with the pmpro_edit_memberships capability, what should be selected?

You would choose the "Advanced" option and select the pmpro_edit_memberships capability from the drop-down.

[tictag]

Just to make doubly-sure, as I will be removing the 'Administrators Only' option and setting just the pmpro_edit_memberships capability, this will still allow accounts with the Administrator role assigned full access, right?

I don't want to limit Administrator access to a capability that only exists because of a plugin.

[DrewAPicture]

Hi @tictag, sorry, I missed your last follow up message.

I don't want to limit Administrator access to a capability that only exists because of a plugin.

That's probably a smart move not to do that, yes. My best suggestion would be to filter user_has_cap to ensure that anybody who is an admin (has the manage_options capability, for instance), also has the specified pmpro_edit_memberships capability too.

Something like this should do it (untested):

<?php
add_filter( 'user_has_cap', function( $caps ) {
    if ( ! empty( $caps['manage_options'] ) ) {
        $caps['pmpro_edit_memberships'] = true;
    }
    return $caps;
} );

[tictag]

Hey @DrewAPicture, no probs, we're all busy ;-)

No, I think we're looking at this the wrong way around. I don't want to give Administrators the pmpro_edit_memberships capability, they can already view the (PMPRo) memberships pages, this issue is around non-admins being able to view the (PMPro) memberships pages.

So, for example, if the Administrator role had x, y & z capabilities e.g. manage_options, then I would like to configure Dashboard Access so that capabilities x, y & z AND pmpro_edit_memberships had access. This would mean no change to default Administrator access but if a non-admin user was assigned to the Membership Manager role, they too would be able to access the admin dashboard.

[DrewAPicture]

Right, so in that case I'd still be tempted to do something similar to the aforementioned solution, but tie access to a custom capability or something and then use map_meta_cap to determine which "primitive" capabilities line up with that custom capability.

Either way, the next version of the plugin is going to have a filter to short-circuit is_user_allowed(), which would make something like what you're talking about much more straightforward.

[tictag]

Thanks, Drew, unfortunately I don't understand your response but that's due to my own lack of knowledge/competence. I assume your solution will work for those playing along at home so please feel free to close the issue.

[DrewAPicture]

Sorry if it went over your head. It's possible that this plugin isn't able to easily help you solve your problem at this time and that's ok! I'm happy to have had an opportunity to consider a new and interesting use case. Maybe I can help you solve it in the future.