There is currently only the ability to disable plugins for all users globally. Because of how confusing it would be to manage global plugins by role mainly. You can create a plugin filter with your root url set as the permalink and select also affect children. That would affect the entire site unless another plugin filter or something else overrides it.
Thread Starter
name
(@technologypoet)
Gotcha,
If I add two plugin filters, one for site.com/* and another for site.com/page-name/*, which takes preference?
I’m not 100% sure how duplicates are handled in the plugin.
Wild cards are not used on the end of a url. The logic works backwards through the url. So if the url site.com/page-name/page1/page2/ was accessed then the filter site.com/page-name would take affect because it would be the first one found. The plugin would first search for site.com/page-name/page1/page2/. If that doesn’t exist it would search for site.com/page-name/page1/. If that doesn’t exist it would search for site.com/page-name/. If that doesn’t exist it would search for site.com/.
Thread Starter
name
(@technologypoet)
Perfect thanks! I’ve been meaning to go through and be more intentional about which plugins are for logged in users vs visitors. The change you made with color coding recently will help make this easier.
I’m also curious, now that you’ve moved away from the drag and drop approach, whether you’d reconsider a global plugin enable/disable by logged in status or role?
I could imagine a dropdown list of checkboxes next to each plugin on the global plugins to select the roles it applies to, and using color coding to indicate for example:
green = everyone enabled
red = everyone disabled
some other color = selectively enabled based on role/login state (as a cue to check the dropdown to see which role/login state it’s active for).
At least from my experience, I’ve found login state to be more useful than role for plugin enable/disable (My understanding is also that checking login state alone is a faster query than checking user role)
