6

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

我有一个自定义角色，我们称之为它librarian，还有一个自定义帖子类型，我们称之为它book。

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

按照另一个问题（WordPress：在自定义帖子类型上禁用“添加新”）和WordPress 文档中的建议，我最终得到了以下代码：

// 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回应：

抱歉，您无权访问此页面。

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

  • 如果我以 .edit.php?post_type=book身份访问，那么我会根据需要看到没有添加新按钮administrator的列表页面。
  • 如果我为librarian角色赋予了能力，那么我会根据需要看到没有添加新edit_posts按钮的列表页面（但我不想赋予他们能力！）。edit_posts

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

  • 如果我'create_posts' => 'do_not_allow'从book类型注册中删除 ，则librarian 可以看到列表页面，但它包含Add New按钮。

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

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

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

4

3 回答 3

5

看来这是 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 更改。

原因

对于那些想知道细节的人......</p>

访问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()呼叫通过 to呼叫get_admin_page_parent()。

如果子菜单已被删除，则get_admin_page_parent()返回一个空的父级，最终导致在角色的情况下user_can_access_admin_page()错误地返回（角色因不同的原因通过）。falselibrarianadministrator

如果子菜单保留在原位，则get_admin_page_parent()返回非空父级，并且访问检查从那里正确进行。

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

于 2019-10-04T09:58:27.513 回答
0

我为这个问题找到了 2 个解决方法：

首先，我发现为 custom_post_type create_posts 分配特定功能而不是使用do_not_allow

所以我使用：

...
'capability_type'     => 'books',
'capabilities'        => array(
    'create_posts' => 'add_new_books'
),
'map_meta_cap'        => true,
...

这样我可以为管理员或其他经理分配 add_new_books 功能，但不允许其他角色使用。

选项 1：（
过滤 user_has_cap 以假装用户拥有“edit_posts”，然后删除帖子菜单项）

add_filter(
    'user_has_cap',
    function( $all_caps, $caps ) {
        global $typenow, $menu;

        if ( is_admin() && ! empty( $typenow ) && stripos( $_SERVER['REQUEST_URI'], 'edit.php' ) && stripos( $_SERVER['REQUEST_URI'], 'post_type=' . $typenow ) && in_array( 'edit_posts', $caps, true ) ) {
            // Temporarily assign the user the edit_posts capability
            $all_caps['edit_posts'] = true;
            // Now Remove any menu items with edit_posts besides the custom post type pages.
            if ( ! empty( $menu ) ) {
                foreach ( $menu as $menu_key => $menu_item ) {
                    if ( ! empty( $menu_item[1] ) && ( $menu_item[1] === 'edit_posts' || $menu_item[2] === 'edit.php' ) ) {
                        remove_menu_page( $menu_item[2] );
                    }
                }
            }
        }

        return $all_caps;
    },
    10,
    2
);

虽然这可行，但它确实为未定义的索引添加了一些 PHP 通知。

选项 2：（
过滤 $pagenow 变量）

add_action(
    'admin_menu',
    function () {
        global $pagenow, $typenow;

        if ( is_admin() && ! empty( $typenow ) && ! empty( $pagenow ) && $pagenow === 'edit.php' && stripos( $_SERVER['REQUEST_URI'], 'edit.php' ) && stripos( $_SERVER['REQUEST_URI'], 'post_type=' . $typenow ) ) {
            $pagenow = 'custom_post_type_edit.php';
        }
    }
);

这可以在不添加任何 PHP 通知的情况下工作，但可能会出现无法预料的问题，因为它正在更改 $pagenow 变量，但仅限于该页面。

到目前为止，我正在使用选项 2，没有任何问题。

于 2021-02-19T20:19:51.467 回答
0

我想我已经找到了一种解决方法，而无需编辑核心文件。

如您所说，此错误的原因是没有子菜单项的空菜单会导致访问检查错误地返回false。

所以解决方法是不要让列表页面成为顶级菜单。相反，使其成为现有菜单下的子菜单。这样就不会有一个空的顶级菜单，并且您可以在没有“添加新”按钮的情况下正确查看列表页面。

这只是一种解决方法，并不理想。但也许它比编辑核心文件更好。

创建自定义帖子类型同时将其列表页面作为子菜单项的方法很简单。的 argsregister_post_type有一个名为 的 arg show_in_menu。正如文档所说：

如果是现有顶级菜单的字符串（例如'tools.php' 或'edit.php?post_type=page'），则帖子类型将作为其子菜单放置。

所以代码将是：

register_post_type('book',
array(
    'labels'                => array(
        'name' => __( 'book' ),
        'singular_name' => __( 'Book' )
    ),
    'capability_type'       => array('book', 'books'),
    'capabilities'          => array(
        'create_posts' => 'do_not_allow'
    ),
    'map_meta_cap'          => true,
    'show_ui'               => true,
    'show_in_menu'          => 'tools.php',   //or whatever top-level menu you'd like
    //... other args omitted
));
于 2020-02-25T09:50:41.323 回答