WordPress前端表单特色图正常上传但WP编辑器Add Media无法传新文件

你遇到的这个报错不是全局上传权限不足导致的——如果是全局upload_files权限缺失，WP抛出的报错会是"Sorry, you are not allowed to upload files"。当前报错You don't have the permission to attach files to this publication是WP的媒体上传逻辑在校验「当前用户是否有权限把上传的附件关联到请求指定的post对象」时失败触发的，和你现在特色图上传能正常工作的差异，本质是两者的权限校验上下文完全不一样。

1. 定位上传请求的实际校验目标post_id #

• 打开浏览器开发者工具，切换到网络面板
• 点击编辑器的Add Media按钮打开媒体弹窗，尝试上传文件触发报错
• 找到上传接口async-upload.php的请求记录，查看表单参数里的post_id值
• 大概率你会发现这个值等于你前端投稿页面本身的WP页面ID，而不是用户正在编辑的待发布文章ID：这个投稿页面一般是管理员创建的固定页面，对应登录投稿的普通用户根本没有这个页面的编辑权限，自然会触发权限校验失败

对应修复 #

如果确认了post_id指向的是投稿页面本身，有两种调整方式：

• 临时新建投稿的场景（用户未保存草稿，没有生成独立post ID）：在页面底部注入JS，把媒体模块的默认关联post ID设置为0。当post_id为0时，WP的权限逻辑会跳过单篇文章的编辑权限校验，只检查用户是否有全局upload_files权限即可：

// 仅在前端投稿页面输出，避免影响后台
add_action( 'wp_footer', function() {
    if ( ! is_page( '你的前端投稿页面的别名' ) ) return;
    // 若JS注入不生效，可在调用wp_editor前提前执行 wp_enqueue_media() 确保媒体模块资源加载完整
    ?>
    <script>
    wp.media.model.settings.post.id = 0;
    </script>
    <?php
});

• 用户已经有保存的草稿/待编辑文章的场景：在渲染wp_editor之前，把全局$post对象替换成当前用户正在编辑的文章对象，让媒体模块自动读取正确的post ID，而不是当前投稿页面的ID。

2. 修正角色权限的配置遗漏 #

你之前给角色加的权限存在两个常见的坑：

• 能力项混淆：你添加的edit_post是针对单个已存在文章的编辑权限，而WP媒体上传校验关联权限时，需要的是全局的edit_posts（带复数s）能力——这个能力代表用户可以创建、编辑自己发布的内容，和单篇的edit_post是完全独立的两个权限项
• 钩子生效问题：你用的register_activation_hook只会在插件激活的瞬间执行一次代码，如果你写完权限代码后没有重新激活对应插件，代码根本不会执行，权限也不会写入数据库的角色配置里

对应修复 #

• 把角色能力补充完整，补上缺失的edit_posts能力，临时挂在init钩子上跑一次让配置写入数据库：

// 临时跑一次写入权限，写入后可以删掉这个钩子
add_action( 'init', function() {
    $role = get_role( 'specificrole' );
    if ( ! $role ) return;
    $role->add_cap( 'upload_files' );
    $role->add_cap( 'edit_posts' ); // 补上带s的全局编辑能力
    $role->add_cap( 'edit_post' );
    $role->add_cap( 'edit_published_posts' );
}, 1 );

• 临时访问任意页面让上面的代码执行一次，去WP后台的用户列表页，确认对应用户角色已经有这些能力，执行完成后可以删除这个临时钩子，避免每次页面加载都重复执行
• 不要随意给用户角色加edit_others_pages、edit_published_pages这类编辑其他用户内容的过高权限，这类权限和投稿用户上传自己文章的配图需求无关，反而会带来安全风险

3. 排除第三方插件的权限逻辑干扰 #

• 临时把站点主题切换为默认的Twenty系列主题，禁用所有第三方插件（包含前端投稿、用户中心、权限管理类插件）
• 再次测试Add Media按钮的上传功能，如果上传恢复正常，就逐个重新启用插件，定位到哪个插件修改了map_meta_cap或者媒体上传的权限校验逻辑，调整对应插件的配置即可

你之前尝试的define('CONCATENATE_SCRIPTS', false)、删除CSS sourcemap注释的操作，和当前的权限报错完全没有关联，不需要再调整这类配置。

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