[wp-hackers] options capabilities bug?

[Steve Taylor]

Sorry, should have checked Trac first :-\  Thanks, Chip!


On 12 July 2011 13:31, Chip Bennett <chip at chipbennett.net> wrote:
> 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
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>