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
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