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
admin-menu-editor.zip (33 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
- 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.
- If you create a custom menu (or change the “File” setting of an existing menu), be sure to tick the “Custom” checkbox. Otherwise that item will not show up in the final Dashboard menu.
Merry Christmas, by the way 
Yes, but I’m very lazy in this respect
Anyway to make this work with PHP4?
One could try, but it would take a lot of rewriting.
You’d need to set all hooks manually – the “magic” self-installing hooks of my makeshift plugin framework depend on the Reflection API, which is PHP5-specific. Class constructions would need to be renamed. Some variable initializers might not work in PHP 4 (arrays?). There’s probably a foreach() loop or two that use the iterator by reference (also not supported in PHP4). And so on.
Thanks for this great plugin! I looked for ages to find something to simplify the administration menus for my clients. Good work!
Well, it does just what I need – great plug! Thanks a lot
First, thanks for what is a really useful plugin.
Second, the problem [you just knew there had to /be/ a problem
]: not sure if this comes about from trying to do too much with ME, or as a result of an interaction with other plugins. It _only_ happens on one site where there are some 20 or so plugins installed [it's a very complex "private" members-only site]
Problem Description: open menu editor from Settings menu, go to “settings” sub-menu, sort all plugins [not default WP items] into alphabetical order below the default WP elements. Save. Refresh page. Go to Settings menu: Menu Editor itself has vanished from the Settings menu and one or more other plugins may also have vanished, whilst one or more plugins may be duplicated in the Settings at odd non-alphabetical places in that settings menu. Duplicate items _are_ functional.
Go back to Menu Editor via the installed plugins page or via direct URL and ME shows everything correctly as last saved: not as shown on the settings menu.
Clearing the WP Cache makes no difference. Clearing the browser cache makes no difference. Indeed the problem is visible from different machines on different OSs and using several different browsers etc etc.
Reset menus to default order, save and refresh and everything instantly works as expected.
Have tried deactivating Menu Editor, cleaning out the options table and then reactivating, but the problem reappears fairly quickly once one starts sorting entries.
I’ve not yet had the courage to deactivate all other plugins and/or reset the WP options table to defaults in order to do a ‘clean’ test because this is such a complex site.
NB: this problem does _not_ arise on other less complex sites running on the same configuration of Apache/Linux with PHP5.n and MySQL5.n and WP 2.7.1 [they're all virtual hosts on the same physical box], although many of them do share several of the same plugins.
Having to run with default order in the Settings menu isn’t a major issue, but missing and/or duplicate items could become a problem. Most of all it’s an irritant which is puzzling me.
Any thoughts or suggestions?
Yep, this might really be a compatibility issue. So muster up the courage and test that idea
– First, save the sorted configuration. Then deactivate/reactivate your other plugins one by one. Reload the page aftear each deactivated plugin and see if the menu is OK. That should help you find the conflicting one.
Personally, I’m pretty sure it is a plugin conflict. Sorting works fine even in WP 2.8 beta, though there are some glitches with separators.
Hi, with the purpose to check plugin compatibility behaviour with 2.0, I duplicated my WordPress site and upgraded. Strangely all my settings in the Menu Editor were resetted to default.
Tha means I should go and re-arrange everything again after upgraded to 2.8. Is this normal? Anybody else met the same issue? If yes, are there any fixes to this?
By the way, this is the bes plugin ever! Letting you customize your admin is someting that should be considered as a default option in any CMS. Luckly, White Shadow did a great work with this. Thanks.
For what it’s worth, upgrading to WP 2.8 worked fine for me – the settings were retained and the plugin still worked as expected. Perhaps in your case the settings were actually lost in the duplication process?
I got a question.
I finished the development for a site (on local) and now I need to put it on the live server. Even without upgrading to 2.8, whenever I copy all my files to the server and I import the databse, the Menu Editor plugin doesn’t keep its settings I set up on local.
Well, actually, I even made a test from local to local (copy files + export/import databse) and I got the same result.
I got the default admin menus and I need to re-arrange them all with Menu Editor again. Is there a reason why that happens. Is it a normal behaviour or a bug?
You say, “perhaps in your case the settings were actually lost in the duplication process?”. How is that possible? Where and what should I look to see where the problem might be?
Thanks for letting me know.
All settings pertaining to this plugin are stored in the “ws_menu_editor” option. Options are, in turn, saved in the wp_options table in the WordPress DB. You can view the database with something like phpMyAdmin (or whatever other tool your host has).
You could check the “ws_menu_editor” option before and after copying, and try to figure out when/why it changes or gets deleted.
One can view the stored options without the use of phpMyAdmin or the MySQL Administrator Toolkit.
http://my_site_url/wp-admin/options.php
It’s not guaranteed to be true but it’s my observation that where other plugins are using the now deprecated get_settings call in their coding, instead of the get_options call, such plugins will interfere with the correct deployment of menu editor.
I’ve seen exactly the behaviour you describe. The only way I’ve found to force menu editor to behave correctly thereafter is to export all WP content, de-activate all plugins, drop and then recreate the DB tables and then reimport the WP content and re-activate ONLY the menu editor plugin and set it as one wishes it to behave. Once that’s been done one can reactivate the other plugins one at a time until one finds which plugin or combination of plugins causes the menu editor to stop functioning. At that point it’s a case of hacking through the code of the problem plugin and replacing any get_settings calls.
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?