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.
- 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
Register a dedicated `promotion` dashboard panel gated by the existing
invite switches (credits + invite reward + invite registration), and move
the invite card out of the revenue tab so 收益中心 is pure earnings/withdrawal.
- src/User/Center.php: register promotion panel; revenue no longer depends
on invite being on
- inc/helpers/user-center-renderers/profile-promotion.php: new panel body
hosting the existing [data-aksrt-invite] card
- profile-revenue.php: drop the invite section; aksrt-user-center.php: drop
unused show_invite_section context, add promotion to built-in tabs + view map
- repoint invite/promotion deep-link aliases from revenue to promotion across
tab-url builder, tab resolver, runtime tabAliases, urls.php, and the
revenue-JS enqueue gate
- sidebar-nav.php: add 推广中心 service entry; shell.css: entry icon color;
sidebar-creator.php: reword revenue card
- UserRuntime.php: allow promotion in configurable tabs
kate522