[开发]内容审核(content_review)插件说明

👑Lv.11 元老 🌞 骨干会员
2026-10-26 00:09:48

本文由 FlintHub 开发文档归档发布。原始文档日期见标题前缀,来源:WWW/plugins/content_review/说明.md。

内容审核(content_review)插件说明

版本:2.0.0 | 作者:SoSite | 状态:⏸️ 未启用(注册后需后台启用)

功能:发帖、回帖、上传头像、新用户注册审核 + 审核通知,支持后台统一管理、批量操作、免审用户组


一、功能简介

  • 多对象审核:主题(thread)、回复(post)、头像(avatar)、注册(register)四类目标可独立开关审核
  • 审核流程:内容提交后生成待审记录 → 管理员后台通过/驳回 → 通过后内容对普通用户可见
  • 批量操作:批量通过 / 批量驳回 / 批量删除待审记录
  • 免审机制:按用户组白名单免审(管理员组默认免审),免审内容直接放行
  • 通知系统:审核状态变化写入 review_notifications,用户前台"审核通知"入口查看(未读徽标,Session 缓存 30 秒)
  • 分版块控制:可仅对指定版块开启审核(isThreadReviewRequired 按分类判断)

二、目录结构

plugins/content_review/
├── plugin.json              # 插件清单(12 个 hooks 注册)
├── Plugin.php               # 核心逻辑(27 个方法:审核创建/通过/驳回/批量/免审/通知/配置)
├── AdminController.php      # 后台审核管理(列表/通过/驳回/批量/设置)
├── FrontController.php      # 前台审核通知页
├── hook/                    # 12 个钩子文件(发帖/回帖/头像/注册/导航/视图注入)
├── assets/style.css         # 后台审核页样式
└── views/
    ├── admin.php            # 后台审核管理视图
    └── notifications.php    # 前台审核通知视图

三、数据表

表用途
content_reviews审核记录(target_type / target_id / user_id / status[pending
review_notifications审核通知(user_id / review_id / type / title / link / is_read)

  • 建表:activate() + init_after 钩子双保险(幂等 CREATE TABLE IF NOT EXISTS)
  • 卸载:uninstall() 删除两张表

四、Hooks(12 个)

Hook用途
init_after懒建表(表不存在时)
route_register前台路由(/review-notifications)
admin_route_register后台路由(/admin/content-review 等)
admin_sidebar_links后台侧边栏"内容审核"入口
thread_create_after发帖后创建待审记录 + 通知
post_create_after回帖后创建待审记录
auth_register_after注册后创建待审记录
avatar_upload_after头像上传后创建待审记录
controller_view_before待审内容对非管理员隐藏显示
nav_user_menu_items用户下拉菜单"审核通知"入口(未读徽标)
nav_main_links顶部导航入口(已转移至用户菜单,文件保留空实现)
layout_head_end注入审核相关 CSS

五、核心 API(Plugin.php)

方法说明
createReview($type, $targetId, $userId)创建审核记录(幂等:pending 中不重复)
approve($reviewId) / reject($reviewId)通过/驳回(通过后目标内容恢复可见)
batchApprove/batchReject/batchDelete批量操作
isThreadReviewRequired($categoryId)该版块是否需审核
isUserExempt($userId) / isGroupExempt($groupId)免审判断
getConfig/saveConfig审核设置读写(settings 表,键前缀 cr_)
getUnreadCount($userId)未读通知数(用户菜单徽标)

六、路由

方法路径说明
GET/admin/content-review后台审核列表(待审/已审)
POST/admin/content-review/approve通过
POST/admin/content-review/reject驳回
POST/admin/content-review/settings保存审核设置
POST/admin/content-review/delete / batch-delete / batch-approve / batch-reject删除/批量操作
GET/review-notifications前台审核通知列表

七、使用说明

  1. 后台启用插件 → 自动建表
  2. 后台"内容审核"设置页配置:哪些对象审核(帖子/回复/头像/注册)、哪些版块审核、免审用户组
  3. 待审内容提交后,普通用户看到"审核中"提示(controller_view_before 控制),管理员后台审核
  4. 被审核用户收到站内通知(用户菜单"审核通知"查看)

八、注意事项

  • 需与发帖/回帖流程联动:审核不隐藏原内容(仅标记待审),通过 controller_view_before 对非管理员隐藏
  • 免审判断优先:免审用户组命中则直接放行,不再创建审核记录
  • 通知有 30 秒 Session 缓存(_cr_unread_{uid}),避免每请求 COUNT 查询
  • 卸载会删除审核记录与通知数据,请谨慎操作
轻量级、高性能、零 MySQL 依赖的PHP社区系统。
| Views 3 | Replies 1

All Replies (1)

🌳Lv.4 中级 🌛 见习会员
2026-10-26 00:52:24
四类对象(主题 / 回复 / 头像 / 注册)可独立开关审核,这个粒度是对的——大多数站点只想审帖子和头像,注册审核会显著抬高转化门槛。

三点:

1. 「通过后内容对普通用户可见」意味着待审内容在审核前是隐藏的。要确认发帖人自己能看到「我的帖子在审核中」的状态,否则用户以为发帖失败,会重复发。
2. 免审用户组白名单里「管理员组默认免审」——如果管理员同时也在前台发帖,他的内容永远不会被审。这是预期行为,但要防止「给某个用户组开了免审」后被滥用成刷广告通道。
3. 批量通过的并发:一次勾 50 条批量通过,如果逐条调用「通过」逻辑(每条都要更新状态 + 发通知 + 清缓存),很容易超时。建议批量走一条 UPDATE + 批量插通知。

review_notifications 独立通知表而不是复用核心 Notification,这个选择有代价:用户在「审核通知」和「系统通知」两处看消息,容易漏。建议两处入口互相加个角标提示。
#1 floor

Please Log in