20

How can I remove this custom post type from being shown in the dashboard for non admin users?

/* Add Websites Custom Post Type */
add_action( 'init', 'create_website_type' );
function create_website_type() {

    register_post_type( 'website',
        array(
            'labels' => array(
                'name' => __( 'Websites' ),
                'singular_name' => __( 'Website' ),
                'add_new' => __( 'Add New Website' ),
                'add_new_item' => __( 'Add New Website' ),
                'edit' => __( 'Edit Website' ),             
                'edit_item' => __( 'Edit Website' ),                
                'new_item' => __( 'Add New Website' ),              
                'view' => __( 'View Website' ),         
                'view_item' => __( 'View Website' ),                    
                'search_items' => __( 'Search Websites' ),  
                'not_found' => __( 'No Websites Found' ),
                'not_found_in_trash' => __( 'No Websites found in Trash' ),                                         
            ),
            'description' => __('Websites to be shown in Resources section.'),
            'public' => true,
            'show_ui' => true,
            'publicly_queryable' => true,
            'exclude_from_search' => false,
            'menu_position' => 20,
            'supports' => array('title', 'editor'),
            'can_export' => true        
        )
    ); 
    remove_post_type_support('website','editor'); 
}

2 Answers 2

21

register_post_type() accepts a parameter capabilities in its arguments. See get_post_type_capabilities() for possible values. From the comments:

By default, seven keys are accepted as part of the capabilities array:

  • edit_post, read_post, and delete_post are meta capabilities, which are then generally mapped to corresponding primitive capabilities depending on the context, which would be the post being edited/read/deleted and the user or role being checked. Thus these capabilities would generally not be granted directly to users or roles.

  • edit_posts - Controls whether objects of this post type can be edited.

  • edit_others_posts - Controls whether objects of this type owned by other users can be edited. If the post type does not support an author, then this will behave like edit_posts.
  • publish_posts - Controls publishing objects of this post type.
  • read_private_posts - Controls whether private objects can be read.

These four primitive capabilities are checked in core in various locations. There are also seven other primitive capabilities which are not referenced directly in core, except in map_meta_cap(), which takes the three aforementioned meta capabilities and translates them into one or more primitive capabilities that must then be checked against the user or role, depending on the context.

  • read - Controls whether objects of this post type can be read.
  • delete_posts - Controls whether objects of this post type can be deleted.
  • delete_private_posts - Controls whether private objects can be deleted.
  • delete_published_posts - Controls whether published objects can be deleted.
  • delete_others_posts - Controls whether objects owned by other users can be can be deleted. If the post type does not support an author, then this will behave like delete_posts.
  • edit_private_posts - Controls whether private objects can be edited.
  • edit_published_posts - Controls whether published objects can be edited.

These additional capabilities are only used in map_meta_cap(). Thus, they are only assigned by default if the post type is registered with the 'map_meta_cap' argument set to true (default is false).

In your registration arguments add:

'capabilities' => array(
    'edit_post'          => 'update_core',
    'read_post'          => 'update_core',
    'delete_post'        => 'update_core',
    'edit_posts'         => 'update_core',
    'edit_others_posts'  => 'update_core',
    'delete_posts'       => 'update_core',
    'publish_posts'      => 'update_core',
    'read_private_posts' => 'update_core'
),
7
  • How would you do the same thing but allowing administrators and editors to access the cpt?
    – urok93
    Jul 11, 2013 at 23:54
  • @drtanz Give both a custom capability, and filter user_has_cap. See this answer for an example.
    – fuxia
    Jul 11, 2013 at 23:58
  • Could I do it the same way you suggested, but put the manage_links capability (shared between admins and editors) instead of update_core?
    – urok93
    Jul 12, 2013 at 0:00
  • @drtanz Yes, but I would use a custom capability. The link manager will be removed eventually, and you don’t know what happens to the assigned capabilities then.
    – fuxia
    Jul 12, 2013 at 0:01
  • 5
    Note about update_core; Only Administrators of single site installations have this capabilitiy. In Multisite, only the Super Admin has thisabilities.
    – numediaweb
    Mar 9, 2014 at 19:27
-1

For Multi site admin can use below code in functions.php:

/* Add Websites Custom Post Type */

function create_website_CustomPostType() {

    register_post_type( 'website',
        array(
            'labels' => array(
                'name' => __( 'Websites' ),
                'singular_name' => __( 'Website' ),
                'add_new' => __( 'Add New Website' ),
                'add_new_item' => __( 'Add New Website' ),
                'edit' => __( 'Edit Website' ),             
                'edit_item' => __( 'Edit Website' ),                
                'new_item' => __( 'Add New Website' ),              
                'view' => __( 'View Website' ),         
                'view_item' => __( 'View Website' ),                    
                'search_items' => __( 'Search Websites' ),  
                'not_found' => __( 'No Websites Found' ),
                'not_found_in_trash' => __( 'No Websites found in Trash' ),                                         
            ),
            'description' => __('Websites to be shown in Resources section.'),
            'public' => true,
            'show_ui' => true,
            'publicly_queryable' => true,
            'exclude_from_search' => false,
            'menu_position' => 20,
            'supports' => array('title', 'editor'),
            'can_export' => true        
        )
    ); 
}

 // if user login with administrator display custom post type else dont
add_action( 'init', function(){
     $WhatRoleUserLoginNow= wp_get_current_user()->caps;
     $StatusAdmin=$WhatRoleUserLoginNow['administrator'] ?? null;

     if( $StatusAdmin) {
          create_website_CustomPostType();
             }
 


} );

The above code add custom post type to all admin users in multisite mode and super admin and hide and forbidden for another user role like author ,editor , ... .

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.