Permissions: Failure to launch

There seems to be some unneeded checks for manage_options() around several of your functions that have made this quite a pain in the butt to work with.

For example, let’s say we want clients to be able to see the Dashboard sub-page. That is done here:

function a360_admin_menu() {
	if (current_user_can('manage_options')) {
		add_options_page(
			__('Settings', 'analytics360'),
			__('Analytics360°', 'analytics360'),
			'manage_options',
			basename(__FILE__),
			'a360_settings_form'
		);
		add_dashboard_page(
			__('Dashboard', 'analytics360'),
			__('Analytics360°', 'analytics360'),
			'manage_options',
			basename(__FILE__),
			'a360_dashboard'
		);
	}
}
add_action('admin_menu', 'a360_admin_menu');

I can normally hook into and change the manage_options() permission around add_dashboard_page() (for example) by doing the following:

/**
 * Change the capability to access an admin menu item.
 *
 * @wp-hook admin_head
 * @return void
 */
function wpse_71303_change_menu_cap()
{
	global $submenu;
	foreach ($submenu['index.php'] as $dashboard => $key) {
		if ($key[0] == 'Analytics360°') {
			$submenu['index.php'][$dashboard][1] = 'analytics_360';
		}
	}
}
add_action( 'admin_head', 'wpse_71303_change_menu_cap' );

Which pulls in the global $submenu var, runs through each menu item and then assigns a new capability to each match (in this case, my custom capability is analytics_360). Problem is, there is an additional check around add_options() and add_dashboard_page() for manage_options() which makes any attempts for this mute.

This also appears to be done in a360_request_handler() for example. If you just leave the manage_options() checks to the menu addition functions, you don’t need to reiterate them in the display functions themselves (or for loading assets) as they will take care of themselves.

I’d really appreciate your thoughts on this. Thanks.

http://wordpress.org/extend/plugins/analytics360/