Solution to: How to allow Editors to edit Menus (only!)

Hallelujah! I finally found a way to allow Editors (or other roles) to just have the ability to edit Menus – without access to Themes, Widgets or Background, that is normally only allowed to Admins.

Actually, the solution allows you to Enable or Disable ANY of the APPEARANCE options (sub-menus: Themes, Widgets, Menus, Background) that is reserved only for Admins.

My search for a way to do this (Google, StackExchange, WP Forums, etc.) came up empty handed because granting the ‘edit_theme_options’ capability is not granular and is (until now) an “All or Nothing” solution as posted and commented on throughout all the posts, articles, forums and comments that I had come across.

In other words, if you granted ‘edit_theme_options’ to a role, such as an Editor, the role had access to all options: Themes, Widgets, Menus, and Background – no matter what.

Then in a moment of inspiration and Thanks to Firebug, I had thought of the idea of why not hide those elements via CSS for which you cannot control? Bingo.

After about 3 hours research and figuring out CSS selectors (and several 1 hour breaks to help my wife paint the kitchen – Hey: Happy Wife = Happy Life! And I’m very happy, btw), I figured out a quick, easy and elegant solution. Actually, I spent more time writing the comments than figuring out the CSS selectors to use…

The Rest of the Story is in the comments of the code snippet. Yes, I prefaced the actual short amount of code with a LONG Comment Intro. But there’s a reason for it. Hey, it’ my code and I can comment if I want to! lol

Here you go:

The whole Code with Comments follows. However I noticed sliding the view back and forth to read the comments/code is a real pain, so after the Code section, is the Comments by it’s self, for your reading pleasure…

Then I realized the WP Wizards out there probably just want the code snippet by itself, no explanations required. So for that, scroll to the very end of this post to get it.

