如何禁用自定义文章类型prj及关联分类法org的移至回收站功能？

我懂你现在的痛点——光藏起UI按钮根本没用，得从权限根源上彻底封死移至回收站的功能，不管是什么用户角色都没法用。下面给你一套完整的解决方案，覆盖自定义文章类型prj和关联分类法org的所有场景：

一、处理自定义文章类型prj #

1. 从权限层面拦截移至回收站操作 #

核心是通过map_meta_cap过滤器修改权限映射，直接拒绝所有用户对prj文章的删除/移至回收站权限：

add_filter('map_meta_cap', 'disable_prj_trash_cap', 10, 4);
function disable_prj_trash_cap($caps, $cap, $user_id, $args) {
    // 拦截移至回收站操作（对应delete_post权限）
    if ($cap === 'delete_post' && isset($args[0]) && get_post_type($args[0]) === 'prj') {
        return array('do_not_allow');
    }
    // 拦截彻底删除回收站中prj文章的操作
    if ($cap === 'delete_posts' && isset($args[0]) && get_post_type($args[0]) === 'prj') {
        return array('do_not_allow');
    }
    return $caps;
}

2. 清理后台UI中的移至回收站选项 #

虽然权限拦截已经生效，但为了避免用户看到不可用的选项，需要隐藏相关UI元素：

// 移除文章列表页的行内移至回收站选项
add_filter('post_row_actions', 'remove_prj_trash_row_actions', 10, 2);
function remove_prj_trash_row_actions($actions, $post) {
    if ($post->post_type === 'prj') {
        unset($actions['trash']);
    }
    return $actions;
}

// 移除文章列表页的批量移至回收站选项
add_filter('bulk_actions-edit-prj', 'remove_prj_bulk_trash_action');
function remove_prj_bulk_trash_action($actions) {
    unset($actions['trash']);
    return $actions;
}

// 移除文章编辑页的移至回收站按钮
add_action('admin_head-post.php', 'hide_prj_edit_trash_button');
add_action('admin_head-post-new.php', 'hide_prj_edit_trash_button');
function hide_prj_edit_trash_button() {
    global $post;
    if ($post && $post->post_type === 'prj') {
        echo '<style>#delete-action { display: none; }</style>';
    }
}

二、处理关联分类法org #

分类法的逻辑和文章类型类似，只是对应的权限和UI元素略有不同：

1. 从权限层面拦截分类的移至回收站操作 #

add_filter('map_meta_cap', 'disable_org_trash_cap', 10, 4);
function disable_org_trash_cap($caps, $cap, $user_id, $args) {
    // 拦截分类的移至回收站/删除操作（对应delete_term权限）
    if ($cap === 'delete_term' && isset($args[0]) && get_term($args[0])->taxonomy === 'org') {
        return array('do_not_allow');
    }
    return $caps;
}

2. 清理分类法后台的删除选项 #

// 移除分类列表页的行内删除（移至回收站）选项
add_filter('row_actions', 'remove_org_trash_row_actions', 10, 2);
function remove_org_trash_row_actions($actions, $term) {
    if (isset($term->taxonomy) && $term->taxonomy === 'org') {
        unset($actions['delete']);
    }
    return $actions;
}

// 移除分类编辑页的删除按钮
add_action('admin_head-term.php', 'hide_org_edit_delete_button');
function hide_org_edit_delete_button() {
    global $taxonomy;
    if ($taxonomy === 'org') {
        echo '<style>.delete-tag { display: none; }</style>';
    }
}

关键说明 #

• map_meta_cap是核心：它负责将用户的权限请求映射到实际可执行的操作，返回do_not_allow会直接阻止所有用户（包括管理员）执行对应操作，从根源上禁用功能。
• UI清理是补充：避免用户看到无效选项，提升后台体验，但即使不做UI清理，权限拦截也能确保操作无法执行。
• 这套方案覆盖了所有场景：不管用户是通过后台UI点击，还是直接调用WordPress API（比如wp_trash_post()），都会被权限系统阻止。

内容的提问来源于stack exchange，提问作者Hassan Alvi