There are about a dozen major features lined up for WordPress 3.1. My main tasks for 3.1 centered around improvements to custom post types. Since we’re in late beta stage, I wanted to offer a summary of all the cool enhancements soon coming to a site near you.
I started with a post on our development blog what I wanted to see, and asked others to chime in and share their “pet bugs, peeves, and workarounds.” The end result cemented what needed to get done for the cycle. There were many small incremental improvements, but a few stood out, which I’ll be covering in a series of posts this week.
Hiding the admin menu
In 3.0, when you register a post type with show_ui, you’ll end up with a top-level admin menu page, with submenu pages for edit, add, and any taxonomies.
Sometimes though, this isn’t ideal. Perhaps you’re using the user interface as a read-only display of logged information, or your post type works great as a specific subset of another admin menu, like slideshows under Media.
Here, the Slideshows submenu page is a custom post type.
Enter a new flag for register_post_type(), called show_in_menu. It defaults to true, assuming show_ui is true. Setting it to false will make your admin menu disappear, just like that. The UI is still there, so you can still go to wp-admin/edit.php?post_type=events, and you can use a function like add_submenu_page() to then add the Edit or Add New pages wherever you’d like.
Making your post type live as a submenu page
As mentioned above, you’ll often want a submenu page in place of a full menu. The show_in_menu flag optionally takes a string that identifies the top-level menu it should fall under. Set show_in_menu to tools.php, and suddenly you have a menu under Tools. It’s important to note that in this case, the Add New entry and any taxonomies will not be listed in the submenu — you’ll have to handle those yourself on a case-by-case basis, if you want them.
function nacin_register_slideshows_post_type() {
register_post_type( 'slideshow', array(
'labels' => array(
'name' => 'Slideshows',
'singular_name' => 'Slideshow',
),
'public' => true,
'show_ui' => true,
'show_in_menu' => 'upload.php',
'supports' => array( 'title' ,'thumbnail', 'editor' ),
) );
}
add_action( 'init', 'nacin_register_slideshows_post_type' );
Naming your menu
This next enhancement works great for custom taxonomies, too. When registering a set of labels for your post type, you can now optionally specify menu_name. This is useful when a post type name isn’t conducive to the relatively small amount of space you have in the admin menu.
function nacin_register_travel_post_type() {
register_post_type( 'travel', array(
'labels' => array(
'name' => 'Travel Itineraries',
'singular_name' => 'Travel Itinerary',
'menu_name' => 'Travel',
),
'public' => true,
'show_ui' => true,
'supports' => array( 'title' ,'thumbnail', 'editor' ),
) );
}
add_action( 'init', 'nacin_register_travel_post_type' );
What’s not new
Don’t forget what 3.0 brought to the table for manipulating custom post type admin menus: You can specify the menu_position flag to change the default position of your menu, and you can specify an icon using the menu_icon flag.
function nacin_register_press_releases_post_type() {
register_post_type( 'press_release', array(
'labels' => array(
'name' => 'Press Releases',
'singular_name' => 'Press Release',
),
'menu_position' => 11, // after 'Posts'
'menu_icon' => plugins_url( '/images/menu-icon.png', __FILE__ ),
'public' => true,
'show_ui' => true,
'supports' => array( 'title' ,'thumbnail', 'editor' ),
) );
}
add_action( 'init', 'nacin_register_press_releases_post_type' );
Further reading
Want to read the code? Check out Trac ticket #14145 for show_in_menu. Special thanks to Jon Cave (duck_) for making my initial patch function properly. For menu_name, check out Trac ticket #14832.
What’s next?
Have a suggestion for what we should do next, as it relates to admin menus and custom post types? Please leave your thoughts in the comments.
Pingback: Better admin menu handling for post types in WordPress 3.1 | Andrew Nacin | Bookmarks
Pingback: Segnalibri al 22 dicembre 2010 | Ubuntu block notes
Thanks for that round-up Andrew, roll on the rest of the series!
Hey Andrew:
Hope you had a wonderful holiday.
Just a quick question.
How do you add “contributor” panel to a custom post type in the post editor?
We need to tie current registered users to content created under the “articles” post type.
I left a message on JT’s blog too. But I thought I’d ask here as well. Thanks.
Tony Z.
You’re probably looking for a way to tie more than one user to a post — in that case, check out a plugin like Co-Authors Plus, or just create a quick meta box which stores additional user IDs into post metadata.
Pingback: 10 Things You Need to Know About WordPress 3.1 — Technosailor.com
Nice post.
One comment: menu_position is too fragile for use in anything other than a custom theme and even then it’s not the best. You really don’t know what other plugin might have chosen to use the same numeric menu position. It would be much better to be able to say “Before Tools” or “After Pages.” Hopefully this will be addressed in the future?
-Mike
Well, you do know the $menu keys for Tools and Pages, so you can pretty easily position things near other positions. It’s not ideal, but it’s what we have, and it’s not that it’s not flexible. You can always move the existing pages around on your own, if you’re completely overhauling the menu.
Andrew, I know you’ve seen this like but posting here for others to see so they can see exactly why what you describe is not sufficient in hopes others might recognize an need for the hooks or provide an alternative:
http://wordpress.stackexchange.com/questions/7029/the-great-wordpress-admin-menu-challenge-of-jan-2011-a-k-a-how-to-resolve-some
Oops, I got carried away. Yes, your reply addressed the comment of mine that you replied to. Sorry for implying otherwise; it’s the rest of the issues that are really of concern.
Oops, I didn’t check the “[X] Notify me of followup comments via e-mail” so I’m adding this comment to allow me to do that. Please delete this comment if you will.
And I just realized you were actually soliciting for feedback so here’s another two issues that are causing me more than a few problems:
1.) It seems that the “Menu Pages” (what I think of as “Menu Sections”) must have a link to something even if there is no need for it. For example, I have two clients that both want a consolidated menu called “Modules” which lists all their custom post types but there is nothing in the admin they want or need that “Modules” should link to. I’d really need WordPress allow me to create a non-linked section (i.e. “Menu Page.”) It can be removed with a jQuery script, but that’s a hack.
2.) It also seems that the Menu Pages add a “Submenu Page” (what I think of a “Menu Options”) as the first item even when not needed. In the case of the Modules mentioned in #1 it wants to add a “Modules” Submenu Page(/Menu Option) even though there is no need for a Modules submenu page. It can be removed by using array_shift() on $submenu, but it shouldn’t require that much internal knowledge to configure the menu structure.
3.) The admin menu system forces the URL for the page to match the URL for Submenu Page(/Menu Option) that is being highlighted. A use-case might be if you want to have a tabbed editing experience for a custom post type but you want to do it with URLs loading the tabs instead of jQuery yet you still want the same highlight in the admin menu. (This has something to do with $parent_file I think but I have a very hard time keeping my head straight as a I trace through the admin menu code as it’s one of the move convoluted bits of code in WordPress core.)
4.) I plan a series of trac tickets starting with this one which proposes to “Make Admin Menu Generation Hookable”: http://core.trac.wordpress.org/ticket/16048 It includes a tiny, easy to include patch, one I hope the team will consider.
Anyway, would love to hear your feedback on these.
-Mike
Here is another tickets on the subject, with a patch:
– Add ‘menu_page’ and ‘submenu_page’ hooks
Remember what you’ve said, “Patches welcome.”?
Pingback: Top 10 New Features in WordPress 3.1 | ShanKrila
Pingback: ShanKrila: Top 10 New Features in WordPress 3.1 | Copiers of the World
Here’s another issue with regards to the admin menus URL inheriting the first submenu item’s URL: http://lists.automattic.com/pipermail/wp-hackers/2011-January/037129.html
Another issue with the admin menu system is that the security is highly coupled to the menu structure which means changing the menu structure per client requirements can easily breaks access to the pages the menus display and it is very difficult to get around this currently in every version up to the current state of 3.1.
Linked below is another ticket with a patch that adds hooks which would enable a plugin/theme developer to decouple the menu structure (which should be done by roles and capabilities, not by coupling the URLs in the admin to those found in the admin menu structure, right?) These hooks enable a developer to provide access menu/submenu pages that the current coupling denys:
http://core.trac.wordpress.org/ticket/16204
Patches welcome, right?
Sorry, I’m probably just being a dunce, but I’m trying to figure out how to add a custom post type or custom taxonomy as a submenu of a custom menu. I’m using add_menu_page to create my plugin’s options page, and then I’m trying to get a post type and a taxonomy as submenus to that.
Pingback: De Nieuwe Features van WordPress 3.1
Pingback: What’s new and exciting in WordPress 3.1 | WPCandy
Pingback: WordPress 3.1 | WP TutsWP Tuts
I’m in the same boat as Mike on grouping custom post types under a parent level admin menu.
I created a parent level menu item to group a set of custom post types. I then created a function for that parent level menu item that does nothing.
I created my custom post types and set them to “show_in_menu” => “my parent menu”.
All of that works fine but the parent menu automatically inherits the first custom post type url, which is kinda odd.
Perhaps there could be a way to group the custom post types better.
Something that keeps the default functionality and let’s you assign them to a container that lives in the admin menu and looks like a menu item but doesn’t have to function like the default menu items.
More like a toggle container.
Pingback: Custom Post Types - Explain the Unexplained - Better WordPress
So, if I create a plugin with a submenu as:
// this function adds the settings page to the Appearance tabadd_action('admin_menu', 'add_wp_accordion_menu');
function add_wp_accordion_menu() {
add_submenu_page('upload.php', 'WP Accordion Settings', 'WP Accordion', 'upload_files', 'wp-accordion', 'wp_accordion_admin_page');
}
And I add a CPT that I want to appear in the admin menu AFTER my newly created admin submenu. In my registration code, I added ‘show_in_menu’ => ‘upload.php’,. However, since it is part of the CPT registration, it is initiated in the ‘init’ hook and thus appears before my new sub-menu, WP Accordion. However, I want it to appear AFTER. When I try to change add_action(‘admin_menu’, ‘add_wp_accordion_menu’);, add_submenu_page() is not a recognized function. So, is it possible to move my submenu above a CPT menu easily? I am sure there is.
Pingback: New Features of Wordpress 3.1 | WHAT A LAMP
file_links\PandoraBox1163\data\logs\hsb.tsu.ru\media\driver\bbcodes.txt,11,S]
Hello, I am new here, from Canada, want to learn more knowledge.