[wp-hackers] options capabilities bug?

[Chip Bennett]

This is a known issue, with a workaround added to 3.2. (You can see the
workaround in action in Twenty Eleven.)

Copying straight out of my own
code<https://github.com/chipbennett/oenology/blob/d586858687a4b00885a88c0b7084dd87153b1c4e/functions/options.php>(so
I don't have to rewrite the explanation):

/**
 * Filter Capability for Theme Settings Page
 *
 * This filter implements a WordPress 3.2 fix for
 * a minor bug, in which add_theme_page() is passed
 * the "edit_theme_options" capability, but the
 * settings page form is passed through options.php,
 * which expects the "manage_options" capability.
 *
 * The "edit_theme_options" capability is part of the
 * EDITOR user role, while "manage_options" is only
 * available to the ADMINISTRATOR role. So, users in
 * the EDITOR user role can access the Theme settings
 * page, but are unable actually to update/save the
 * Theme settings.
 *
 * The function is hooked into a hook, introduced in
 * WordPress 3.2: "option_page_capability_{option_page}",
 * where {option_page} is the name of the options page,
 * as defined in the fourth argument of the call to
 * add_theme_page()
 *
 * The function returns a string consisting of the
 * appropriate capability for saving Theme settings.
 */
*function** oenology_get_settings_page_cap() {*
*	return 'edit_theme_options';*
*}*
*// Hook into option_page_capability_{option_page}*
*add_action**(** 'option_page_capability_oenology-settings',
'oenology_get_settings_page_cap' );*

I added on a bit to what Twenty Eleven does, by passing
oenology_get_settings_page_cap() to add_theme_page(), just to ensure
consistency:

/**
 * Setup the Theme Admin Settings Page
 *
 * Add "Oenology Options" link to the "Appearance" menu
 */
function oenology_add_theme_page() {
	add_theme_page(
		// $page_title
		// Name displayed in HTML title tag
		'Oenology Options',
		// $menu_title
		// Name displayed in the Admin Menu
		'Oenology Options',
*		// $capability*
*		// User capability required to access page*
*		oenology_get_settings_page_cap(), *
		// $menu_slug
		// String to append to URL after "themes.php"
		'oenology-settings',
		// $callback
		// Function to define settings page markup
		'oenology_admin_options_page'
	);


So, easy fix, once you know what's going on.

Chip

On Tue, Jul 12, 2011 at 7:18 AM, Steve Taylor <steve at sltaylor.co.uk> wrote:

> I'm using Justin Tadlock's excellent Members plugin to create a "Super
> Editor" role. Basically to allow some client editors to change
> settings on the site, but to keep them from updating, installing
> plugins, etc.
>
> So, besides the usual Editor capabilities, I've assigned them the
> manage_options one.
>
> They can see the Settings menus, but when they submit one, they get
> the "You do not have permission" notice.
>
> I've tracked this down to this in my custom theme code:
>
> add_action( 'admin_menu', 'slt_all_settings_link' );
> function slt_all_settings_link() {
>        add_options_page( __('All Settings'), __('All Settings'),
> 'update_core', 'options.php' );
> }
>
> I want this "all settings page" output just for admins, so I use the
> update_core capability. However, setting it this way causes the above
> issue with users who have been granted the manage_options capability,
> but who don't have the capability set for the options.php page. If I
> change the above capability to manage_options, the other screens work
> too.
>
> Is this a bug? Or is it just something unavoidable in the way the
> internal options handling works?
>
> I'm setting the above page to be visible with manage_options for now,
> it's no biggie - just thought I report this in case there's other
> ramifications.
>
> cheers,
>
> Steve
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>