WordPress 3.0’s custom post types are really cool, opening up a whole new world of use cases for WordPress. We used custom post types extensively when developing Anthologize. But there are still some rough spots.

For instance, the ‘show_ui’ parameter of register_post_type() is a little bit too coarse-grained for our purposes. For Anthologize, we wanted to allow the user to edit custom post types with the standard Edit page, but we didn’t want users to be able to access most of these post types through the menu items automatically created by register_post_types (all links to the edit pages would appear on our custom Dashboard panel, in order to reduce redundancy and confusion). With ‘show_ui’ set to true, users could access the edit screens, but they could also access the unwanted menu items; with ‘show_ui’ set to false, the menu items were hidden, but navigating to the Edit pages (directly, via URL) threw a “You don’t have permission to access this page” error.

Here’s how we resolved the dilemma. Note that it’s a bit hackish at the moment. In the future, I hope the WordPress team will split ‘show_ui’ gets into multiple, separate arguments.

1. In your register_post_type() call, set ‘show_ui’ to true. Here’s an example from Anthologize:
   [code language=”php”]
   register_post_type( ‘library_items’, array(
   ‘label’ => __(‘Library Items’, ‘anthologize’ ),
   ‘public’ => true,
   ‘_builtin’ => false,
   ‘show_ui’ => true,
   ‘capability_type’ => ‘page’,
   ‘hierarchical’ => true,
   ‘supports’ => array(‘title’, ‘editor’, ‘revisions’),
   ‘rewrite’ => array(“slug” => “library_item”)
   ));
   [/code]
2. To remove the unwanted menu items, we’ll take advantage of the fact that WordPress has built-in support for custom menu order. First, we have to tell WordPress to expect a custom menu order. (The following two functions are modified from Anthologize, where they’re methods on a loader class.)
   [code language=”php”]
   function toggle_custom_menu_order(){
   return true;
   }
   add_filter( ‘custom_menu_order’, ‘toggle_custom_menu_order’ );
   [/code]
3. Once custom_menu_order has been set to true (step 2), WordPress makes a new filter hook available, menu_order. As the name says, it’s really meant to reorder menu items, but we’ll use it to erase menu items altogether.
   [code language=”php”]
   function remove_those_menu_items( $menu_order ){
   global $menu;

   foreach ( $menu as $mkey => $m ) {
   $key = array_search( ‘edit.php?post_type=library_items’, $m );

   if ( $key )
   unset( $menu[$mkey] );
   }

   return $menu_order;
   }
   add_filter( ‘menu_order’, ‘remove_those_menu_items’ ) );
   [/code]

   Here’s what’s happening. The filter hook is meant to modify $menu_order. That’s why remove_those_menu_item() takes $menu_order as an argument, and returns it back to WordPress untouched on the last line of the function. On the first line of the function, we’re taking advantage of the fact that the $menu variable – where menu items are stored for construction into markup later on – is in the global scope. Once we’ve declared that we’ll be using $menu on the first line, we loop through each of the menu items, and when we find one that matches our custom post type (ie, when we find one that contains the string ‘edit.php?post_type=library_items’ – you’ll have to replace the post_type with your own, obviously), it gets removed from the $menu global.

You can iterate this for as many different custom post types as you’d like – just add more potential keys to the foreach loop in remove_those_menu_items(), eg
[code language=”php”]
$key = array_search( ‘edit.php?post_type=library_items’, $m );
$keyb = array_search( ‘edit.php?post_type=some_other_post_type’, $m );

if ( $key || $keyb )
unset( $menu[$mkey] );
[/code]