This is an interesting request. I’ve never done this.
The cleanest way would be to see if there are any generic techniques for preventing a plugin from running/loading so the plugin doesn’t execute at all. However, I’ve never thought about doing that before and I don’t know if it’s feasible.
The plugin hides/deactivates features through a variety of JavaScript, CSS, and PHP, so it would be pretty difficult to prevent the plugin from acting.
So if you can’t literally prevent the plugin from running, I think I would recommend return empty arrays for all the plugin’s filters by user role. Something like this (untested):
if( current_user_can( 'manage_options') {
add_filter( 'mrw_hidden_blocks', '__return_empty_array' );
add_filter( 'mrw_hidden_block_styles', '__return_empty_array' );
add_filter( 'mrw_hidden_block_editor_settings', '__return_empty_array' );
add_filter( 'mrw_hidden_embeds', '__return_empty_array' );
// continue for all other plugin filters
}
I’m curious if you end up doing this and how it works out, so I’d love to have you report back. I can potentially foresee some issues with admins using settings like margin that editors can’t adjust (or unwittingly clone), but I can also see the rationale for doing it.
While not quite the same, there’s also a somewhat experimental $context
parameter passed to all the hidden block filters (and not others) that can be useful for adjust the behavior of those filters based on the screen in the admin being looked at. I could potentially foresee extending that to be on most filters, as possible.