<?php
/*
 * A Solution for non-Admins (ie, Editor's) for accessing (Admin's) Menus and ONLY Menus (or more if you like).
 * A Short Story told Long... You can remove the comments if you want, or choose to keep them for reference sake!
 * (Verbosity is due to that while many may be WP Wizards, most are not.  Plus, I like the sound of my typing...)
 *
 * Why in the Footer?  Because CSS is hierarchial in nature, what comes after usually supercedes what came before.
 * The Footer is the last piece/section to load, therefore any <style> provided should override anything previous.
 * Finally, the Dashboard for any User comes from the wp-admin directory and files.  Ergo, the admin-footer.php
 *
 * NOTE: Where to put this?  Try AFTER:  <div id="wpfooter"> AND BEFORE: <?php do_action( 'in_admin_footer' ); ?>
 *
 * This addition to the wp-admin footer uses CSS selectors to HIDE {display:none} the APPEARANCE sub-menu options
 * you don't want non-Admins to have by default, because the 'edit_theme_options' capability is "all or nothing".
 * This modification/addition fixes that.  Simply comment out the CSS style line below for the option you WANT to
 * allow, leaving any remaing active lines to hide that option from being available.  The IF statements are used
 * to check and see if the logged in user is an Admin or non-Admin user.  (True Admins should only have access to
 * the "manage_options" capability.)
 *
 * But how does one give non-Admins (such as Editor's) specific and limited Admin functions or options such as the
 * 'edit_theme_options' capability?  While there may be other plugins available that can do this, the plugin I have
 * found that works well for me is the Advanced Access Manager (AAM) plugin.  While not intuitive (Okay, not much
 * in the way of "on page" Help, FAQ's or Readme's, but once you figure out how it works, it is very simple to use.
 * I've not delved into it much, as I only set the Editor role to have certain Admin functionality.  Caveat emptor!
 *
 * Oh what the heck...  The quick and dirty on the Advanced Access Manager (AAM) plugin after initial activation:
 * (1) To remove the "Config File is not Writable" message, you will need to give write permissions to this file:
 * .../wp-content/plugins/advanced-access-manager/config.ini  (minimum 666/777  depending on server hosting, etc.)
 * (2) To remove the "Module Directory is not Writable" message, you will need to give write permissions to this
 * directory:  .../wp-content/plugins/advanced-access-manager/model  (chmod 777 on directory only, NO recursive!)
 *
 * The "Read more..." links takes you to the author's website Forum for Troubleshooting with no clear answers...
 * Fortunately I provided clear answers.  (Note the Premium version requires the above file and directory to have
 * the permissions set to work right.  What's good for Premimum must be good for the free Basic version, right?)
 *
 * NOTE:  I suggest enabling permissions BEFORE making changes with AAM, then revert back to protected settings
 *	  AFTERWARDS for the file and directory permissions.  I mean, who wants to open things up for hackers?
 *	  It shouldn't a big bother to do this, as how often do you really need to modify the Roles? Set & Forget.
 *
 * Now, to understand how AAM works:  Select ACCESS MANAGER option under the AWM GROUP (anything else displays info
 * and upselling to Premium version of AAM and another plugin by the author.  Plus a Javascript error message. lol).
 *
 * Once you're in the Access Manager, there are three (3) panels displayed: (A) Options List panel with Tabs, then
 * (B) General panel in the upper right, and (C) Role Manager panel (below General).  What you need to know (as I
 * finally figured out) is to FIRST go to the General panel and CHANGE the current role from Administrator to the
 * Editor (or whatever role you want to edit/change).  Then in the Options List panel, select the CAPABILITIES tab
 * to display the current capabilities of the current role you selected previously in the General panel.  What will
 * happen is the Options List panel will now display the CURRENT options available for the role selected, including
 * any and all previous modifications made and SAVED previously with AAM.  If no previous changes, its WP defaults.
 *
 * One thing you need to know:  The buttons in the lower right area of the Options List panel (Admin, Editor, etc.)
 * sets all the options to the WORDPRESS DEFAULTS for the ROLE of the button clicked.  Use them only to set the WP
 * original defaults for the role, then in the General Panel, click the SAVE button to make it happen.  As long as
 * you don't click Save, no harm or change is made.  Whew!  (Author is not fluent in English, so syntax is... odd.)
 *
 * So now that you've selected the Role (ie, Editor) in the General panel and then selected the Capabilities tab in
 * the Options List panel, you are now ready to add/edit/modify capabilites of the Role by checking or un-checking
 * options as you desire.  Once you are done, click the SAVE button in the General panel.  That's it.  Now you have
 * just added/removed capabilites for that Role.  (My suggestion is to NEVER edit the Administrator's Role unless
 * you absolutely and positively know what you are doing.  Can you say Lockout?  Besides, Admin's are supposed to
 * be ALL POWERFUL, so why diminish it?  Google:  BOFH Stories  (Very Educational, lol)
 *
 * Another sweet thing about AAM btw, is that it sees/picks up on other Admin type plugins and lists them under the
 * Capabilites tab under the MISCELLANEOUS Section (well, Author spells is MISCELANEOUS :^).  So if you want, you
 * can easily give/extend those Admin functions to Editors or other Roles as you like. (ie, Calendar Event plugins)
 *
 * Finally, if you don't want to Add Another Plugin, you can edit and modify the (or Theme's) functions.php file to
 * add the following snippet to just give/allow the Editor Role the 'edit_theme_options' capability:
 *
   <?php
   // Best to put this at the END of the functions.php file, so it's not nested by accident in any logic statements.
   $role = get_role('editor'); // Or any role type
   $role->add_cap('edit_theme_options'); // More CAP types and info at WP.org - Search for:  ROLES and CAPABILITIES
   ?>
 *
 * The End
 *
 * PS ~ You're welcome!
 * PSS ~ Why all the verbage? 'Cuz you'll read the post, cut & paste to use it, then forget where & why you did it.
 *	 Now it's in the Mod's comments! (Unless you delete the comments!  Then you're up a creek without a paddle.)
 */

