本文约 4,170 字，预计阅读 11 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：三个人写稿，进度全靠群里问
内容型站点到了一定规模，写作就不再是”一个人写完点发布”。常见的真实配置是：甲方提需求 → 主编派活 → 写手交稿 → 编辑校对 → SEO 复核 → 发布。每个人做完一步，下一个人不知道轮到自己了，于是进度靠微信群喊、靠表格记、靠主编人肉盯。
WordPress 原生的状态只有”草稿 / 待审 / 已发布”三种，而且”待审”只有编辑以上能看到提示，没有责任人、没有评论批注、没有通知。PublishPress 就是补这块：它给站点加上自定义状态（选题 / 已派发 / 写作中 / 待校对）、编辑批注（文章内部的讨论区，不对外）、内容清单（发布前必须勾完的项）、通知工作流（状态变更时自动通知到人）和编辑日历（谁哪天发什么一目了然）。
原理分析：状态流转与通知是两个独立系统
PublishPress 的核心由几块组成，理解它们的分工很重要：
| 模块 | 作用 | 依赖 |
|---|---|---|
| Statuses | 自定义文章状态 | 核心 register_post_status() |
| Calendar | 按月/周视图排期 | 读取 post_date |
| Content Checklist | 发布前必做项 | 元框 + 保存校验 |
| Editorial Comments | 内部批注 | 自定义 comment_type |
| Notifications | 状态变更自动通知 | 邮件/站内通知 |
| User Groups | 按组分配职责 | 角色体系扩展 |
关键点一：状态流转不是强制的。 PublishPress 让文章在自定义状态之间移动，但 WordPress 本身不限制”谁能把文章从写作中挪到待校对”——这一步的权限仍由角色能力决定。所以流程设计必须和权限设计一起做。
关键点二：通知是事件驱动的。 状态变更、批注新增、清单未完成时，PublishPress 触发相应的通知事件，由你配置”谁收、以什么形式收”。自定义业务事件也可以接进这套机制。
关键点三：编辑批注不是评论。 它用的是独立的 comment type，不会出现在前台，也不会被”关闭评论”那类操作影响。
保姆级实操
第一步：定义状态流转
后台「PublishPress → Statuses」，默认已有 Pitch（选题）、Assigned（已派发）、In Progress（写作中）等。按需增删，建议控制在 4–6 个，太多没人记得住。
一个可落地的流程：
选题 Pitch → 已派发 Assigned → 写作中 In Progress → 待校对 Draft/Pending Review → 已发布 Publish
每个状态在设置里可以指定颜色和”是否计入日历”。状态本质是注册的 post status，也可以用代码注册：
add_action( 'init', function () {
register_post_status( 'in-progress', array(
'label' => '写作中',
'public' => false,
'exclude_from_search' => true,
'show_in_admin_all_list' => true,
'show_in_admin_status_list' => true,
'label_count' => _n_noop( '写作中 (%s)', '写作中 (%s)' ),
) );
} );
第二步：配置通知工作流
「PublishPress → Notifications → Add New Workflow」：
- When：触发事件（如 “Post is moved to a new status”、
Editorial comment is added）； - Who to Notify：作者、指定的用户组、指定角色、或具体邮箱；
- What to say：邮件主题与正文，支持短代码变量（文章标题、链接、状态）。
业务系统里产生的事件（比如外部稿件系统回调）也可以接进来：
// 让自定义业务事件也走 PublishPress 的通知机制
do_action( 'publishpress_notif_workflow_run', 'manuscript_returned', array(
'post' => $post,
'actor' => wp_get_current_user(),
'message' => '外部稿件被退回，需要修改',
) );
第三步：设置内容清单（发布前的硬校验）
「PublishPress → Checklists」里定义必做项：是否设置特色图、是否填写 SEO 标题、是否选分类、正文是否超过 800 字。清单默认只是”提醒”，要变成硬约束需要配合校验逻辑：
add_action( 'transition_post_status', function ( $new_status, $old_status, $post ) {
if ( 'publish' !== $new_status || 'publish' === $old_status ) {
return;
}
$problems = array();
if ( ! has_post_thumbnail( $post->ID ) ) {
$problems[] = '未设置特色图片';
}
if ( ! has_excerpt( $post->ID ) ) {
$problems[] = '未填写摘要';
}
if ( $problems ) {
// 打回待审，并留一条编辑批注说明原因
wp_update_post( array( 'ID' => $post->ID, 'post_status' => 'pending' ) );
wp_insert_comment( array(
'comment_post_ID' => $post->ID,
'comment_author' => '系统',
'comment_content' => '发布被打回：' . implode( '；', $problems ),
'comment_type' => 'editorial_comment',
'user_id' => 0,
) );
}
}, 10, 3 );
第四步：用日历排期
「PublishPress → Calendar」按月视图展示所有已排期的文章，拖动即可改日期，点标题可快速编辑。配合状态筛选（只看”写作中”）与作者筛选，主编每天扫一眼就知道当天该发什么、谁还没交。
排期依赖 WordPress 的定时发布机制，也就是 post_status=future + 一条 publish_future_post 的定时任务。如果站点的定时任务不可靠，日历排得再好也不会按时发，务必先把 WP-Cron 与系统 cron 配合配置 这一步做扎实。
第五步：按组分配职责
「PublishPress → User Groups」把用户分组（写手组、编辑组、SEO 组），通知可以按组下发，避免”每次改状态都通知全站”。组与 WordPress 角色是两套东西：角色管能力，组管通知与流程。
常见踩坑
- 状态太多，没人记得住。 超过 6 个状态之后，写手只会随便选一个。流程设计以”能落地”为第一目标。
- 状态迁移动作没配权限。 PublishPress 不限制谁能迁移状态，需要靠
map_meta_cap或角色能力约束（做法见 User Role Editor 权限控制）。 - 通知太多变成骚扰。 每次批注都给全组发邮件，一周后所有人都会设过滤规则。只给”必须立即行动”的事件配通知。
- 邮件发不出去，以为流程没跑。 站点 SMTP 没配好时，通知会静默失败，先确认发信链路正常（可装邮件日志插件看发送记录）。
- 日历里看不到文章。 只有
post_date在未来或已排期的文章会出现；草稿若没设日期会堆在”未排期”区域。 - 自定义状态在前台 404。 自定义状态默认
public => false，前台访问不到是正常行为，不要为了”能预览”把它设成 public。 - 案例： 一个五人内容团队上线 PublishPress 后，把所有状态变更都配了邮件通知给全组。两周后 Slack 邮箱频道被刷屏，编辑干脆全部标为已读，结果真正重要的”稿件被打回”通知也被忽略了，一期内容晚了三天发布。调整方案：只保留三类通知（派发、打回、即将发布），其余改成站内提示，并在日历里用颜色区分状态。教训：流程工具的价值在于减少沟通噪音，而不是把所有动作都变成通知。
总结
设计审核流程的三条原则：状态数控制在 4–6 个、通知只给需要立即行动的事件、清单项要能自动化校验的才写进去（”检查语气”这种主观项没意义）。
落地顺序：定流程 → 建状态 → 配用户组 → 配通知 → 上日历 → 加发布前校验。技术上必须配套做两件事：确保定时任务可靠（否则排期形同虚设）、确保状态迁移有权限约束（否则流程可以被随意跳过）。界面层面如果想让不同角色看到不同的后台，可以叠加 Adminimize 精简后台界面 的收口。
