WordPress 3.2: Fixing the edit_theme_options/manage_options bug

Theme Developers:

Many of you are aware of a minor bug in the Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. implementation for Themes, in which add_theme_page() is passed the “edit_theme_options” capability, but the settings form submission via options.php requires the “manage_options” capability, resulting in users with the Editor role having access to the settings page, but being unable to submit the settings page form.

Fortunately, WordPress 3.2 adds a new filter that can be used to resolve this issue: option_page_capability_{option_page}, where {option_page} is the name of the option page, as defined in the fourth parameter passed to add_theme_page().

To get an idea of how to implement the fix, refer to the patch for the filter, which also includes an implemented fix for TwentyEleven. The key is to ensure that the capability passed to the hook is the same as the capability passed to add_theme_page.

Here’s one example of how to implement:

First, create a function to return the “edit_theme_options”:

function themeslug_get_options_page_cap() {
    return 'edit_theme_options';

Then, hook the function:

add_filter( 'option_page_capability_themeslug-options', 'themeslug_get_options_page_cap' );

Then, ensure consistency with the add_theme_page() call. Notice that I replace the hard-coded string with the previously defined function:

    'Theme Name Options',
    'Theme Name Options',

If you’re already testing against the 3.2 Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. (and you are, aren’t you?), you should now be able to save Theme settings as a user with the Editor role.

#3-2, #best-practices, #settings-api