if ( is_user_logged_in() ) { // This IF may be redundant, but safe is better than sorry...
	if ( current_user_can('edit_theme_options') && !current_user_can('manage_options') ) { // Check if non-Admin

	// NOTE: All <style> statement(s) are "supposed" to be within the <head> per HMTL DTD for validation,
	//	 else it won't validate.  If that isn't important to you (me neither), it doesn't matter as all
	//	 browsers support it anyway.  Well, until the HTML DTD police knocks on my door... lol
	//	 And if some PFY wants to "fix" this mod to be Politically HTML DTD correct, go for it!
?>

<style type="text/css">
<!-- /* Comment out the line you WANT to enable (display) */ -->
li#menu-appearance.wp-has-submenu li a[href="themes.php"] { display:none; } <!-- /* THEMES */ -->
li#menu-appearance.wp-has-submenu li a[href="widgets.php"] { display:none; } /* WIDGETS */
<!-- /* li#menu-appearance.wp-has-submenu li a[href="nav-menus.php"] { display:none; } */ /* MENUS */ -->
li#menu-appearance.wp-has-submenu li a[href="themes.php?page=custom-background"] { display:none; } <!-- /* BACKGROUND */ -->
</style>

<?php
	} // End IF current_user_can && !current_user_can
} // End IF is_user_logged_in and END OF THIS MODIFICATION/ADDITION ?>

Just They Comments, Please:

A Solution for non-Admins (ie, Editor’s) for accessing (Admin’s) Menus and ONLY Menus (or more if you like). A Short Story told Long… You can remove the comments if you want, or choose to keep them for reference sake! (Verbosity is due to that while many may be WP Wizards, most are not. Plus, I like the sound of my typing…)

Why in the Footer? Because CSS is hierarchial in nature, what comes after usually supercedes what came before. The Footer is the last piece/section to load, therefore any <style> provided should override anything previous. Finally, the Dashboard for any User comes from the wp-admin directory and files. Ergo, the admin-footer.php

NOTE: Where to put this? Try AFTER: <div id=”wpfooter”> AND BEFORE: <?php do_action( ‘in_admin_footer’ ); ?>

This addition to the wp-admin footer uses CSS selectors to HIDE {display:none} the APPEARANCE sub-menu options you don’t want non-Admins to have by default, because the ‘edit_theme_options’ capability is “all or nothing”.
This modification/addition fixes that. Simply comment out the CSS style line below for the option you WANT to allow, leaving any remaing active lines to hide that option from being available. The IF statements are used to check and see if the logged in user is an Admin or non-Admin user. (True Admins should only have access to the “manage_options” capability.)

