The theme is FA5-only, but aksrt_icon_markup() prefixed bare glyphs with
the FA4 style token, so stored icon-picker values rendered FA4 markup,
and three runtime strings still carried the FA4 double-fa form (report
modal header and submit button, comment report menu item). That left the
navigation icon contract failing at 11/12.
- aksrt_icon_markup() normalizes bare glyphs, legacy FA4 values and
style-only values to "fa fas fa-<glyph>", keeping the FA5 brand family
(fa fab) and trailing classes intact.
- aksrt_normalize_icon_key() strips the legacy FA4 prefix so stored
values resolve against the brand-icon catalog again.
- report.js and the comment report item emit FA5 markup.
- An icon-picker contract test locks the upgrade behaviour.
Verification: 338 widget-system, 12 navigation, 28 admin and 13
front-submit contract tests pass; normalization also exercised against
legacy, FA5 and brand inputs.
1:1 replicate the reference theme user-ban flow on the frontend:
- Ban/unban modal rendered by inc/helpers/user-ban.php, opened via
AksrtModalRuntime.openRemote (600px desktop dialog, 360px initial
height, mobile bottom drawer, c-yellow colorful unban header).
- Three entry points wired: user homepage cover three-dot menu,
comment section menu, article author card menu (ban item takes
priority over report, matching the reference hook order).
- REST endpoints /user-ban/modal and /user-ban/set under aksrt/v1,
guarded by check_permission, persisted through User\Restriction.
- Submit semantics match zib_ajax_set_user_ban: ban reloads the page,
unban only closes the modal.
Cleanup (no dual-track): the backend ban-restrictions tab, its form
handlers and flash keys are removed; ticket processing links to the
frontend user homepage as the reference theme does; admin/report and
appeal notification URLs move to type/status query args.
Verification: 337/337 widget-system contract tests, 41/41 admin and
front-submit tests, php -l clean on all changed PHP files.
The record list rendered an action only for global ban/suspend rows, so
mute (禁言) rows showed an empty 操作 column with no way to lift them.
- record list: active mute rows now render a 解除禁言 button
- unban view: falls back to the active mute record when no ban/suspend
exists, with 解除禁言/禁言中 titles (ban > suspend > mute precedence
preserved); lifting still goes through lift_user_restriction (mute
included by default)
- contract tests: cover the mute action link and the unban-view fallback
- Restriction: add is_suspended/get_active_suspend; comment block now covers
suspend (小黑屋) in addition to mute, with reason in the deny message
- FrontSubmitSave::persist: block post/draft/edit submission for suspended
users (reference-theme semantics: 小黑屋 loses all publishing rights)
- report.js: close icon switched from fa-times to the SVG sprite ic-close
(#icon-close), same as reference theme; textareas gain autoHeight growth
(hidden 'other reason' box skips the first measurement)
- WeChatNotify: NOTIFY_TYPES now includes report/system so report results
and account restriction notices fan out to WeChat template messages;
generic title/description fallback for template values
- contract tests: +3 tests (suspend enforcement, modal polish, wechat types)
Replace the self-invented CRUD (warn/mute/suspend/ban + scope selector)
with the reference-theme ban model: ban method (blackroom suspend /
login ban), duration radios (1/7/14/30/100 days or permanent, default 7),
preset reason chips with an other-reason input, ban note, delete-all-
content switch (posts/comments to trash), and a no-appeal switch with a
required notice that also gates the frontend appeal entry. Banned users
render the status info view (status/start/end/reason) with an unban
leave-a-message form; the record list uses the reference columns and
per-user unban links. Bans notify the user in-site like the reference
zib_updata_user_ban_msg.
Expand and cancel were full admin navigations (action/id query round
trip), which is why they felt slow. Pre-render each pending ticket's
process form as a hidden colspan=6 row and swap list row <-> form via a
small delegated jQuery handler: expand hides the row (info stays
single-sourced), collapse brings it back, only one form is open at a
time, and the no-JS action=process links keep working as a fallback.
The reference theme has no such element above the inline process form;
filter reset is already handled by the type buttons and status subsubsub.
Contract label list updated accordingly.
Restore the reference-theme direction: processing happens inline in the
filtered list, not on a separate page. The actual defect was the same
ticket being rendered twice (list row + form) while the bare <form><table>
inside <tbody> got foster-parented by the browser, displacing the extra
row info below the submit button. Now the processing ticket renders only
as the form, wrapped in a valid <tr><td colspan=6>, and every other row
renders normally.
action=process used to append the process form into the tickets table as
a bare <form><table> inside <tbody> — invalid HTML that browsers reflow,
leaving the ticket list stacked below the submit button. Render the
process form as its own view (early return, list and pagenavi skipped,
with a lookup fallback beyond the current page slice) and keep the list
view free of form injection.
Ban appeals already sent site messages to admins and to the appellant,
but reports only produced emails: the submit path never notified admins
in-site and the status change path never notified the reporter. Send a
'report' site message to administrators on submit (deep link to the
ticket list) and to the reporter on status change (status label plus
the admin note), matching the appeal flow's direct-send pattern.
Contract test extended accordingly.
update_status() fired aksrt_report_status_changed without the note and
the mail listener hard-coded note => '', so the reply-to-reporter
comment written in the process form never reached the email. Pass the
sanitized note as a 4th action arg, render it via the existing {note}
placeholder, and map the raw status key to its Chinese label in the
email body. Contract test extended accordingly.
The process form posted to admin-post.php without a hidden action field,
so no admin_post_{action} hook fired and WordPress returned a blank
page. Dispatch to aksrt_users_update_report / aksrt_users_process_appeal
per ticket kind, matching every other native form, and lock the contract
in the report test.
ban_settings() derived each reason slug via sanitize_key(label), which
strips CJK text to an empty string; the frontend filter then discarded
every reason (including the schema defaults) and fell back to the
hard-coded list. Derive the slug from an ASCII key when possible and
from a stable md5 short hash of the label otherwise, and relax the
frontend filter to the label only. Adds a WP-stub harness that verifies
the defaults path end to end (tests/dev/verify-ban-settings-defaults.php).
ban_settings()/report_settings() read the raw aksrt_settings option, so on
sites that never saved the ban/report admin section the keys are absent and
the preset reasons resolved to an empty list (frontend hard-coded fallback).
Read the section through SchemaProvider instead — read_section_settings
merges schema defaults, matching the reference theme _pz(key, default)
semantics. Also drop the dead user_report_categories parse chain that fed
a key nobody stores or consumes.
main.css already ships the reference plus icon (.preview .add:before/:after,
25px rounded bars centered via inset:0 + margin:auto). The duplicate
left/top:50% + translate version in modal-runtime.css over-constrained
the same pseudo elements (right/bottom:0 + margin:auto from main.css
still applied), pushing the bars to 75%/75% so only an L-shaped corner
was visible. Drop the duplicate and lock the single-source contract in
the report test.
- read preset reasons from the real source (ban_preset_reason via
UserRuntime::ban_settings); the previous injection read a
nonexistent report.categories key, so backend reasons never showed
- rebuild the modal on the reference markup contract: edit-header
warning header, reason chips toggling the reference .active class
(focus color), other-reason textarea, violation link, description,
but-average modal-buts footer
- add image evidence upload gated by user_report_img_s: new
/report/upload-image route reusing the comment upload handler with
its own permission, preview/remove UI, up to 3 images appended to
the report content
- render the backend report notice (user_report_desc, sanitized HTML)
inside the modal
- widen the dialog to the reference 600px desktop geometry and share
the form-upload preview styles with the order review modal
- extend the report contract test accordingly
The comment three-dot menu relied on the legacy data-toggle=dropdown
delegation living in comment-move-form.js; when that bundle chain does
not evaluate (stale cache or an earlier top-level error), the menu
appears dead. Move the comment action dropdown to its own top-level
document delegation in comments.js (data-aksrt-comment-drop), keep the
.open-driven CSS contract including the mobile drop-fixed-sm sheet,
sync aria-expanded, close on outside click / Escape / menu item click,
and stay idempotent for AJAX-injected comments.
- enqueue report.js on singular pages too: the single meta box and
comment report buttons rendered without their script handler, so
clicking the report item did nothing
- align the report runtime default with the admin schema and the
reference theme (user_report_s default true) so the public user
home cover menu shows the report entry
- rebuild report.js on top of AksrtModalRuntime following the
reference theme modal format: red warning header, preset reason
badges with an other-reason textarea, violation link field, detail
description and a cancel/submit footer; submit goes through the
unified /report/submit endpoint
- keep report inside the comment three-dot dropdown and enrich the
payload (target name/avatar) for the modal; inject configured
report categories via aksrtData.reportCategories
- update the report contract test accordingly
The users-interaction sidebar entry 禁封/举报 was a redirect stub; it is
now a schema-driven settings page replicating the reference theme
field-for-field:
- user_ban_s / user_report_s switches, ban_preset_reason and
ban_appeal_keys as repeatable group rows ({t}), ban_appeal_desc and
user_report_desc HTML textareas with the reference default copy, and
user_report_img_s — keys, labels, help texts, defaults and ordering
all mirrored in SchemaUsers.php and the SPA report.js schema
- UserRuntime::ban_settings()/report_settings() and
BanAppeal::settings() read the new group-array values with fallback
to the previous line/comma formats
- delete the self-built SPA queue pages (UsersBan, UsersReport,
ReportDetailDrawer, UsersMessages) that the reference theme does not
have; legacy /users/report bookmarks still redirect to the native page
- contract tests: lock the schema keys/labels, the schemaPage mount and
the deleted-file state; drop reads of removed components
- submenu page title becomes 处理举报及禁封申诉 (menu title 举报&禁封申诉)
- replicate the reference pagenavi: first/prev/numbered/next/last links
with displaying-num (每页 20 共N) and paging-input (第X页共Y页)
- report process form is now status-only like the reference theme:
被举报用户/举报信息/被举报用户禁封信息/处理说明 blocks, with a 点击此处
link to the restrictions tab (prefilled user_id) instead of an
enforcement select
- replicate reference row details (举报用户/举报内容, 正在处理 state,
此用户已解封 auto-close for stale appeals, 当前用户已解封 notice) and
the table-box/preview-item style block
- drop now-unused ReportCenter::get_report_row
- rename the users.php submenu to 举报&禁封申诉 and the page heading to
用户禁封申诉及用户举报管理
- merge report tickets and ban appeals into one Zibll-style queue:
type filter buttons (全部/禁封申诉/用户举报), status subsubsub
(全部/待处理/已批准/已拒绝), search box, sortable widefat table with
the same column set (状态/类型/提交用户/详情/提交时间/更新时间),
inline process forms and 20-per-page pagination
- report process form shows the reported target, restriction status and
an enforcement action select; appeal form offers approve/reject radios
with a message to the user
- move restriction enforcement into ReportCenter::apply_action so REST
and the native page share one implementation; add get_report_row()
- drop the old three-tab rendering (reports/appeals tabs) and fix all
notice/mail/SPA links to the merged page
The users SPA section had no ban/report menu item after the queue pages
moved to native WP admin. Add a sidebar entry under 用户&互动 that lands
on users.php?page=aksrt_user_ban via NativeOpsRedirect, and keep the
old /users/report bookmark redirect.
- apply_report_action now writes aksrt_user_restriction via Restriction::restrict
and lifts via new lift_user_restriction(), replacing the display-only
aksrt_user_ban_state meta dual-track
- ban type restrictions destroy the target user's sessions on apply
- appeal approval lifts active ban/suspend/mute restrictions instead of
updating a nonexistent status column
- UsersBan.vue posts to /users/{id}/restrict with valid types (warn/mute/
suspend/ban), scope and expires_at
- add comment report entry to the comment actions dropdown
- add duplicate pending report guard on submit
- remove dead ReportCenter ajax handlers, option migration, REST alias
routes and write-only restriction meta
- fix report admin mail link to the real aksrt_user_ban page
- add report-ban contract tests
kate522