/wp-admin-menu-classes.php Secret
bedex78 - Good catch. Yes, I made that change to the function name before posting the gist but obviously forgot to test it and find the error. I've updated the gist to use pause_admin_menu_section_refresh() instead. (Sorry for the bother.)
Added a new version. Fixed some bugs, added delete_admin_menu_item().
Added another new version with MAJOR breaking changes. Greatly simplified the API interface with a goal of making it more likely to be incorporated into WordPress v3.1.
BTW, I dubbed this new version 1.03.
This is the version 1.04, and usage examples I was referring to in my email Mike ... read all the trac stuff too. Really hoping this gets in to 3.2. I think it's a waste of time to worry about making it PHP4 compatible at this point, just skip it and build it clean for 3.2.
Eager to know how things went at the dev meeting as I wouldn't want to see #1466(?) as anything more than a stop gap. It's great, but, too limited. Now that I'm able to use this, I'm spoiled. This is right on target.
My only comment is that as you are making sub menu changes you need to make references to parent level items, which pending whether you have previously renamed or not, gets a little awkward. Works, but, seems it could be a little smoother. Seems menu items ( all ) would benefit from being assigned unique ids. Call me crazy, I'm all about numerical ids. They just feel safer and more reliable than slugs or titles, which change with the wind.
In my very novice mind, it seems that this entire menu system would benefit from the goal of eventually having the same capabilities as the new menu system for the front end ... ie perhaps a submenu under tools called "admin menu" that functions very much in the same way as the "menu" under appearances? It should need to be activated in the functions, same as post_thumbs etc.
Some Test Results:
This works:
delete_admin_menu_section('edit-comments.php'); // Comments
This does not:
delete_admin_menu_section('Comments'); // Comments
This however does work:
delete_admin_menu_section('Links'); // Links
I also noticed that in #1466(?) ... sorry, can't remember if that's the right ticket ... the code is referencing the page titles associated with those top level menu "sections". Can this be added here so that if I change "posts" to "news" this change is reflected in the page title of edit.php to avoid confusion.
Works:
$community = rename_admin_menu_section('Posts','Community');
delete_admin_menu_item($community,'edit-tags.php?taxonomy=post_tag'); // Tags
Doesn't Work:
$appearance = "themes.php";
delete_admin_menu_item($appearance,'theme-editor.php'); // Editor
Partially Works:
$appearance = rename_admin_menu_section('Appearance','Site Administration'); ---> works
delete_admin_menu_item($appearance,'theme-editor.php'); ---->doesn't work
Am I missing something Mike?
Really hoping this gets in to 3.2.
I think it's a waste of time to worry about making it PHP4 compatible at this point, just skip it and build it clean for 3.2.
That's now the plan: ignore PHP4 compatibility. It would not be possible without a significant rewrite because of my heavy use of passing objects by reference.
Eager to know how things went at the dev meeting as I wouldn't want to see #1466(?) as anything more than a stop gap.
It's great, but, too limited. Now that I'm able to use this, I'm spoiled. This is right on target.
The dev meeting was postponed for unrelated reasons. Please comment on ticket 12718 (and ticket 14666) adding your support to using these functions if you want to see them included. One option is to include it in v3.1 and do a check to fail if not PHP5. Since there would be no backward compatibility concerns this approach has in general been approved by the core team for other enhancements.
My only comment is that as you are making sub menu changes you need to make references to parent level items, which pending whether you have previously renamed or not, gets a little awkward.
Works, but, seems it could be a little smoother.
Seems menu items ( all ) would benefit from being assigned unique ids.
Call me crazy, I'm all about numerical ids.
They just feel safer and more reliable than slugs or titles, which change with the wind.
The problem with numerical IDs for menu sections and items is the source of the menus is code and not the database there is no where to be the authority for assigning numeric IDs. Numerics work for posts since they are stored in the database as a single arbiter but there's no reasonable way to assign idempotent numeric IDs to the admin menus. So we are stuck with slugs and titles.
That said, you can use object references and they don't care if you rename, i.e.:
$dashboard = get_admin_menu_section('index.php');
$dashboard = rename_admin_menu_section($dashboard,'My Main Admin Menu');
delete_admin_menu_item($dashboard,'index.php'); // Dashboard
delete_admin_menu_item($dashboard,'update-core.php'); // Updates
In my very novice mind, it seems that this entire menu system would benefit from the goal of eventually having the same capabilities as the new menu system for the front end ... ie perhaps a submenu under tools called "admin menu" that functions very much in the same way as the "menu" under appearances?
It should need to be activated in the functions, same as post_thumbs etc.
I hate it when others tell me this so, sorry in advance...., but I think that's plugin territory. WordPress is designed to have a standard admin with replaceable themes. Most people who really need to change the admin menus are site implementors; if end users want to change them they can find a plugin that will give them the option (with these functions, that plugin becomes pretty easy to write.)
This does not (work): delete_admin_menu_section('Comments');
It doesn't work because you are trying to match "Comments"
when instead you need to try to match the following (note the values hidden in the HTML) :
Comments <span id="awaiting-mod" class="count-0"><span class="pending-count">0</span></span>
I could have match a substring of the full menu but then you could potentially rename/delete menu you don't want to change. So the solution it to pass it a regular expression like so:
delete_admin_menu_section('Comments .*');
But let me think about it. I might be able to come up with a better answer later. For now, use it as designed.
I also noticed that in #1466(?) ... sorry, can't remember if that's the right ticket ...
the code is referencing the page titles associated with those top level menu "sections".
Can this be added here so that if I change "posts" to "news" this change is reflected in the page title of edit.php to avoid confusion.
Ah, good point. I missed that requirement. I'll see what I can work in but unfortunately I can't do it for a while. Clients are demanding me to produce, sooner than later!
BTW, the ticket to which you refer is #14666.
Doesn't work:
$appearance = "themes.php";
delete_admin_menu_item($appearance,'theme-editor.php'); // Editor
Partially Works: ... delete_admin_menu_item($appearance,'theme-editor.php'); ---->doesn't work
Am I missing something Mike?
heh. I chased my tail around a while on that one too. You will find the answer to why it doesn't work on line 170
of /wp-admin/menu.php
(in v3.0.1.) We must thank whoever wrote that code because they decided to set the 'admin_menu'
hook priority to 101
which means you need to set your 'admin_menu'
hook priority to 102
or greater. Sheesh! I think it's actually really sloppy of the person who wrote that because it causes many people to waste their time trying to track down why code doesn't work when it looks like it "obviously" should. This is yet another thing we should try to get fixed in core, IMO.
Hope this helps.
-Mike
The dev meeting was postponed for unrelated reasons. Please comment on ticket 12718 (and ticket 14666) adding your support to using these functions if you want to see them included. One option is to include it in v3.1 and do a check to fail if not PHP5. Since there would be no backward compatibility concerns this approach has in general been approved by the core team for other enhancements.
I love the optional fail. Will do.
The problem with numerical IDs for menu sections and items is the source of the menus is code and not the database there is no where to be the authority for assigning numeric IDs. Numerics work for posts since they are stored in the database as a single arbiter but there's no reasonable way to assign idempotent numeric IDs to the admin menus. So we are stuck with slugs and titles.
I was envisioning backend content types like nav_menus are now ... admin_nav_menus ... this comment should actually be down there with my mention on similar topic ... object references it is then ;-)
That said, you can use object references and they don't care if you rename, i.e.:
In my very novice mind, it seems that this entire menu system would benefit from the goal of eventually having the same capabilities as the new menu system for the front end ... ie perhaps a submenu under tools called "admin menu" that functions very much in the same way as the "menu" under appearances? It should need to be activated in the functions, same as post_thumbs etc.
I hate it when others tell me this so, sorry in advance...., but I think that's plugin territory. WordPress is designed to have a standard admin with replaceable themes. Most people who really need to change the admin menus are site implementors; if end users want to change them they can find a plugin that will give them the option (with these functions, that plugin becomes pretty easy to write.)
No worries on telling me that ... I'm not easily "miffed" heh. I was thinking in terms of development ease, for instance, if admin menus incorporated the approach that we have in the backend now with nav_menus and did have a place in the database, those numerical id's would be available, then, not only would the work your doing be way easier and "cleaner" per se, a dev only type plugin that would make our lives so much easier for creating custom backends for our clients would be a breeze as well ... that's where my thinking was on that anyway.
I also noticed that in #1466(?) ... sorry, can't remember if that's the right ticket ... the code is referencing the page titles associated with those top level menu "sections". Can this be added here so that if I change "posts" to "news" this change is reflected in the page title of edit.php to avoid confusion.
Ah, good point. I missed that requirement. I'll see what I can work in but unfortunately I can't do it for a while. Clients are demanding me to produce, sooner than later!
Groovy.
BTW, the ticket to which you refer is #14666.
Thanks! I was being too lazy to open the tab again to look.
Doesn't work: $appearance = "themes.php"; delete_admin_menu_item($appearance,'theme-editor.php'); // Editor Partially Works: ... delete_admin_menu_item($appearance,'theme-editor.php'); ---->doesn't work
Am I missing something Mike?
heh. I chased my tail around a while on that one too. You will find the answer to why it doesn't work on line 170 of /wp-admin/menu.php (in v3.0.1.) We must thank whoever wrote that code because they decided to set the 'admin_menu' hook priority to 101 which means you need to set your 'admin_menu' hook priority to 102 or greater. Sheesh! I think it's actually really sloppy of the person who wrote that because it causes many people to waste their time trying to track down why code doesn't work when it looks like it "obviously" should. This is yet another thing we should try to get fixed in core, IMO.
haHA! Well now, I know. Menu item is officially gone thank you.
I'll be heading over to put 2¢ in on the aforementioned topics now ...
oh yeah, there won't be any way to just move one item to another spot will there ... due to the same issue of not having ids huh? I can't imagine any way that could be done ... unless "groups" could be created somehow ... hmmm.
sorry for the nightmare read ... didn't know how to quote properly ...
Hey @10SexyApples:
sorry for the nightmare read ... didn't know how to quote properly ...
To quote lines, start them with a greater than (">"). Here's the: links to how to format (which you can find linked to the top right of the edit box as _Comments are parsed with GitHub Flavored Markdown)_:
- http://github.github.com/github-flavored-markdown/
- http://daringfireball.net/projects/markdown/syntax
Hope this helps.
-Mike
I love the optional fail. Will do.
Big thanks!
I was envisioning backend content types like nav_menus are now ... admin_nav_menus ... this comment should actually be down there with my mention on similar topic ... object references it is then ;-)
In my very novice mind, it seems that this entire menu system would benefit from the goal of eventually having the same capabilities as the new menu system for the front end ... ie perhaps a submenu under tools called "admin menu" that functions very much in the same way as the "menu" under appearances? It should need to be activated in the functions, same as post_thumbs etc.
Ah, fair point! But, be careful what you wish for. I've been doing a lot of advanced work with the nav_menus and I really, really long for the simplicity of menus that would just be registered. But I digress…
I was thinking in terms of development ease, for instance, if admin menus incorporated the approach that we have in the backend now with nav_menus and did have a place in the database, those numerical id's would be available, then, not only would the work your doing be way easier and "cleaner" per se, a dev only type plugin that would make our lives so much easier for creating custom backends for our clients would be a breeze as well ... that's where my thinking was on that anyway.
Anyway, there could be some value in that but I've learned that large changes don't make their way into WP core, at least not quickly so I'm just really happy with this only slightly evolutionary improvement.
haHA! Well now, I know. Menu item is officially gone thank you.
You've heard that pioneers are the ones with arrows in their backs, right…? ;-)
oh yeah, there won't be any way to just move one item to another spot will there ... due to the same issue of not having ids huh? I can't imagine any way that could be done ... unless "groups" could be created somehow ... hmmm.
Give me a use-case example specific with item names?
I have swap_admin_menu_sections()
; would swap_admin_menu_items()
be what you'd need?
Hope this helps.
-Mike
To quote lines, start them with a greater than (">"). Here's the: links to how to format (which you can find linked to the top right of the edit box as Comments are parsed with GitHub Flavored Markdown):
Thanks!
I responded via email on this, sorry, but, I had another question anyway, so, here goes. I'm wondering if you foresee there being any issues with hooking into core menus that have been potentially renamed and relocated.
For instance, if a plugin wanted to add an option page, and I had moved and renamed the section they wanted to hook into, could any discrepancies arise, perhaps in how the developer coded it to hook in, that would cause a fail?
Just curious~
if a plugin wanted to add an option page, and I had moved and renamed the section they wanted to hook into, could any discrepancies arise, perhaps in how the developer coded it to hook in, that would cause a fail?
It all depends on what the plugin does. If it renames titles and you are using titles then yes, it could cause problems. But no more than going direct to the $menu
or $submenu
variables. My functions do nothing to modify the underlying structure nor do they cache their values so they are as safe as you can get but still no silver bullet. Caveat Emptor!
Hope this helps.
-Mike
BTW, on WordPress dev chat they don't want to discuss including these for v3.1 (mostly because they've already blessed the list of tasks and this was not on it.)
oh yeah, there won't be any way to just move one item to another spot will there ... due to the same issue of not having ids huh? I can't imagine any way that could be >>done ... unless "groups" could be created somehow ... hmmm.
Give me a use-case example specific with item names?
I have swap_admin_menu_sections(); would swap_admin_menu_items() be what you'd need?
Hope this helps.
Here's a use case where simply 'moving' is more preferable than 'swapping'....
Let's say I want to move the 'Comments' section below 'Posts' and above 'Media', but I want to maintain the order of the rest of the menu, ie. 'Media', then 'Links', then 'Pages'.
In order to do that, I have to:
- Swap 'Comments' with 'Media'
- ..then swap 'Media' with 'Links'
- ..then swap 'Links' with 'Pages'
And if I were to put 'Comments' above 'Posts' then I would have to add one more line of 'swap' command.
Is it possible to make this more straightforward? Of course, it would be good if we could have this for menu items as well.
Just a thought.
Cheers!
@bedex78 - Of course it would be possible, but it would also be a lot more complicated because of how WordPress currently stores menus as +5 indexes into a set of arrays. The code to make it work correctly is a lot more work than what I've done so far. Also, I'm not sure what the best API interface would be. Maybe I should ask, if you had this functionality what would the function calls look like? What parameters would you pass?
Good job!
@marcosmlopes - Thanks!
I just found your gist here through your post on the wordpress SE forum. Great stuff! The only thing it's missing is what @bedex78 mentioned - I really want to be able to move things around. It would also be nice if it could handle separators too. You asked before what the function calls would look like for moving a section around. This is what I would have in mind:
<?php
move_admin_menu_section( array(
'slug' => 'upload.php' // slug of section to move
'insert' => 'before', // or 'after'
'neighbor' => 'edit.php' // slug of section to insert next to
'priority' => 10, // similar to wp actions to handle multiple moves
));
Thanks again for your work on this.
@aaemnnosttv Thanks for your kind comments. Right now, I've got my hands full with too many other projects to have time to focus on this, unfortunately. If you want to take a stab a getting this to work I'll be happy to post it as an update.
Hi Mike,
That's a great piece of code ! I don't know if you could take a few minutes to tell me what do I'm doing wrong !
I have an option page that I want to move inside at section created with your code, I've moved multiple custom post type without any problem, but the option page wouldn't moved at all.
I've tried to change the add_action priority it dose not work, i've tried to recreate this subpage with your script but can't figure how to get ride of "you don't have access to this page" and finally I found that I can remove it with the Menu name instead of the slug, but still don't move it around..
$new_section = array(
'title' => 'Google Transit',
'slug' => 'google-transit-export',
'page_title' => 'Exportation des cartes',
'icon_src' => false,
'function' => false,
'capability' => 'edit_posts',
);
$new_section_args = array(
'where' => 'bottom' // top or bottom
);
$google_transmit_menu = add_admin_menu_section($new_section, $new_section_args);
$gt_fares = 'Tarifs'; // Menu Name
$gt_fares = 'admin.php?page=google-transmit-management-system-fares'; // Slug
copy_admin_menu_item($google_transmit_menu,$gt_fares);
remove_admin_menu_item($gt_fares);
remove_admin_menu_section($gt_fares);
Thank you !
I'm having a similar problem to @jonathanlaf. I can't get copy_admin_menu_item() to work with pages added via add_menu_page().
I think there's a slight mistake in line 34...
Instead of 'pause_admin_menu_section();'... shouldn't it be 'pause_admin_menu_section_refresh();' instead??