But how does one give non-Admins (such as Editor’s) specific and limited Admin functions or options such as the ‘edit_theme_options’ capability? While there may be other plugins available that can do this, the plugin I have found that works well for me is the Advanced Access Manager (AAM) plugin. While not intuitive (Okay, not much in the way of “on page” Help, FAQ’s or Readme’s, but once you figure out how it works, it is very simple to use. I’ve not delved into it much, as I only set the Editor role to have certain Admin functionality. Caveat emptor!

Oh what the heck… The quick and dirty on the Advanced Access Manager (AAM) plugin after initial activation: (1) To remove the “Config File is not Writable” message, you will need to give write permissions to this file: …/wp-content/plugins/advanced-access-manager/config.ini (minimum 666/777 depending on server hosting, etc.) (2) To remove the “Module Directory is not Writable” message, you will need to give write permissions to this directory: …/wp-content/plugins/advanced-access-manager/model (chmod 777 on directory only, NO recursive!)

The “Read more…” links takes you to the author’s website Forum for Troubleshooting with no clear answers… Fortunately I provided clear answers. (Note the Premium version requires the above file and directory to have the permissions set to work right. What’s good for Premimum must be good for the free Basic version, right?)

NOTE: I suggest enabling permissions BEFORE making changes with AAM, then revert back to protected settings AFTERWARDS for the file and directory permissions. I mean, who wants to open things up for hackers? It shouldn’t a big bother to do this, as how often do you really need to modify the Roles? Set & Forget.

Now, to understand how AAM works: Select ACCESS MANAGER option under the AWM GROUP (anything else displays info and upselling to Premium version of AAM and another plugin by the author. Plus a Javascript error message. lol).

Once you’re in the Access Manager, there are three (3) panels displayed: (A) Options List panel with Tabs, then (B) General panel in the upper right, and (C) Role Manager panel (below General). What you need to know (as I finally figured out) is to FIRST go to the General panel and CHANGE the current role from Administrator to the Editor (or whatever role you want to edit/change). Then in the Options List panel, select the CAPABILITIES tab to display the current capabilities of the current role you selected previously in the General panel. What will happen is the Options List panel will now display the CURRENT options available for the role selected, including any and all previous modifications made and SAVED previously with AAM. If no previous changes, its WP defaults.

One thing you need to know: The buttons in the lower right area of the Options List panel (Admin, Editor, etc.) sets all the options to the WORDPRESS DEFAULTS for the ROLE of the button clicked. Use them only to set the WP original defaults for the role, then in the General Panel, click the SAVE button to make it happen. As long as you don’t click Save, no harm or change is made. Whew! (Author is not fluent in English, so syntax is… odd.)

So now that you’ve selected the Role (ie, Editor) in the General panel and then selected the Capabilities tab in the Options List panel, you are now ready to add/edit/modify capabilites of the Role by checking or un-checking options as you desire. Once you are done, click the SAVE button in the General panel. That’s it. Now you have just added/removed capabilites for that Role. (My suggestion is to NEVER edit the Administrator’s Role unless you absolutely and positively know what you are doing. Can you say Lockout? Besides, Admin’s are supposed to be ALL POWERFUL, so why diminish it? Google: BOFH Stories (Very Educational, lol)

Another sweet thing about AAM btw, is that it sees/picks up on other Admin type plugins and lists them under the Capabilites tab under the MISCELLANEOUS Section (well, Author spells is MISCELANEOUS :^). So if you want, you can easily give/extend those Admin functions to Editors or other Roles as you like. (ie, Calendar Event plugins)

Finally, if you don’t want to Add Another Plugin, you can edit and modify the (or Theme’s) functions.php file to add the following snippet to just give/allow the Editor Role the ‘edit_theme_options’ capability:

<?php
// Best to put this at the END of the functions.php file, so it’s not nested by accident in any logic statements.
$role = get_role(‘editor’); // Or any role type
$role->add_cap(‘edit_theme_options’); // More CAP types and info at WP.org – Search for: ROLES and CAPABILITIES
?>

The End

PS ~ You’re welcome!

PSS ~ Why all the verbage? ‘Cuz you’ll read the post, cut & paste to use it, then forget where & why you did it. Now it’s in the Mod’s comments! (Unless you delete the comments! Then you’re up a creek without a paddle.)

Just the Code, Please:

<?php
if ( is_user_logged_in() ) { // This IF may be redundant, but safe is better than sorry...
	if ( current_user_can('edit_theme_options') && !current_user_can('manage_options') ) { // Check if non-Admin

	// NOTE: All <style> statement(s) are "supposed" to be within the <head> per HMTL DTD for validation,
	//	 else it won't validate.  If that isn't important to you (me neither), it doesn't matter as all
	//	 browsers support it anyway.  Well, until the HTML DTD police knocks on my door... lol
	//	 And if some PFY wants to "fix" this mod to be Politically HTML DTD correct, go for it!
?>

<style type="text/css">
<!-- /* Comment out the line you WANT to enable (display) */ -->
li#menu-appearance.wp-has-submenu li a[href="themes.php"] { display:none; } <!-- /* THEMES */ -->
li#menu-appearance.wp-has-submenu li a[href="widgets.php"] { display:none; } /* WIDGETS */
<!-- /* li#menu-appearance.wp-has-submenu li a[href="nav-menus.php"] { display:none; } */ /* MENUS */ -->
li#menu-appearance.wp-has-submenu li a[href="themes.php?page=custom-background"] { display:none; } <!-- /* BACKGROUND */ -->
</style>

<?php
	} // End IF current_user_can && !current_user_can
} // End IF is_user_logged_in and END OF THIS MODIFICATION/ADDITION ?>