WordPress.org

Ready to get started?Download WordPress

Forums

WordPress Settings API "Cheatin' Uh?" Error (8 posts)

  1. ashblue
    Member
    Posted 3 years ago #

    To follow the previous conversation leading to this post view the thread here.

    Looks like a fix for the Cheatin Uh error for roles who don't have access to manage_options with the Settings API make it into version 3.3 of WordPress. To follow the progress on this check out the current standing track ticket http://core.trac.wordpress.org/ticket/14365.

    In the meantime here is a workaround below for those of us who want to create special roles like "Admin Light" and still use the settings API without giving them manage_options access. It isn't the best solution, but will have to do for now unless somebody comes up with something better. Hopefully this saves you several traumatizing hours of searching and banging your head on a keyboard.

    1. You'll need to add manage_options to the role type.

    2. Strip the settings menu from the role type with the code below. While they might be still be able to access this with the exact URL structure, this should be enough to keep them out of the settings they don't belong in and plugins. The odds of them chucking in the exact URL structure are slim to none so please don't argue with me on this. Also, this means you'll want to include your special menu somewhere other than Settings.

    In functions.php

    function remove_menus () {
    	// Choose an option that the custom role doesn't have access to
    	if(! current_user_can('update_core')) {
    		global $menu;
    		$restricted = array(__('Settings'));
    		end ($menu);
    		while (prev($menu)){
    			$value = explode(' ',$menu[key($menu)][0]);
    			if(in_array($value[0] != NULL?$value[0]:"" , $restricted)){unset($menu[key($menu)]);}
    		}
    	}
    }
    add_action('admin_menu', 'remove_menus');

    Does anyone have a better solution for this other than editing the WP core files?

  2. Mark Rowatt Anderson
    Member
    Posted 3 years ago #

    In WP3.2 there is a reasonably straightforward way to solve this.

    If you have a setting registered such as
    register_setting('my-settings','some_field');

    Then you can give give any capability the ability to edit settings in that group with a simple filter, for example:
    add_filter('option_page_capability_my-settings', create_function(NULL, 'return "edit_my_settings";') );

    Where 'edit_my_settings' is the capability you have given to users who can edit those settings.

    Note that this won't work well (or possibly at all) if you have multiple settings groups on one options page.

  3. Chip Bennett
    Theme Review Admin
    Posted 3 years ago #

    I wouldn't use use an anonymous function; I would consider Twenty Eleven's implementation to be current best practice:

    function twentyeleven_option_page_capability( $capability ) {
    	return 'edit_theme_options';
    }
    add_filter( 'option_page_capability_twentyeleven_options', 'twentyeleven_option_page_capability' );
  4. Eran Miller
    Member
    Posted 2 years ago #

    Awesome!
    Thanks Chip, this was exactly the information I was seeking!

  5. Mark Rowatt Anderson
    Member
    Posted 2 years ago #

    Chip - could you elaborate why you consider not using anonymous functions to be best practice? There is no mention of this in the WordPress coding standards, and other than one reference which states that create_function isn't cached (which isn't really relevant for a filter only used in admin) I can't find any reason not to use create_function.

  6. Chip Bennett
    Theme Review Admin
    Posted 2 years ago #

    Chip - could you elaborate why you consider not using anonymous functions to be best practice? There is no mention of this in the WordPress coding standards, and other than one reference which states that create_function isn't cached (which isn't really relevant for a filter only used in admin) I can't find any reason not to use create_function.

    Currently, the most practical reason not to use anonymous functions is that only PHP 5.3 supports them, and only 8% of current WordPress installations are running on PHP 5.3.

  7. Mark Rowatt Anderson
    Member
    Posted 2 years ago #

    While it is correct that true anonymous functions are only PHP5.3+, the create_function function has been in PHP since PHP4.0.1 so there shouldn't be any compatibility issues for WordPress sites.

  8. enailor
    Member
    Posted 2 years ago #

    Chip! Thank you!
    That worked great!

    Note to others:
    In the code Chip posted from the TwentyEleven theme, the filter for "option_page_capability_twentyeleven_options" refers to the options group that was registered.

    So for your code, if you have registered an options group call mytheme_options, the filter would then be "option_page_capability_mytheme_options".

    This took me a minute to figure out.

    Enjoy!
    Ed

Topic Closed

This topic has been closed to new replies.

About this Topic