Admin Menu Editor For WordPress
Admin Menu Editor is 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.
Features
- Sort menu items any way you want by simple drag & drop.
- Move a menu item to a different submenu via cut & paste.
- Edit any existing menu – change the title, access rights, menu icon and so on. Note that in the free version you can’t relax menu permissions – i.e. give access rights to a role that originally didn’t have them – 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 :
This plugin also has a Pro version that offers a bunch of extra features.
Download
The latest version of the plugin is always available on WordPress.org.
Requirements :
- WordPress 4.1 or later
- PHP 5.2 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. This has been fixed in the Pro version.
- Plugin menus that are moved to a different submenu will not work unless you put the full page URL in the “URL” field. This is because WP “ties” the menu item to it’s parent menu and won’t recognize it in a different submenu.
Subscribe via RSS
Get Updates by Email
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).