WordPress comes with the settings API, an API that simplifies development of configuration pages. It’s a complete API, with regard to function and security. This post will take a look at security, more specific, at access control.

Access control is about controlling access to a configuration page. WordPress uses capabilities to filter who can access the page and who can’t. The default capability to manage an option page is manage_options, meaning the user is an administrator. This is probably the best choice for 90% of the configuration pages, but if you’re using a plugin that uses data maintained by another service to create a page (like LiPS does), manage_options is just too much. Every WordPress user with the capability edit_pages is permitted to create a page. An editor holds this capability and has edit_published_pages too, so modifying a published page is permitted too. And that’s about everything LiPS does, so it does not require administrative privileges.

The settings API knows which privilege a user must hold by add_submenu_page. A user with the right capabilities will be able to view or modify the settings, but as soon as the settings are saved, this person will see the famous Cheatin', uh? error. This is because options.php assumes every page uses manage_options, and an editor does not hold that capability. So, an editor can view and change settings but not save them.

There is a filter hook that solves the error. The name of the filter is a concatenation of option_page_capability_ and the value for the $option_group provided to register_setting and settings_fields. A filter is required to return a value, which is the name of the capability. For LiPS, the return value is edit_pages and the name of the hook is option_page_capability_e75b15d0_a917_4711_9347_5033834de19b.