kate522/wordpress-theme-aksrt
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,915 Commits 1 Branch 0 Tags
35bb96e82f0debc09d079c5fd5a1666724fc8793
Commit Graph
7 Commits
Author SHA1 Message Date
kate522andClaude Opus 5 35bb96e82f refactor: rename the theme brand and every identifier from AKSRT to Jio 
Full-project rename. `git grep -i aksrt` is now empty apart from the
DBMigrator 3.3.0 changelog note that documents the rename itself.

Code identifiers
- PHP namespace AKSRT\ -> Jio\ (composer PSR-4 + 378 declarations)
- global constants AKSRT_* -> JIO_* (VERSION/DIR/URI, PAY_TYPE_*, CAPTCHA_*)
- procedural functions, hooks, options, meta keys, table names,
  cookies, query vars, ajax actions and nonces: aksrt_ -> jio_
- text domain aksrt -> jio; Theme Name -> Jio
- JS globals: aksrtData/aksrtAdminData/... -> jioData/jioAdminData/...,
  window.AKSRTCaptcha & friends -> window.JioCaptcha, Aksrt* -> Jio*
- Vue components Aks*.vue -> Jio*.vue (15 files renamed + imports)
- CSS classes/data-attrs/custom properties: aksrt- -> jio-
- REST namespace aksrt/v1 -> jio/v1 (incl. payment gateway callbacks)

Storage layer
- DB tables {prefix}aksrt_* -> {prefix}jio_*; SCHEMA_VERSION 3.2.0 -> 3.3.0
  so dbDelta creates the new names on install
- widget id_base aksrt_widget_* -> jio_widget_*
- uninstall.php drop list rebuilt from the actual migrator tables
  (dropped 3 stale entries, added the 17 missing ones)

Removed
- hardcoded https://api.aksrt.com/version.json default update endpoint;
  get_endpoint() now reads the 「更新端点」 setting and do_check() no-ops
  when it is empty

Files renamed: inc/helpers/aksrt-*.php -> jio-*.php (54),
assets/admin/src/components/form/Aks*.vue -> Jio*.vue (15).
Build artifacts regenerated: assets/css/build, assets/js/runtime,
assets/admin/build.

Verified: audit-psr4-paths errors=0, audit-admin-contracts errors=0
(warnings=56, unchanged baseline), 813/813 widget-system tests,
44/44 phpunit, php -l clean across all PHP.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-11-01 20:05:04 +08:00
kate522 5201f2ab6f fix(ban): hide scrollbars entirely in ban modals 
申诉弹窗等内容区的细滚动条（mini-scrollbar 悬停显现的 3px 滚动条）也不予保留：
三个禁封弹窗（禁封/解封 max-vh7、申诉 max-vh5、禁封记录 max-vh5）的滚动容器
统一改用 no-scrollbar（scrollbar-width:none + ::-webkit-scrollbar{display:none}），
滚动能力保留但任何状态下都不显示滚动条。契约测试锁定：ban 相关helper 不得
再出现 mini-scrollbar。
 2026-09-22 19:53:03 +08:00
kate522 7a3f5d7c34 fix(ban): appeal textarea squash and nested tone on the user center entry 
- fix(ban): 申诉弹窗「请填写申诉说明」填写框被压成 0px——bindAppealForm
  对全部 textarea 执行 bindAutoHeight，而 grow 对无 maxHeight 属性的元素
  走 else 分支写入 height:0；参考主题申诉说明框为 rows=3 自然高度。
  现 autoHeight 仅对显式声明 autoHeight/maxHeight 的文本框生效
- fix(ban): 申诉弹窗与禁封记录弹窗滚动容器对齐参考主题 max-vh5（50vh，
  内层滚动、外层对话框不滚动）；mini-scrollbar 提供细滚动条（悬停才显示，
  无常驻侧边滚动栏）；禁封弹窗保持 max-vh7 不变
- fix(ban): 用户中心封禁元信息按钮两层颜色嵌套——外层 but 与内层 badg
  同时带 c-red/c-yellow；现外层 but 为默认按钮色，颜色仅由内层 badg
  承载（1:1 参考主题 zib_get_user_ban_info_link 结构）
- test: 契约测试锁定三处修复（说明框自然高度、max-vh5、外层 but 不重复着色）
 2026-09-22 19:46:35 +08:00
kate522 a4af024f32 feat(ban): align ban prompts with the reference theme modals and block page 
对照参考主题(Zibll)修正四项偏差，申诉链路从页面整体迁移至弹窗：

- feat(ban): 新增三个 1:1 复刻弹窗（REST /user-ban/{info,appeal,log}-modal）：
  查看禁封状态（多彩头 c-gray + 信息行 + 申诉按钮）、禁封申诉（edit-header
  gavel/c-blue + 信息框 + 资料项 data[key] 输入 + 审核中态 + 禁止申诉态）、
  禁封记录（多彩头 c-yellow + 计数 + 逐条卡片）；user-ban.js 增加
  data-aksrt-ban-info/appeal/log 委托与 admin-ajax 申诉提交
