Admin Menu Editor For WordPress
Here is my latest and hack-iest plugin yet – Admin Menu Editor. It’s a WordPress plugin that will let you manually edit the Dashboard menu. You can reorder the menus, show/hide specific items, change access rights, and more. The plugin is still a bit rough around the edges, so a good understading of WP internals is recommended (but not required).
Features
- Sort menu items any way you want by simple drag & drop.
- Move a menu item to a different submenu via cut & paste. Note that if you move an item that belongs to a plugin, you will need to modify the “File” attribute to point to the right parent file (e.g. instead of “akismet-key-config” use “options-general.php?page=akismet-key-config”).
- Edit any existing menu – change the title, access rights, menu icon and so on. Note that you can’t lower the required access rights, but you can change them to be more restrictive.
- Hide/show any menu or menu item. A hidden menu is invisible to all users, including administrators.
- Create custom menus that point to any part of the Dashboard. For example, you could create a new menu leading directly to the “Pending comments” page.
Here’s a screenshot :
Download
menu-editor.zip (27 KB)
Requirements :
- WordPress 2.7 or later
- PHP 5 or later
Known Issues
The basic idea for the plugin was suggested by several commenters way back in October. However, the internal menu system that WordPress uses is obscure and unsuitable for direct manipulation, so I spent quite a while inventing workarounds. And even after a few weeks of pondering, there are some things I haven’t quite fixed.
- If you delete any of the default menus they will reappear after saving. This is not a bug, it’s a feature
- You can’t use arbitrary URLs as menu targets because WordPress will automatically strip off the “http:/”.
- As I mentioned before, the access rights required for using a particular menu item can’t be lowered, but can be made more strict. I think.
- Also, a plugin’s menu that is moved to a different submenu will not work unless you also include the parent file in the “File” field. This is because WP “ties” the menu item to it’s parent menu and won’t recognize it in a different submenu.
Merry Christmas, by the way 
Could you name at least one of the problematic plugins? I’d like to test those plugins myself and, if possible, make the menu editor coexist peacefully with them. Right now I just don’t see how
get_settingscould be a problem, because internally it’s just a wrapper forget_option(at least in newer versions of WordPress).I may have expressed myself badly; as far as I can tell it’s not your code that’s the problem, it’s the code in the other plugins that’s the problem.
For example using the WP CMS Post Control plugin in conjunction with SarahG’s Page Menu Editor and OZH Admin Drop Down Menu seems quite frequently to cause problems for ME, especially if a] there are a lot of plugins and b] during the process of site development one is adding and then removing and then re-adding various plugins for testing purposes to discover which combinations of plugin do work together in a friendly manner.
One of the issues I’ve noted with some dismay is that not all plugin authors use a sensible cleanup option when their plugin is deactivated; in other words they leave their junk behind in the options table when the plugin is deactivated. What a well-behaved plugin _should_ do on deactivation is offer to export the current settings to a suitable file in the plugin directory, and then remove all of its current settings: if one then reactivates the plugin one should then be able to import the old settings. As we all know, over time the WP options table can get very messy. Yes I know there are plugins to inspect and clean the options table, but that’s beside the point: by and large with well-designed plugins one should not have to go cleaning out the options in the first place.
In my case, one of the common things I’ve found is that at a certain point, having added/removed and possibly re-added various plugins ME simply will not show on the menus one or more plugin items that are actively installed and functional and there’s no way back from that except to drop the WP tables, recreate and reinstall the plugins. Cleaning out the options table doesn’t help.
Right now I have one site in development which has the Upload+ plugin installed, [together with quite a few other plugins] but Upload+ isn’t showing up in ME or on any of the admin menus. Clearing the WP and browser caches isn’t going to change that visibility issue.
I see. I’ll test some of the plugins you mentioned later.
However, I disagree with the idea that a plugin should clean up it’s options/database records when it is deactivated. There are lots of situations where plugins are deactivated only temporarily, like when upgrading the plugin or updating the WordPress core itself. It would be impractical to make the user explicitly import the old settings every time.
Instead, I think plugins should clean up when they’re uninstalled, which is both more intuitive and easier to implement. WP 2.7 even introduced an uninstallation API, though most plugin authors still haven’t updated their plugins to make use of it (I’m quite guilty of this myself).
That is, if you’ll forgive me, a semantic argument rather than a real or meaningful argument; deactivating and uninstalling are functionally the same thing as far as both the site administrator and users are concerned. Deactivate a plugin and the users will be deprived of its benefits – whatever they are; wordpress performs exactly as if the plugin is uninstalled.
Yes we all of us have to deactivate [some] plugins during the course of upgrades etc, or for other temporary reasons; but the fact remains that too many plugins habitually leave dross in the options table and elsewhere after an uninstall. This is simply bad coding. Just as hardly any plugins allow one to view or export ALL of their current settings.
Giving the admin the *option* to export/delete settings before deactivating is the key to what I said: which you elected to ignore.
The new uninstall API is good, as far as it goes.
I’ll concede that having an option to export/import a plugin’s settings would be a useful feature, yet I must insist that deactivating and uninstalling a plugin are two distinct actions. And, judging from how the uninstall API works, the people working on the WordPress core would agree with that.
Of course uninstalling and deactivating are two distinct “actions” on the part of the admin – I’ve not said otherwise.
However *functionally* as far as the use and deployment of WP is concerned they’re identical: there is absolutely no difference between a WP site with a deactivated plugin and the same WP site where the plugin has been entirely uninstalled through the WP UI, or indeed a WP site where one simply deletes the relevant plugin directory in the file system.
All of these methods produce identical functional results.
Take a common addon: TinyMCE Advanced; deactivate it and the *effect* for all users is exactly the same as uninstalling it, and vice versa.
The WP Uninstall API is irrelevant in this context: it’s merely a cleaner more logical means for achieving those functional changes.
It seems to me that you’re far more of my comments than they warrant.
@ Robert Neuschul:
As it is best practice, to deactivate plugins before doing an update on WP, there’s a big logical difference between uninstalling and deactivating. And I wouldn’t want to import all my settings after a (maybe even minor) update on all the sites i’m working for.
Therefore the uninstall API is highly relevant and i wish more plugin authors would use it.
If you updated your blog to 2.8 with plugins left active, you probably ran into severe problems.
@ m.e
Logical and functional aren’t the same thing: I wasn’t discussing the logical or even the best practice: I was describing the functional EFFECTS of two different actions.
If you disagree with my statement that uninstall and deactivation are functionally equivalent then show me a single instance where uninstall and deactivation have different functional effects on the ongoing operation of a WP site as far as either users or sysadmin are concerned.
As for the u/g to 2.8: for some values of “severe problems” you’re correct. If plugins are already 2.8 compatible then deactivation is not required. Best practice tells one to deactivate; and it is indeed a good idea in almost all instances, but if a specific plugin is already and genuinely 2.8 compatible then it isn’t essential.
However the issues surrounding the uninstall API still are not relevant to a description or discussion of functional effects until one comes to a discussion of reinstallation or reactivation of a plugin.
Again: you’re making the same mistake as White Shadow: making more of my comments than they warrant.
This does not appear to work, at least with wp v 2.8 and my collection of plugins. I’ve tried from FF and Safari (Mac) and the menu does not seem to permit cut/copy/paste, or drag/drop. Is there a place I can report the issue more fully? Can I assist by providing more information?
Thanks.
I suspect it’s a plugin conflict of some kind. I’ve tested the menu editor in a relatively “clean” install of WP 2.8 (using FF and Opera) and drag & drop and the menu items still work as expected.
The quickest way to test if it really is a plugin conflict is to temporarily deactivate all other plugins (this should be pretty easy to do via the “Bulk Actions” dropdown.) and try using the menu editor again. If you find out the editor works with other plugins deactivated, re-activate your other plugins one-by-one to find the conflicting one.
You could also check the Error Console in Firefox for some clues (Tools -> Error Console).
[...] Admin Menu Editor – used to hide menus from my client’s user account and “keep things simple” [...]
Hi,
I accidently set my “Settings” menu to invisible with Menu Editor – now I can’t access it via the direct URL lnik, it says I don’t have enough user rights. How can I access Menu Editor now to make “Settings” visible again?? Wehre in the DB can this be done?
Thanks!!
Go to the wp_options table and delete the row that has the “option_name” column set to “ws_menu_editor”. This will reset the menu configuration and let you access the “Settings” page again. Note that any other changes you made to the dashboard menus will also be lost.
LOVE U! <3
[...] In: Wordpress plugins 13 Aug 2009 Go to Source [...]
Hello,
I am trying to add a new seperator so I copy and paste an existing one but when I save it disappears. Any ideas how to stop this?
Thanks
Dave.
Strange, I’m not seeing that behaviour in my test setup. Have you tried moving the copied separator to a different place before saving? Maybe you could instead copy a normal menu and then change it’s properties so that it becomes a separator (as a workaround).
Hi,
I don’t understand my problem. I configure my dashboard menu with your plugin. And all is ok. But when, for example, I change the theme of my website, the submenu of the previous theme is always present and it isn’t hidden (And when, i click on this link,of course, I have an error like “The requested URL /htmlv3/wordpress/wp-admin/fusion-settings was not found on this server.”
Can you help me please?
This is a known issue. The plugin errs on the side of caution and doesn’t automatically remove menu items that point to a non-existent page.
I’ll put this on my to-do list, but I can’t promise it will get fixed soon – there are other things that take priority right now.
Just FYI – I love this plugin, but now it has a conflict with Disqus that renders this plugin completely unconfigurable while Disqus is activated. When I deactivate Disqus, I can change the settings on Menu Editor, and thank goodness they seem to stick even when I re-activate Disqus. My guess is that it happened with the latest Disqus update and is a javascript conflict.
Hmm, I installed Disqus in my test blog and the menu editor still worked fine… So I’ve got no idea what the conflict might be.
Assuming it really is a JS conflict, check your browser’s error console for the specific error message.
Benjamin Allison, I am also running a WPMU website.
The Site Admin menu seems to be getting added to every blogs admin area.
Although users cannot access the pages on it.
Are you finding this too? Were you able to overcome it?
I am looking for a similar plugin, I rememebr having seen it somewhere, where one could specify what menus are available for what users/roles/etc…
i.e. excluding the TAGS menu for everyone, etc…
Hi,
I have noticed that the Admin Menu Editor plugin does not work when the WPML plugin (http://wpml.org) is activated also. (WP 2.8.4)
Once WPML activated, if I go to the Menu Editor option in the admin, I cannot drag the items around or click any option. It seems to be a JS issue. It gives the error “menu.defaults is undefined” in menu-editor.js line 110.
Other users seem to have the “menu.defaults is undefined” error issue. Is there any solution to this ?
I don’t have a solution as of yet. The problem is I can’t replicate the bug – when I activate WPML the menu editor continues to work without a hitch.
[...] önskade innehållstyper är skapade installerar du pluginet Admin Menu Editor som ger dig fria händer att möblera om (och dölja saker) i [...]
Someone emailed me about how they solved the “menu.defaults is undefined” problem; I’m posting their comment here (with permission) as it might help other users :
[...] Admin Menu Editor Permet de personnaliser les éléments du menu et de ses sous-menus d’administration. [...]
White Shadow, this might have been asked already before, but is there a reason why this AMAZING plugin of yours is not listed in the official WP plugin repository?
It’d be nice to get noticed about updates and stuff. Plus, I am sure you’re cutting off quiet a big piece of potential new users by not having it listed in there, and that will never find out such a useful plugin. To me Menu Editor is a must-have for each and every WP installation.
It’s mainly due to my laziness. Nevertheless, listing in in the wp.org repository is on my Cthulhu-forsaken to-do list.