如何限制新用户角色以仅访问常规帖子，而不访问自定义帖子类型？

Question

[我们正在尝试添加一个名为'post_editor'的新用户角色，该角色只能访问Wordpress'的默认帖子，而不能访问2个自定义帖子类型，我们将它们分别命名为'content_blocks'和'slides'。

我们已经能够通过插件用户角色编辑器实现此目的，但我们正试图不添加其他插件。

这是我们尝试过的。在每种情况下，它都会创建新的用户角色，但他们可以继续查看，编辑和发布“ content_blocks”和“ slides”这两种自定义帖子类型。

我们如何防止此用户角色访问这两种自定义帖子类型？

// Attempt 1

  add_action( 'admin_init', 'add_role_post_editor' );

  function add_role_post_editor(){
    global $wp_roles;
    if( get_role( 'post_editor' ) == NULL){
        $cap = array(
            'edit_posts' => true,
            'edit_others_posts' => true,
            'edit_published_posts' => true,
            'read' => true,  
            'create_content_blocks' => false,
            'delete_content_blocks' => false,
            'edit_content_blocks' => false,
            'edit_slides' => false,
            'create_slides' => false,
            'delete_slides' => false,
          );
        add_role( 'post_editor', 'Post Editor', $cap );
     }

// Attempt 2

  add_action( 'admin_init', 'add_role_post_editor' );

  function add_role_post_editor(){
    global $wp_roles;
    if( get_role( 'post_editor' ) == NULL){

        $cap = array(
            'edit_posts' => true,
            'edit_others_posts' => true,
            'edit_published_posts' => true,
            'read' => true
          );
        add_role( 'post_editor', 'Post Editor', $cap );

        $role = get_role( 'post_editor' );

        $role->remove_cap( 'create_content_blocks');
        $role->remove_cap( 'delete_content_blocks' );
        $role->remove_cap( 'edit_content_blocks' );
        $role->remove_cap( 'edit_others_content_blocks' );
        $role->remove_cap( 'edit_published_content_blocks' );
        $role->remove_cap( 'publish_content_blocks');
        $role->remove_cap( 'read_slides' );
        $role->remove_cap( 'edit_slides' );
        $role->remove_cap( 'edit_others_slides' );
    }
   }

问题是，当我们注册自定义帖子类型时，我们也必须也注册这些功能，否则我们将无法使用它们来添加或删除user_roles？

Answer 1

这可能会为您指明正确的方向。

首先，您应该确定如何更新用户的角色和功能。这些与存储在数据库中的自定义帖子类型非常不同，后者只是在运行时进行注册。如果您要使用自定义代码来管理用户角色或上限，我建议您不要使用插件来执行相同的操作，因为过去这对我来说效果不佳。

// update this to re-init caps which are stored in DB
$custom_user_role_version = "1.1";

if ( $custom_user_role_version !== get_option( "custom_user_role_version" ) ) {
    update_option( "custom_user_role_version", $custom_user_role_version );

    $r = 'post_editor';

    remove_role( $r );
    add_role( $r, [
        'edit_posts' => true,
        'edit_others_posts' => true,
        'edit_published_posts' => true,
        'read' => true,
        'create_content_blocks' => false,
        'delete_content_blocks' => false,
        'edit_content_blocks' => false,
        'edit_slides' => false,
        'create_slides' => false,
        'delete_slides' => false,
    ]);
}

现在我们钩上'map_meta_cap'。该过滤器实际上只是具有相同名称的函数的最后一行。您应该阅读该函数以查看每个输入参数的选项。您必须进行一些研究和测试才能完成问题。读取函数中的代码还将使您对register_post_type的参数在元功能方面的工作方式有一些了解。

function is_post_editor( $user ){
    return $user instanceof WP_User && in_array( 'post_editor', $user->roles );
};

/**
 * @see map_meta_cap
 */
add_filter( 'map_meta_cap', function( $caps, $cap = '', $user_id = null, $args = []  ){

    // can return this to allow an action after authenticating the logged in user
//    $caps_to_allow = [
//        'exist'
//    ];

    switch( $cap ) {
        case 'edit_post':

            if ( in_array( get_post_type( $args[0]), [ 'content_blocks', 'slides' ] ) ){

                if ( is_post_editor( get_user_by( 'ID', $user_id ) ) ) {

                    // I think pushing 'do_not_allow' to $caps will also work.
                    return [
                        'do_not_allow'
                    ];
                }
            }

            break;
        case 'read_post':

            // you might need something here too.
            break;
    }

    // the $caps that the user must have to perform the thing that requires $cap
    return $caps;
});