Remove Custom Post Type menu for non-administrator users.

I’ve been researching this all day and haven’t come up with much results.

I want to restrict who can see my Custom Post Types by User Level (or some other way). So if the person logged in is not an ‘administrator’ the added Custom Post Types are not visible to them.

Here is part of a Custom Post Type that I have:

add_action('init', 'portfolio_register');

function portfolio_register() {

    $labels = array(
        'name' => _x('Case Studies', 'post type general name'),
        'singular_name' => _x('Case Study Item', 'post type singular name'),
        'add_new' => _x('Add New', 'portfolio item'),
        'add_new_item' => __('Add New Case Study Item'),
        'edit_item' => __('Edit Case Study Item'),
        'new_item' => __('New Case Study Item'),
        'view_item' => __('View Case Study Item'),
        'search_items' => __('Search Case Studies'),
        'not_found' =>  __('Nothing found'),
        'not_found_in_trash' => __('Nothing found in Trash'),
        'parent_item_colon' => ''
    );

    $args = array(
        'labels' => $labels,
        'public' => true,
        'publicly_queryable' => true,
        'show_ui' => true,
        'query_var' => true,
        /*'menu_icon' => get_stylesheet_directory_uri() . '/article16.png',*/
        'rewrite' => true,
        'capability_type' => 'post',
        'hierarchical' => false,
        'menu_position' => null,
        'supports' => array('title','editor','thumbnail')
      ); 

    register_post_type( 'portfolio' , $args );
}

And here are the potential solutions that I found that don’t work for the Custom Post Type menu removal:

function remove_menus()
{
    global $menu;
    global $current_user;
    get_currentuserinfo();

    if($current_user->user_login != 'admin')
    {
        $restricted = array(__('Posts'),
                            __('Media'),
                            __('Links'),
                            __('Pages'),
                            __('Comments'),
                            __('Appearance'),
                            __('Plugins'),
                            __('Users'),
                            __('Tools'),
                            __('Settings')
        );
        end ($menu);
        while (prev($menu)){
            $value = explode(' ',$menu[key($menu)][0]);
            if(in_array($value[0] != NULL?$value[0]:"" , $restricted)){unset($menu[key($menu)]);}
        }// end while

    }// end if
}
add_action('admin_menu', 'remove_menus');

The above works to remove the default menu items but I couldn’t get it to remove a Custom Post Type menu. Plus it is username specific, which is ok if I could add more than one user to it.

global $user_login;
get_currentuserinfo();
   if (!current_user_can('update_plugins')) {
      .......
   }

The above didn’t work at all.

Thanks.

Codex – Register Post Type

See the capability_type and capabilities arguments for register_post_type.
You can pass the capabilities argument an array of capabilities to map to the necessary caps, here’s an example of the args array with custom capabilities.

$args = array(
    'labels' => $labels,
    'public' => true,
    'publicly_queryable' => true,
    'show_ui' => true,
    'query_var' => true,
    'rewrite' => true,
    'capabilities' => array(
        'publish_posts' => 'ADD_CAP_HERE',
        'edit_posts' => 'ADD_CAP_HERE',
        'edit_others_posts' => 'ADD_CAP_HERE',
        'delete_posts' => 'ADD_CAP_HERE',
        'delete_others_posts' => 'ADD_CAP_HERE',
        'read_private_posts' => 'ADD_CAP_HERE',
        'edit_post' => 'ADD_CAP_HERE',
        'delete_post' => 'ADD_CAP_HERE',
        'read_post' => 'ADD_CAP_HERE',
    ),
    'hierarchical' => false,
    'menu_position' => null,
    'supports' => array('title','editor','thumbnail')
); 

You’d of course replace ADD_CAP_HERE with a capability. If you wanted to limit this post type to admins, simply use a capability only admins have, such as manage_options.

Table of roles and their caps(for quick reference).
http://codex.wordpress.org/Roles_and_Capabilities#Capability_vs._Role_Table