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
Hello again, WS. First of all, thank you for getting back to me so quickly about this, specially on a Sunday.
After your explanation, I was able to understand the moving mechanism way better, and I was able to get the Add This plugin working well after moving it inside my custom menu, so thank you very much for all your help!
Hey WS!
First of all as it’s been said before, what a tremendous plugin this is. Truly superb work.
I’m running it as a site admin on a wpmu 2.9.2 install. I’ve been able to move directories and subdirectories all over the place even renaming them to best suit my users needs.
I have noticed that if I make any changes to the “General Settings” tab (options-general.php) that when I click save I am taken to the dashboard and the Menu Editor no longer works. Clearing the SQL table resets everything and I try again.
What I’m trying to do is make the General Settings tab appear as a submenu of the Dashboard at the top. I’ve tried copying it and placing it up there. I’ve also tried cutting and pasting it. I’ve clicked the “custom” button and even added the link to the “File” field. I’ve successfully moved everything else around to their new homes, but when I try to do anything with this one the plugin breaks.
Any thoughts? Again, such fantastic work at such a relatively early stage of dev is amazing! Koodos to you!
Short answer: This can’t be fixed except by throwing out the current WP menu subsystem and writing a new one. And I’m definitely not up for that, at least not without a significant monetary incentive.
I would recommend inserting the full URL of the original “General Options” tab in the “File” field of the moved menu. For example : http://example.com/wp-admin/options-general.php
I’ve tried it locally, and it worked.
Long answer: The dashboard menu system is, at its core, a horrible jumble of legacy code and undocumented hacks. It’s an eldritch horror, capricious and shrouded in mystery. It was never meant to be user-modifiable, and it shows. The arcane magicks that fuel Admin Menu Editor may be powerful, but even they can never fully control the beast. As you’ve discovered, one misstep, one unwritten rule accidentally broken, can render menus inaccessible.
Ahem. In summary : The menu system sucks, and programming for it is hard.
WS,
You sir, are the man. I give you +11 points for the reference to the dashboard menu system as “an eldritch horror, capricious and shrouded in mystery.” LOL that made my day!
Anyway, I see your point and if I had the funds to provide the significant monetary incentive, I’d probably fork it over. Alas, that time is not now. Should things change I’ll give you a call!
Great work man. Seriously.
Hi White Shadow!
This is an absolutely MUST HAVE plugin! Great, and THANKS for it!
A tiny problem I observed:
When I deploy my local site (single not mu install) to another host (and after when typically replacing the new host name in the database.. etc) on the new host the whole menu structure will be as default, although the database contains the right settings (in the quite magical json data) in the wp_option table option_name=ws_menu_editor.
I glanced at the concerning codes more times what may cause to vanish the previously set menu structure. But surely I’m not quite magical to understand what happens.
Could you help me – please how can I resolve this? (That’s a bit embarrassing to rearrange the menus as many times I may deploy my site to an other host, although the settings are kept in the database 🙁
much thanks for your answer
iplnts
So far I’ve been unable to reproduce the bug. I’ve tried moving a test blog to a new directory and a new subdomain (by following the instructions), but the modified menu was successfully retained in both cases.
Unfortunately, I don’t currently have a spare domain to test moving sites between domains. If you do, maybe you could give me access to such a moved blog that has this problem so that I can run some tests on the plugin?
Hi White Shadow!
Thanks for your answer, and help.
Unfortunately I can not give you an access to such a domain. I can only send you the database file to see the menu order is really well in that.
I wasn’t quite exact. (I’m using wp 2.9.2, and your last 0.2. version of your plugin downloaded from the wp plugin repository and my site allows multi author environment)
Actually, I didn’t move nowhere my site, only I wished to give access the site to an other computer on my local network for testing by an other people than me.
I mean, the test site basically remained on my localhost\wordpress directory on a computer named xy.
I only replaced in the previously exported wordpress.sql the localhost to xy as an exact domain name, then allowed accessing xy’s webserver on the other computer’s Win firewall, reimported that worpress.sql on xy, and changed that host name in the wp_config.php too. Restarted using the site from http://xy/wordpress instead of http://localhost/wordpress.
Generally, everything okay, I can see and handle the whole site from my xy an also from the other computer on the network except the previously set menu order lost on both computers.
Perhaps, I missed yet something in the settings (?)
As far as I glanced your code, and the core menu php too, I was unable to understand concretely that, how do you access the stored data in wp_option table option_name=ws_menu_editor? I couldn’t find any database operation. Only that line regarding to that for example in the menu-editor-core.php
//Set some plugin-specific options
$this->option_name = ‘ws_menu_editor’;
Have you any suggestion, what would be the error in this special case? How can resolve that?
(I’m a programmer but, not yet a wp expert or magician. :-D)
* I’m planning later after deliberately tested to deploy the site to a payed Internet host too. And I only should like avoiding to rearrange manually the menu again.
much thanks again for you answer
iplnts
Here’s some background about how the plugin works, maybe it’ll help you find the problem :
The options are loaded in the “load_options” method found in the “shadow_plugin_framework.php” file (around line 95). Once loaded, they’re stored in the “options” object var., i.e. $this->options. This variable is an associative array.
The custom menu is stored in the “custom_menu” key of that array. The custom menu is a pretty complex multi-level array. You can put a
call somewhere in the “hook_admin_menu” function in menu-editor-core.php to dump the raw custom menu structure to the screen.
The custom menu is used to modify the default WP menu on lines 131-138 of the menu-editor-core.php file.
My guess would be that for some inexplicable reason the plugin doesn’t “see” the old “ws_menu_editor” option once the domain name has changed. However, I have no idea how that could possibly happen.
Hi White Shadow,
Much thanks for your help, again.
That’s okay I found both functions to which you referred. I understand the logic. What I missed to realize that, how the options from the wp_otion table are (auto) loaded what is surely a wp core thing what I need to better learn yet.
Meanwhile, I had to rearrange the menu again, at now it resolved my problem. However, I exported this particular row from the database for the hope I could recover it somehow if the problem might happen again when I deployed the site to a final host.
BTW: There were defined yet in the wp-config – EMPTY_TRASH_DAYS, and WP_POST_REVISIONS by me which settings also had been by-passed after I’d run the site from the changed hostname, and I noticed later some else plugin settings also were lost too, unfortunately. (???)
In summary: This issue is surely not the problem of your plugin, but as a possible event, I wish you only to know about.
Much thanks again for your help, and further good works to you
iplnts
Hi White Shadow,
Let me react back to your previous message:
“.. My guess would be that for some inexplicable reason the plugin doesn’t “see” the old “ws_menu_editor” option once the domain name has changed. However, I have no idea how that could possibly happen…”
Perhaps, that I found explaining this may be useful for you too, if you haven’t figured out until.
——
I looked into a bit better, how the options might been loaded and found the trick to dump all options into the wp options screen:
(..domain/wordpress/wp-admin/options.php)
There I found quite many options variables are SERIALIZED..and disabled the writing out and any editing them. Although, when I’m seeing the database with PhpMyAdmin all of those variables previously set are stored in the database well, but after the simple manual replacing of the host name all of them will be lost.
I found some useful references what would be the problem:
1. http://www.andrewnacin.com/2010/04/18/wordpress-serializing-data/
2. http://www.davesgonemental.com/php-serialization-fix-for-wordpress-migrations/
As far as I can understand now, something happens with the serialized stored data when changing the domain name, thus those serialized stored data are hard to recover.
I’m not figured out yet how to get back them, but I will try in the latter (2.) suggested fix to run.
(It is truly a nightmare if I have to look trough every such option variable and set them again manually after deploying 🙁 )
cheer,
iplnts
Hi White Shadow
Yet another better fixer and explanation from browsing toward the above (2.) link
http://www.davesgonemental.com/mysql-database-search-replace-with-serialized-php/
Hey…
Just it is for me and I think everyone else who may has the same problem, and maybe some good trick also for you in the php code, perhaps 🙂
Interesting. Perhaps if I change the plugin to use a storage format that’s more tolerant towards manual editing these issues will go away…
Try this modified version.
No slight on the plugin, because I think it’s the most innovative WP plugin I’ve seen in a very long time, but if you could fix this issue, all my problems would be solved. Regardless, it is minor when considering how much this plugin does for WP backend!
Hi White Shadow
Much thanks dealing with my issue. I’ll try your modified version.
It is no doubt (I agree with Johny) your plugin is a must!
(Unfortunately, not only your plugin affected by this serialization problem. I’ve tried the above mentioned two links of fixes and that worked well, regardless some \\” issues .
If someone will also use them I suggest reading through their comments too. 🙂
Thanks again for your plugin and the modification too.
further good work
cheer
iplnts
Hi White Shadow!
After I’ve made a backup of my previously fixed database I installed your new modified version.
Unfortunately, I also lost again my all menu settings. When I looked into the database ws_menu_options field, I realized the stored data changed but some \/ were written into strangely. Unfortunately, I can not send/write here you this field value completely, because I ‘ve reinstalled your original plugin and restored the database since then.
I mention here this also for your information only, that perhaps really strange happens …
iplnts
Yes, JSON can escape forward slashes (i.e. replace them with “\/”). There might be some arcane format that doesn’t introduce any “strange characters”, but I’m not aware of one.
I guess that just means that running a bruteforce search & replace on the WP database is sometimes inadvisable 😉
Hi White Shadow,
Apologizing for the long messages here, but I only wish to make this issue clear 🙂
I think, there is not any problem with your new code and really thanks for your effort making it to be more stable avoiding the manual editing when migrating a site..
—–
The only problem that the previously stored menu order data was yet in the older stored format in the db when I installed and run your new code. I was lazy to arrange the menu again starting to rewrite it from scratch with your new code and saving that, I think.
It is quite true, that the serialize fix and the second search & replace (offered by the above links) may have also very dubious outcomes. (I spent quite enough time yesterday to look through the db carefully after run that serialization-fix.php). Yes, there was some problems with that, too, I had to correct manually.
—–
Your resolution is obviously clear, surely resolving the problem for your plugin setting when migrating a WP db in the future, but (as per my trying) it involves at least once to rearrange/rewrite the menu order again to store the new data format and getting that back well.
****
For my special case, wherefore I decided to put back your previous code:
Generally, this problem did not influence only your stored data, but else options settings made by other plugins too. (However I only presented this problem at present only for you, but not for any else plugin developers whose plugin are also in question for me.)
I had already run the serialize fix before installing your offered new code, and that fix basically resolved the problem at least for me, although I’ve made after running it yet some handwork.
I can consider to use your new code and arrange the menu again manually at least once, save that, but I think too that will resolve the problem only for your plugin when future deploying the site, however I’ll need to use again the serialize fix for the other plugins, and I just don’t know how that will influence your newly stored data. That is the reason, if you understand my problem.
****
Basically I think, this issued problem is for the plugin developers common understanding, as somehow that was mentioned in the http://www.andrewnacin.com/2010/04/18/wordpress-serializing-data/, and I think, I’m not the proper person to further care with it.
Much thanks for you, taking efforts dealing with and resolving this issue, truly.
cheer,
iplnts
Great plugin! I use this as part of my wordpress framework. I have been having a slight issue, that when I migrate a wordpress database, for example going local to live, my settings for this plugin dissapear. It was not like that in previous versions. Any thoughts?
Read the previous half a dozen comments that discuss just that.
Summary : the problem is caused by blindly editing the serialized menu configuration in the wp_options table (e.g. by running a global search & replace to set the new domain name), which makes it invalid. There is as of yet no viable solution.
I followed your directions for installing this plugin in WPMU. When I activate the plugin sitewide i get a brief 500 Internal Server error message and the page redirects to the plugin page with the following error message:
“Plugin could not be activated because it triggered a fatal error.”
Can you help? I love this plugin and will be using it to simplify the menu for many of our users.