This is a pretty advanced post, but it was causing me issues for about half an hour, so I thought I’d share quickly.

Here’s the deal: I wanted to add a submenu to an existing custom post type. Right away, when creating a custom post type with public or show_ui set to true, WordPress will create a new top-level menu item, with a submenu item of “Add .” I wanted to be able to hook into that, and add a new sub-menu item called “settings”

Already in the plugin, I had created a custom post type:
[code lang=”php”]
register_post_type( ‘tdd_beans’, ‘tdd_beans_register_post_type’ );
[/code]

The details of my beans post-type are unimportant. What is important is the handle. In all cases, it’s the first parameter that you pass to register_post_type() — in this case, beans.

[code lang=”php”]
function tdd_beans_menu(){
add_submenu_page( ‘edit.php?post_type=tdd_beans’, ‘Beans Settings’, ‘Settings’, ‘manage_options’, ‘tdd-beans-settings-menu’, ‘tdd_beans_view_settings’ );
}
add_action( ‘admin_menu’, ‘tdd_pb_beans_menu’ );
[/code]

The add_submenu_page() function takes these parameters:

1. $parent_slug: The magic is that it requires that whole edit.php whatnot in order to work. At least right now, although I believe that may be a bug in WordPress. Future versions may only require the slug (tdd_beans). In any case, it’s the slug for the parent page
2. $page_title: This is what goes between the <title> tags
3. $menu_title: What shows up in the menu (keep it short)
4. $capability: This maps to a WordPress capability that will be required to access this sub-menu. It should probably map to whatever the capability is for your custom post type. Sub-menus will continue to display even if their parent menu is unavailable due to permissions
5. $menu_slug: Put your own menu slug here for referencing this menu item elsewhere.
6. $function: Lastly, this is the function that will echo stuff to the page.

[code lang=”php”]
function tdd_beans_view_settings(){
echo ‘<div class="wrap"><h2>Hello World (inc. beans)</h2></div>’;
}
[/code]