Steve Taylor photo

The WordPress edit_plugins capability

I’ve been finding more and more WordPress plugins that, when they check if the current user should be allowed to view / edit the plugin’s settings page, check whether the user has the edit_plugins capability. I think this is a bad practice; let me explain why.

If you check the Codex on Roles and Capabilities, you’ll see that there’s certain capabilities that are, by default, only assigned to admins.

Now, roles can be customized (most easily and reliably, I find, with Justin Tadlock’s Members plugin). That’s why it’s advised that, when checking whether a user can do something or not, you check what capabilities they have, not what role they’re in (usually using current_user_can).

So, as detailed by Mark Jaquith, if you want to check whether someone is an admin, you check against a capability that is by and large assigned only to admins—e.g. manage_options. True, someone might have customized their roles so, for instance, authors have the manage_options capability. But that’s stupid, and it’s their problem. As a plugin author, if you limit admin-only stuff to users with manage_options, you’ve done your job pretty well.

Checking for manage_options is obviously most suited to checks for editing options or settings. For other admin-only bits that are a bit more technical, I often use update_core. I often create a “Super Editor” role, which is pretty much like the default Editor role, but with manage_options (so clients can adjust site and plugin settings, but not upgrade or do other more technical things).

Now, as I mentioned, I’m discovering a number of plugins that use edit_plugins as a check for the plugin settings page. The thing that brought this to my attention as a problem is that I like to include this line in my wp-config.php file:

define( 'DISALLOW_FILE_EDIT', true );

You can see in the core that if this is set, it steps in on capability checks and blocks everyone from editing plugins, themes, or other files. I never use this feature of WordPress—it can be very risky on production servers, and is largely pointless on dev servers. And I certainly don’t want my clients using it. So I block it.

Unfortunately, as you’ll have guessed, this also blocks eveyone from editing the aforementioned plugins’ settings. Not good!

Initially I thought these plugin authors were using edit_plugins as a generic “admin-only” check, in the way that I use update_core. I slowly realized that they might be using it under the impression that they’re being appropriate, i.e. that edit_plugins refers to editing anything to do with plugins, e.g. settings. However, as the core and the Codex testify, that’s not true. This capability refers to editing plugin files.

Unless you’ve got a good reason to do otherwise, the capability you should use to check if the user should access your plugin settings (usually passed to add_options_page) is manage_options.

By all means choose something else if it’s related to the functionality you’re protecting. If your plugin include some kind of exporting functionality, check against the export capability. But if you do need a more generic “admin-only” capability to check against, use something unlikely to be disabled, such as update_core. The very handy DISALLOW_FILE_EDIT constant means that edit_files, edit_themes and edit_plugins are all a bad choice for checking if you’re dealing with an admin.