具有自定义角色的 WordPress 用户无法查看没有 "create_posts"功能的自定义帖子类型的列表页面

Question

我正在运行一个 WordPress 5.2.3 站点并且在管理面板中遇到问题。

我有一个自定义角色，我们称之为 librarian ，以及自定义的帖子类型，我们称之为 book .

我想让 librarian可以编辑 book但不创建一个新的。

遵循另一个问题 ( WordPress: Disable “Add New” on Custom Post Type ) 和 WordPress 中的建议documentation ，我最终得到了这段代码:

// Custom post type.
register_post_type('book',
    array(
        'labels'                => array(
            'name' => __( 'book' ),
            'singular_name' => __( 'Book' )
        ),
        'capability_type'       => array('book', 'books'),
        'capabilities'          => array(
            'create_posts' => 'do_not_allow' // <-- The important bit.
        ),
        'map_meta_cap'          => true,
        'description'           => 'Book full of pages',
        'exclude_from_search'   => true,
        'publicly_queryable'    => false,
        'show_in_nav_menus'     => false,
        'show_ui'               => true,
        'show_in_menu'          => true,
        'show_in_rest'          => true,
        'menu_icon'             => 'dashicons-location',
        'menu_position'         => 5,
        'supports'              => array('title', 'revisions')
    ));

// Custom role.
add_role('librarian', 'Librarian', array(
    'read'                  => true,
    'edit_books'            => true,
    'edit_published_books'  => true
));

当我访问 edit.php?post_type=book 时，我期待着作为 librariran然后我会看到 books 的列表进行编辑，但我看不到 新增 按钮。但是，我实际得到的是 403回复:

Sorry, you are not allowed to access this page.

我认为这可能是 WordPress 中的一个错误，原因如下:

如果我访问 edit.php?post_type=book作为 administrator ，然后我看到没有 的列表页面新增 按钮，根据需要。

如果我给 librarian角色edit_posts能力，然后我看到没有 的列表页面新增 按钮，根据需要(但我不想给他们 edit_posts 功能!)。

这些让我认为一般设置的自定义帖子类型不是问题。

如果我删除 'create_posts' => 'do_not_allow'来自 book类型注册，librarian可以看到列表页，但它包含新增 按钮。

这让我认为一般设置的自定义角色不是问题。

有没有人遇到过这个问题？我是否错过了配置中的任何内容？或者有没有简单的补丁或解决方法？

任何帮助，将不胜感激!谢谢。

Answer 1

看来这是 WordPress 中的一个错误。我找到了问题的根源和解决方法。

解决方法

如果您对原因不感兴趣，解决方法是注释掉 wp-admin/includes/menu.php 中的这段修饰代码。 :

https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/menu.php#L168

/*
 * If there is only one submenu and it is has same destination as the parent,
 * remove the submenu.
 */
if ( ! empty( $submenu[ $data[2] ] ) && 1 == count( $submenu[ $data[2] ] ) ) {
    $subs      = $submenu[ $data[2] ];
    $first_sub = reset( $subs );
    if ( $data[2] == $first_sub[2] ) {
        unset( $submenu[ $data[2] ] );
    }
}

这将意味着以前不显示子菜单的一些菜单项现在将显示(与主菜单项相同的单个项目)，但这只是一个装饰性的 UI 更改。

原因

对于那些想知道细节的人......

访问 edit.php?post_type=book在 wp-admin/includes/menu.php 中未通过此检查:

https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/menu.php#L341

if ( ! user_can_access_admin_page() ) {

    /**
     * Fires when access to an admin page is denied.
     *
     * @since 2.5.0
     */
    do_action( 'admin_page_access_denied' );

    wp_die( __( 'Sorry, you are not allowed to access this page.' ), 403 );
}

调用 user_can_access_admin_page() 调用 get_admin_page_parent() .

如果子菜单已被删除， get_admin_page_parent()返回一个空的父级，最终导致 user_can_access_admin_page()错误返回 false在 librarian 的情况下角色( administrator 角色因不同原因而传递)。

如果保留子菜单， get_admin_page_parent()返回一个非空的父节点，并且访问检查从那里正确进行。

所以根本问题是全局 $submenu既用于确定 UI，也用于对权限层次结构做出决策。除了上面的解决方法之外，我没有看到这个问题的立即快速解决方案，它不会在整个 WordPress 代码的其他地方产生副作用。