- feat(ban): 禁封/解封弹窗的「当前用户已有N次禁封记录」静态文案改为可点击
  黄链（N>1），打开禁封记录弹窗；解封视图信息行改复用统一数据源
- refactor(ban): 治理展示态收敛至 Restriction::state_badges()（封号=c-red
  违规已封号 / 小黑屋=c-yellow 小黑屋禁封中 / 禁言=c-gray 禁言中，颜色与
  字段统一管理）+ get_ban_info()（状态/起止时间/原因/说明/申诉权限，
  三弹窗与禁封页共用）
- feat(ban): 登录行为对齐参考主题——移除登录期拦截（enforce_login_ban）
  与 complete_login 禁封闸门，封号用户可正常登录；新增 template_redirect
  前台禁封页（1:1 zib_user_ban_restrict_login/zib_die_page：红盒提示 +
  信息行 + 申诉权限 + 退出登录/申诉按钮，模板 templates/parts/user/ban-block.php）
- feat(profile): 公开主页禁封状态从资料卡下方提示框改为占据身份行元信息位
  的 badg 徽章（参考主题 author_header_identity 语义）；用户中心元信息改为
  but 按钮（徽章+箭头）打开查看禁封状态弹窗；评论拒绝态链接同源
- refactor: 移除申诉页面模板（page-ban-appeal.php）及其资产/注册/入队、
  get_profile_notice/profile_notice 链、state_labels/state_notices/
  login_ban_message、UserRuntime 的 public_notice/ban_notice_text 死配置、
  report_settings 死键、无消费方的 aksrt_ban_appeal_status 端点
- feat(ban): BanAppeal::ajax_submit 兼容弹窗 data[key] 表单结构
  （逐项清洗入库，申诉说明取 data['申诉说明']，旧平铺字段保持兼容）
- chore: 重新构建 public.css/public.min.css（三个新弹窗几何与头部样式）
- test: 契约测试重写（徽章元信息位、三弹窗与记录链接、禁封页、允许登录 +
  前台拦截、死代码移除断言），全量 362 项通过
 2026-09-22 19:14:02 +08:00
kate522 f9bc0f69c4 fix(ban): align user center ban notice with adjacent meta info 
用户中心页头治理提示与相邻元信息（用户名/邮箱/城市）排版不一致：
- 高度不一致：原实现为 badg 胶囊 + 箭头作为 <a> 的内联兄弟节点，箭头
  游离在胶囊之外且按基线对齐，整行高度被 pill 撑高；
- 字号不一致：badg-sm 的 0.8em 使提示文字小于相邻项的 13px；
- 箭头位置：参考主题 zib_get_user_ban_info_link 的箭头位于按钮内部。

现复用 uc-header__meta-item（inline-flex 居中、12px 图标、13px 字号），
与相邻元信息完全同构：状态图标 + 状态文案（c-red/c-yellow）+ 内部箭头；
链接默认色经作用域规则回归行内墨色。契约测试锁定新结构，361 项全通过。
 2026-09-22 18:13:58 +08:00
kate522 7f520803ff feat(ban): mirror reference theme ban/restriction prompt surface 
修复公开主页禁封提示框为空的问题，并对齐参考主题(Zibll)全部前台禁封提示入口：
- fix(profile): 资料卡下方治理提示框渲染为空——模板读取的 tone/message 键与
  数据层实际输出的 state/label/text 契约不匹配；现按禁封类型展示
  「违规已封号/小黑屋禁封中/禁言中」+ 可配置说明文案
- feat(ban): 用户中心页头展示治理状态徽章 + 查看详情入口，直达禁封申诉页
  （参考主题 user_page_header_desc / zib_get_user_ban_info_link）
- feat(ban): 评论拒绝态区分禁封/小黑屋/禁言，附状态徽章与申诉链接
  （参考主题 zib_get_user_ban_nocan_info，原为笼统的无权限文案）
- feat(ban): 禁封申诉页补全状态信息卡（状态/开始时间/结束时间/原因/说明/
  申诉权限），对齐 zib_get_ban_info_modal；此前仅有「禁封原因」一行且无入口
- feat(ban): 昵称旁禁封徽章 + 头像禁封角标（覆盖 VIP 位，参考主题
  user_name_badge / user_avatar_badge 钩子语义），main.css 与入队的
  main.min.css 同步新增角标样式
- fix(ban): 举报入口对已封禁/小黑屋目标隐藏（评论、文章下拉、封面菜单三处，
  对齐 zib_get_report_link 排除语义；禁言为轻量限制不隐藏）
- refactor(ban): 治理展示态收敛为单一数据源 Restriction::get_display_state()
  + state_labels()，资料卡/用户中心/评论拒绝态/昵称徽章共用
- feat(ban): 小黑屋用户开放申诉（对齐参考主题 zib_user_is_ban 双类型语义），
  禁封站内信附加申诉页链接
- test: report-ban 契约测试 +3（展示态单一数据源、提示面入口矩阵、举报排除），
  45 个测试文件全部通过
 2026-09-22 13:28:52 +08:00
kate522 7597972eea feat(user-ban): frontend ban modal replaces the backend restrictions tab 
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.
 2026-09-20 18:42:53 +08:00