laoyang/wordpress-kratos-yang
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
95 Commits 1 Branch 0 Tags
main
Commit Graph
17 Commits
Author SHA1 Message Date
laoyang 1a31e412b0 写作增强：翻译服务商选了谁才显示谁对应的账号输入框 #26 
之前四个密钥框（百度 APPID/密钥、有道应用 ID/密钥）无论选哪家服务商
都全摆在设置页上，四组输入框里永远有三组用不上。

改动：
- inc/theme-options.php：新增 $yang_prov_class() 闭包，统一生成字段
  的 class。服务端就按「当前已保存的服务商」把 yq-cond-hide 打好，
  首帧不闪。分组标记 yang-prov / yang-prov-<key> 写在每个字段的
  'class' 上，是**唯一的分组声明处**，JS 不再抄服务商清单。
  原本一个 shared 的 info 块拆成三块，每家一句自己的说明。
- inc/options-framework/js/options-custom.js：重写
  yq_toggle_writing_slug_fields()。两层条件（总开关 + 服务商归属）
  必须在同一函数内合成一个结果再 toggleClass —— toggleClass 的
  force 是绝对赋值，拆成两个函数各 toggle 一次的话结果只取决于
  注册顺序。change 事件同时监听 #w_on_slug 与 #w_provider。
- style.css：3.2.57 -> 3.2.58

两处刻意避开的老坑：
- 用 class + display:none !important，不用 jQuery show()/hide()，
  后者会把行内 display 写成 block，回退 3.2.28 的 flow-root 修复。
- 隐藏不 disabled 输入框，密钥字段是「留空=不修改」语义，disabled
  不随表单提交，会把已保存的密钥冲掉。
 2026-10-27 21:40:00 +08:00
laoyang 0a5486e195 3.2.57 新增「写作增强」：发布时自动生成别名/标签/分类/摘要 #25 
需求（工单 #25）：写文章时自动生成别名（翻译）、自动生成标签、
自动选择分类、自动生成摘要，问主题能不能做、是否必须用插件。
结论：主题自己就能做，不依赖任何插件。

新增 inc/theme-writing.php（四个独立引擎 + 设置读写 + 密钥处理）：

- 触发点：transition_post_status，且要求
  new_status === publish && old_status !== publish
  ⇒ 只在「第一次点发布」时动手，自动保存不触发，已发布的文章一概不碰。
- 幂等锁 _yang_writing_done：同一篇只做一次，避免反复覆写。

四道「不覆盖」守卫（用户逐条确认的决策）：
- 摘要：只在 post_excerpt 为空时才写。
- 分类：只在文章还挂默认分类（未分类）时才动。
- 别名：只在「空」或「不是纯 ASCII」时才生成。判据不是"空"而是
  "不是纯 ASCII" —— 中文标题下 WP 生成的是 %e4%bf%a1... 这种编码串，
  它非空但不可用。已有英文别名的 966 篇一概不动（别名=URL，改了
  就是成批 404）。
- 标签：wp_set_post_tags(..., true) 追加，绝不删除手工标签。

修一个真实产品 bug：3.2.56 及以前 apply() 里写的是
list($suggest, $_) = yang_writing_make_tags(...)，$new 被整个丢掉；
接着又拿 $suggest 去 get_term_by 二次分类 —— 而 $suggest 里每个词
都来自词典、必然全部命中 ⇒「新建」分支永远进不去 ⇒ 这条功能在真实
发布流程里一次都没生效过。改为 list($exist_hits, $new_cands)，
两段分别复核后合并。

标签两级策略（新博客也能用）：先匹配已有标签池，匹配不到才新建，
每篇新增数量受 w_tag_new_limit 约束（默认 3，设 0 = 永不新建）。

中文分词（服务器无 scws/jieba）：先按虚词与标点切短语，再在短语
内部取 2~6 字 n-gram。不切句直接取窗口会产出「星等换算与赤」
这类跨词碎片，且字面上"出现 ≥2 次"能通过所有频次闸门 —— 这是
n-gram 的固有缺陷，只能靠切分规避，调阈值无效。
虚词表统一由 yang_writing_seps() 提供（闸门④ 复用同一函数）。

翻译：默认 MyMemory（免注册），可选百度/有道。任何失败都返回空串
跳过该项，绝不阻塞发布。

密钥：存独立选项 yang_writing_secrets，不进 kratos；password 类型 +
std 空串；页面只显示末 4 位；留空提交 = 不修改。

设置页：新增「写作增强」独立 heading 标签页，四个开关默认全关
（升级不改变现有行为）。framework 里 'requires' 这个键根本没被读取，
条件显示改用 options-custom.js 显式逻辑；info 类型不生成 .section
包裹层，补一条 .section-info 规则才能藏住服务商申请说明。

验证（发布前）：
- 写作端到端 71 条、后台渲染 21 条、密钥路径 9 条，合计 101 条全过
- 反证 22 组（W1~W16 端到端 / A1~A6 后台）× R1~R14 发布包注入，
  全部让失败数从 0 增加
- 测试自身不污染：每节差分回滚 + 总闸门，标签库稳定 703 / 967 篇
- 发布走 theme-update/，主题目录仍是 3.2.56，未被覆盖
 2026-10-27 16:05:43 +08:00
laoyang 9da5e9e2df 后台代码配色预览不上色 + donate.png 404 一并修复 #14 
Bug 1：后台预览的示例代码没有高亮。三层原因叠在一起。
  ① yang_hl_admin_assets() 从未 enqueue hljs 本体，而 yang_hl_enqueue()
     开头 `if (is_admin() || is_feed()) return;` 挡掉后台
     ⇒ 后台 window.hljs 恒 undefined ⇒ recolor() 静默 return。
     卡片的边框/顶栏是 data-kind 驱动的纯 CSS，切深浅配色时照样会变，
     看起来像"预览在工作，只是代码没颜色"。
  ② init() 里 applyTheme(sel.value, true) 传 noRecolor=true ⇒ 首屏永不上色，
     只有手动拨下拉框才有颜色（正是报障的"下面的示例代码并没有高亮"）。
  ③ recolor() 缺 hljs 时只是 return，控制台零输出 ⇒ 极难定位。

  修法：
  - inc/theme-highlight.php：后台 enqueue hljs 本体，并作为 preview 脚本的
    硬依赖（不靠 WP 的加载顺序碰运气）；前台 yang_hl_enqueue() 仍挡后台。
  - assets/js/highlight-admin.js：删掉 noRecolor 这个"能否跳过核心动作"的
    参数（调用方迟早会用错）；首屏与切换走同一条路径。
  - 缺 hljs / 上色失败时 console.error 出声，并给 code 打
    data-unhighlighted、给卡片打 data-hl-failed；CSS 画橙色虚线框 +
    顶栏文字，让失败在画面上也看得出来，不再是一坨单色字。
  - 配色样式加载主路径改为 setTimeout(once, 125)，link.onload 只作加速。
    onload 三情形不触发：样式表已在缓存、link 移除后重插、jsdom 无网络。

Bug 2：后台设置页报 donate.png 404。
  库里 g_donate_alipay / g_donate_wechat 存的是旧主题目录名
  `.../themes/kratos-master/assets/img/donate.png` 的绝对 URL。前台走
  yang_option_image() 有 yang_image_url_is_stale() 兜底，后台
  class-options-media-uploader.php 直接 echo $value，绕过检测。
  修在渲染处：预览图与"浏览文件"href 走检测后的 $preview（带
  function_exists 兜底），输入框仍显示库里的原值，不偷偷改用户数据。

版本 3.2.44 → 3.2.45。
 2026-10-26 12:20:33 +08:00
laoyang adcf80af62 3.2.35 CDN 加速加启用开关 + 预制白/黑名单，勾了不填地址拒绝保存 #4 
「启用 CDN 加速」复选框放在 CDN 段最前。不勾时下面填什么都不产生作用，
前台与没装该功能完全一致（三个入口 should_rewrite / rewrite_html /
buffer_start 都过 yang_cdn_active()）。

预制名单写进输入框的 std，用户可直接增删改，保存后以用户内容为准：
  白名单 13 项（.avif .css .gif .jpeg .jpg .js .json .mp3 .mp4 .pdf
  .png .svg .webp）；黑名单 13 项安全后缀（.php* .phtml .phar .env
  .sql .bak .log .ini .sh .htaccess）。同时 yang_cdn_defaults() 给同一份
  —— std 在运行时完全不生效，两处不同源就会出现「后台 13 项、前端 0 项」。

勾了开关但地址留空：保存被整单拒绝（validate_options 返回旧值），并
add_settings_error 提示。回调里绝不 update_option（会递归触发
sanitize_option_kratos，3.2.11 吃爆内存的路径）。另加 admin_init 进页面
提示，救「勾着但地址空」的老站点。

开关默认值按「地址是否非空」推算，老站点升级不丢加速；没填过地址的站点
默认不勾，避免第一次点保存就被「必须填地址」拦住。

顺带修掉 parse_url 对主机过于宽容导致的畸形地址（https://not a url at all
曾被当合法，会把全站静态资源拼成畸形地址）。

验证：_cdn335_logic.php 116/0 · _cdn335_falsify.php 22/0 ·
_admin335_cdn_check.py 74/0 · _admin335_falsify.py 23/0 ·
_pkgcheck335.py 117/0 · _pkgcheck335_falsify.py 27/0 ·
_cdn334_logic.php 92/0（向后兼容）· _cdn334_falsify.php 21/0
 2026-10-25 17:10:06 +08:00
laoyang e47bf37966 3.2.33 后台「主题设置」两栏顶边对齐 (#2) 
用户反馈：「左侧标签栏和右侧设置框两个也不一样高，有一个高度差，看着
很别扭。」经测量纠正：不是高度不一样，是**顶边**位置不同 —— 左栏白
卡片 top=53、右栏白卡片 top=63，差 10px，左边高、右边低。

根因不在主题里，在 WordPress 后台自己的样式：
  #wpbody-content .metabox-holder { padding-top: 10px }
这条是给「一路往下竖排的 metabox」留顶部间距用的。3.2.24 把标签列
float 到左边、变成两栏并排之后，这 10px 就没人跟它配对了：左栏
(h2.nav-tab-wrapper) 不带这层 padding，右栏 (#optionsframework-metabox)
还带着，于是右栏被压低 10px。

修法：两栏并排时把这 10px 清零。
  #optionsframework-wrap > #optionsframework-metabox { padding-top: 0 }
只在 @media (min-width: 960px) 里清 —— 窄屏仍是标签横排在上一路往下，
那 10px 是该留的间距，不动。

没有采用「给左栏补 10px」的凑齐改法：那样左栏卡片内部会多出一段看不
见的空白，标签整体下移，问题只是从「两栏错位」变成「左栏内部偏空」。

底边仍不齐（左栏 467 固定、右栏 366~1276 随标签变），这是另一个问题，
本轮按用户界定不做，等确认后另开一单。

验证：
- _geo333_top.py        18/0（三档宽屏顶边差 0px；逐标签切 11 次顶边不变；
                        窄屏 700px 仍保留那 10px）
- _geo333_top_falsify.py 7/0（删规则/写成10px/补左栏padding/挪出媒体查询/
                        额外 margin/等价重写 0→0px，六种注入全部红对地方）
- _pkgcheck333.py       77/0 · _pkgcheck333_falsify.py 10/0
                        （C5 抓出真盲点：'float: left' in css 会命中别处，
                         判据改为锚在左栏块内部）
- 回归全绿：_admin330_tab_check 88/0 · _admin328_check 13/0 · _guard330 63/0
            _toc330_logic 101/0 · _test_toc 53/0 · _geo330_rail 73/0
            _geo331_inline 23/0，及对应六组 falsify 全部变红且红对地方
- 公网核验：md5 319d098f2fa5c5fb2764f25b8d55936c 本地/下载一致；
            包内 Version=3.2.33；padding-top:0 出现 1 次且在 960 媒体查询内；
            readme 24 条版本标题、历史 23 条全保留、ul/li/b/code 全配平
 2026-10-25 15:36:55 +08:00
laoyang 4a2d62b1aa 3.2.31 目录「正文内显示」与「浮动显示」拆成两个独立开关（#1） 
原来「目录位置」是一个三选一下拉：正文中间 / 页面左侧 / 页面右侧，
等于把「放进正文」和「浮在页边」当成互斥的一件事 —— 想同时在正文
开头放一份、又在边上浮一份，做不到。

改成两个独立勾选，各自带子选项：

  · 在正文中显示 → 正文中的对齐（靠左 / 靠右）+ 自动插入位置
  · 浮动显示     → 浮动方向（页面左侧 / 页面右侧）

两个都勾就同时出现两份，只勾一个就只出现一种。四种组合都在后台
联动里逐个验证过（探针 70/0）。

新增能力「正文内靠左 / 靠右」是本单的主要新需求。实现上两个要点：

  1. 必须给正文目录一个宽度上限（max-width: min(100%, 28em)）。
     块级盒子默认撑满正文栏，此时 margin:auto 没有剩余空间可分配，
     「靠左/靠右」会是一个属性正确、画面纹丝不动的空操作。
  2. 用 data-align 属性把方向带下去，CSS 只需两条规则，
     不随方向数量膨胀。属性在 yang_toc_slot_html() 里输出。

语义收窄：手写 [TOC] 以前会让整份自动处理全停（连带 rail=false），
现在只手管「正文那一份」—— 手写位置优先，浮动仍由 float 开关独立
决定。这样「精确定位正文位置」和「全站边上都有目录」可以并存。

顺手修掉一处默认值错配：checkbox 用 !empty() 判断会把「键不存在」
和「键明确为空」混成一件事，导致新装站点后台框显示勾上、页面却
不出目录。改用 array_key_exists() 区分的三态判断。

老配置不迁移：3.2.30 的 toc_place 直接作废，不做兼容。
默认 inline=1 / float=0，升级后页面与升级前一致。

重构：把内容过滤器拆成 yang_toc_apply()（纯执行层）+ 运行时壳，
使设置组合能在单进程单测里逐个喂进去（PHP 无法重置函数 static）。

验证
  逻辑 101/0 · 逻辑反向 15/15
  旧回归 53/0
  静态契约 58/0 · 反向 11/11
  后台几何+交互 70/0 · 反向 11/11
  侧栏几何 73/0 · 反向 8/8
  正文对齐几何 23/0 · 反向 5/5（含阴性对照）
  包内容契约 59/0 · 反向 9/9

正文对齐的几何探针量到真实的 Δleft = 348px（靠右比靠左），
而不是只断言 data-align 字符串存在。
 2026-10-25 13:37:26 +08:00
laoyang 6f51d50a58 3.2.30: 文章目录进后台（新增「自动目录」标签页）—— 位置/插入点/默认展开可配，手写 [TOC] 永远优先 
后台「主题设置」新增第 5 个标签页「自动目录」，7 个选项：
  目录位置   正文中间 / 页面左侧（浮动）/ 页面右侧（浮动）
  添加方式   手动（只认 [TOC]）/ 自动
  自动插入位置  文章开头 / 第一个 H1、H2 之前 / 文章结尾
  默认状态   默认显示 / 默认隐藏
  另外：目录标题、收录层级（H1~H4）、是否显示序号

设计要点：
- 插入方式拆成 toc_mode(manual/auto) x toc_anchor(start/first/end) 两个正交
  字段，不合成一个四值下拉：侧栏模式下插入位置毫无意义，合并会产生歧义。
- 手写 [TOC] 绝对优先：yang_toc_plan() 里 $has_marker 最先返回，inline_at
  ='marker' 且 rail=false —— 否则同一篇会出现两份目录，老文章升级后突然多
  出一个目录。这条是刻意守住的。
- 纯函数 + 薄壳分层：normalize_settings / plan / inject / build_list 全部不查库，
  单进程可喂几十种组合；settings() 只负责读库 + 调纯函数 + static 缓存。
- <details open> 是唯一可靠的「默认收起」手段：展开态不接受 CSS 覆盖，只能
  由 open 属性决定，所以隐藏时必须不输出该属性。
- 侧栏收起态必须 translateX(±100%) 完全移出视口：只做 opacity 会让透明面板
  留在原位吃掉正文点击（探针 elementFromPoint 才抓得到）。
- yang_toc_rail_ready() 开关：侧栏在 wp_footer 输出，那时正文可能没走
  the_content（缓存插件/OEmbed），标题没 id ⇒ 侧栏链接全跳不动却看起来正常。
  宁可不出侧栏。
- 后台联动隐藏「插入位置」不用 jQuery show()/hide()：会把 .section 的行内
  display 写成 block，悄悄回退 3.2.28 的 display:flow-root BFC 修复。改用
  class + display:none!important。

验证（全部在本轮重跑）：
  _test_toc.php       53/0   旧 TOC 行为回归
  _toc330_logic.php   88/0   逻辑判据
  _toc330_falsify     13/13  注入全变红且红对地方
  _geo330_rail.js     73/0   侧栏真实几何（左/右 x 展开/收起 x 宽窄屏）
  _geo330_falsify     8/8
  _guard330.php       46/0   后台控件与运行时默认值双向一致
  _guard330_falsify   8/8
  _admin330_tab_check 36/0   新标签页几何 + 联动 + 载入态
  _admin330_falsify   8/8
  _admin328_check     13/0   3.2.28 布局回归

发布：只发 zip + readme + update.json 到 theme-update/，不动服务器主题目录，
用户在 WP 后台自行升级（沿用 3.2.24 起的策略）。
 2026-10-25 12:18:52 +08:00
laoyang 420434aacf 3.2.28: 修后台设置页第一个配置项后面的大块空白（.section 建独立 BFC，不再被左侧浮动标签列的 clear:both 拉长到标签列等高；真实渲染实测 405px→93px） 2026-10-25 10:13:44 +08:00
laoyang 92ffced7cf 3.2.26: 评论布局重排（姓名/时间垂直居中于头像、正文全宽下移 10px，锚点黄底不再压作者徽章）；引导线与子块留 8px 空隙并与缩进同源（--yq-my-indent）；修深层缩进晚一层生效的存量 bug；后台设置页标题 margin 收编（项间空白 42→22px） 2026-10-24 23:58:55 +08:00
laoyang fb12d58067 3.2.25: 评论框改为所见即所得编辑器（B/I/颜色/表情可视化+序列化白名单+纯文本粘贴）；后台资源 enqueue 版本号改跟 THEME_VERSION（修设置页重排被浏览器缓存挡住的问题） 2026-10-24 22:38:10 +08:00
laoyang fd27b4d218 3.2.24: 评论富文本工具条（B/I/颜色/表情移入）+ kses 放行 span+style + 后台设置页标签左列竖排重排 2026-10-24 21:59:06 +08:00
laoyang 4beb09307c 3.2.17: 修复「保存设置时静默清空未提交的字段」 
现象
在主题设置里填了「附加日期」（例如 10-23），过一阵发现它变回空了，
于是当天的哀悼效果不再出现，而其他设置都好好的，看不出哪里坏了。

根因
inc/options-framework/includes/class-options-framework-admin.php 的
validate_options() 里，对每个选项无条件取 $input[$id] 去 sanitize：

    $clean[$id] = apply_filters('of_sanitize_'.$type, $input[$id], $option);

一旦某次提交里没有这个键（分组没渲染、字段被条件隐藏、表单中途出错只
提交了一半……），$input[$id] 是未定义索引 ⇒ null ⇒ sanitize_text_field()
返回空串 ⇒ 把用户存了很久的配置写成空。而且"清成空串"和"用户主动清空"
在库里完全一样，事后无法区分，只表现为"我明明填过，怎么没了"。

实测证据（线上 PHP 8.5.12，同一套用例）
  修复前：3 通过 / 2 失败，失败项同时伴随
          PHP Warning: Undefined array key "g_rip_extra" ... line 252
  修复后：5 通过 / 0 失败

改法
- 循环外先取一次 get_option('kratos') 作 $saved_options（不在循环里查库）
- 提交了（array_key_exists($id,$input)）才 sanitize
- 没提交则沿用 $saved_options 里的旧值；旧值也没有就不写这个键，
  让运行时的默认值继续生效
- checkbox / multicheck 保持原语义：这两类"没提交"确实等于"没勾"，
  沿用旧值会导致开关关不掉。用 $is_toggle 单独判定，与"沿用旧值"互斥

为什么这个改动值得单独发一版
它不是界面问题，是**数据被静默改写**。凡是这种"用户没动、值却变了"的
缺陷，都会让人怀疑数据不可靠；而且每次后台保存都可能再触发一次。

验证
- 线上 _test_keep_old_value.php：5/5（修复前 3/5，用例 2 精确复现空串）
- 本地 _static_317.php：8/8，第 4 组自带注入（改成老写法必须变红）
- 全量流水线 verify_all.sh：rc=0
- 线上浏览器 _live315.py：纪念日分支 33/33、非纪念日分支 27/27
  （判据改为「由配置侧独立算 expect_show，再与页面渲染对比」，
   不再无条件断言"必须有灰度"，也不再拿页面自身当预期值）
 2026-10-23 23:18:51 +08:00
laoyang 704a9346e1 3.2.12 紧急修复：点「测试邮件」引发无限递归、内存耗尽 
3.2.11 引入的事故。线上表现：
  Allowed memory size of 268435456 bytes exhausted
  in .../wp-includes/class-wp-block-parser.php on line 91
前台首页、后台登录页都正常，只有点那个按钮才炸。

根因不在区块解析器 —— 那只是递归链最后执行到的一行，看它会完全跑偏。

validate_options() 是 register_setting() 注册的 sanitize_callback，
WP 把它挂在 `sanitize_option_kratos` 过滤器上（wp-includes/option.php:3073）。
3.2.11 为了让"刚改的 SMTP 配置立刻生效"，在这个回调里调了
update_option('kratos', $clean)。而 update_option() 内部**会再跑一遍**
同名过滤器 ⇒ 又调回 validate_options ⇒ 再 update_option ⇒ 无限递归。
每层都在复制 $clean 派生的大数组，直到吃满 256M。

本地实测确认递归存在：回调被调用 3 次、嵌套深度 2。

改法：不写库，改用一次性覆盖层。
- 分支里把 $clean 放进 $GLOBALS['__yang_options_override']
- kratos_option() 优先读它，取不到再读库
- 效果等价（点测试用的就是刚填的值），但不触发任何过滤器，不可能递归
- 覆盖层是本请求内的全局，不落库、不跨请求残留

assertions: run_tests 104 → 110
- 分支里**没有** update_option（这条是红线，直接对应本次事故）
- 分支里有覆盖层
- 覆盖层真生效：kratos_option 优先返回新值
- 覆盖层未命中的键仍读库（不能把别的配置一起抹掉）
- 撤掉覆盖层回到库值（不跨请求残留）
- 桩与产品代码一致：直接读 autoload.php 确认它也认覆盖层
  （桩比产品温和是这次漏检的根源之一 —— 桩里 update_option 不挂
   sanitize 过滤器，所以注入递归 bug 后 harness 根本不崩）

顺带修了两个测试基础设施问题：
1. wp_stub.php 的 kratos_option 与真实实现语义不一致。已同步，
   并加断言防止两边再次漂移（否则"测的是桩、不是产品代码"）。
2. falsify 的 rebuild() 没把被 file_get_contents 读的 autoload.php
   复制进副本 ⇒ 新断言读不到文件 ⇒ 基线假红。

falsify 24 → 25：注入「分支里调 update_option」能抓住（靠静态红线，
不靠跑崩）、注入「去掉覆盖层」能抓住、注入「退回裸 wp_mail」能抓住。

全量 14 组全绿；run_tests 110 / run_tests2 154 / falsify 25。
 2026-10-23 18:49:06 +08:00
laoyang 9a053169e9 3.2.11 后台「测试邮件」改走主题模板，并修发信早于落库 
两个问题叠在一起，都不报错，只是「测了等于没测」：

1. 按钮发的是纯文本
   validate_options() 里 isset($_POST['sendmail']) 那个分支只有一句裸
   wp_mail()，正文是「恭喜您 SMTP 邮件服务配置成功！」。于是点测试收到的
   东西和真实评论通知（HTML 模板）完全不同，没法用它验收版式。
   主题里 yang_mail_send_test() 本来就是干这件事的，但全仓库零调用点 ——
   注释写着「后台测试按钮走这条」，实际上从没接上线。

2. 发信发生在配置落库之前
   validate_options() 是 register_setting 的回调，返回值之后才由 WP
   写进数据库。在分支里直接发信，主题配 PHPMailer 时读 kratos_option()
   拿到的还是上一次保存的主机/账号/密码。刚改完 SMTP 密码点测试，
   测的是旧密码，表现成「明明填对了却发不出去」。

改法：
- 分支里先 update_option('kratos', $clean) 再调 yang_send_test_mail()
- yang_send_test_mail() 优先调主题的 yang_mail_send_test()；
  主题被换掉时退回原来的纯文本，不能因此白屏
- send_mail_notice() 从「一律发送完成」改成三态：WP_Error / wp_mail
  返回 false / 成功，前两者用 error 样式。原来密码错了也显示成功，
  用户会去邮箱里干等。

assertions: run_tests 95 → 104 条（新增 2k 组 8 条 + 1 条）
- sendmail 分支确实调用主题发信函数、确实先落库
- 落库位置在发信位置之前（判顺序，不判有没有）
- 分支里没有裸 wp_mail
- 发信函数对主题缺失做了兜底
- 提示语分三态，两类失败都用 error 样式

falsify 22 → 24 条：
- 注入「先发信后落库」⇒ 变红（这条一开始是假绿：判据比的是注释里
  那两个词谁先出现，注释里 update_option 和函数名都在，恒真。
  改成先剥注释再比代码里的位置）
- 注入「退回裸 wp_mail」⇒ 变红

顺带修了 falsify 的一个基础设施坑：options-framework 那批文件在工作区
是 CRLF，锚点里写 \n 对多行内容恒不匹配，报的是「命中 0 次」，
很像锚点选错了。inject() 现在先试原样、不中再把 \n 换 \r\n 重试一次。

全量 12 组 / 506 条断言全绿。
 2026-10-23 18:28:53 +08:00
laoyang 37c52948c4 版本号 3.2.5 -> 3.2.6（统一邮件出口 + 邮件模板 + 纪念日自动哀悼 + 去掉广告位） 
评论邮件重复的根因是发信源不止一个，分两层处理：一层管「谁发」，一层管「发几封」。
只做前者的话邮件照样重复，只是都从同一个 SMTP 出去。

邮件治理（新增 inc/theme-mail.php）
- phpmailer_init 优先级 9999 接管通道，保证主题配置优先于其它 SMTP 插件；
  接管前先重置可能被别的插件设过的字段，避免残留半套配置。
- From 强制等于 SMTP 登录账号。QQ / 163 会以「发件人不符」拒收。
- wp_mail 优先级 99 统一 From 与 Content-Type；调用方自带的 From 与
  Content-Type 被剥离后重建，自定义 header 保留。
- wp_mail 优先级 100 做短期去重：同一收件人 + 同主题 + 同正文，90 秒内只发一次。
  用 transient 是因为评论通知跨请求（wpDiscuz 走 AJAX、审核通知走后台请求），
  静态变量跨不过去。90 秒足够宽（一次提交引发的通知都在同一秒）也足够窄
  （手动重发通常隔几分钟，不该被吞）。
- 被去重的那次把 to 置空并由 pre_wp_mail 返回 true，而不是 return null：
  返回 null 会改变 wp_mail 返回值语义，有的插件据此判定失败并重试，反而更多封。
- 用 filter 关掉核心的 notify_postauthor / notify_moderator，不改进数据库里的
  comments_notify / moderation_notify。改用户设置属于越权，而且用户下次进后台
  一勾又回来了；filter 是可逆的。只拦通知，不影响评论审核流程。
- 线上站点 m_smtp=1 但 m_host 为空时判定为「未就绪」并完全放手。只勾开关不填
  主机时若强行接管，所有邮件会静默失败，比回退到 mail() 更糟。

邮件模板（新增 inc/theme-mail-template.php）
- 表格布局 + 全内联样式：Outlook 2007-2019 用 Word 引擎，不认 flex / grid；
  Gmail 会剥掉 <head> 里的 style 块（含 media query）。
- 不用外部图片、不用 CSS 变量、不用 ::before。按钮的 padding 放在 td 上，
  因为 Outlook 忽略 a 的 padding。
- 宽度用混合写法：HTML 属性 width=600 给 Outlook，CSS 的
  width:100% + max-width:600px 让手机窄屏自动收窄。只写死 600px 会让手机横向滚动。
- badge 背景用预算的实色而非 rgba。Outlook 不支持 rgba，会当成非法值丢掉，
  半透明背景变成全透明，badge 直接消失。
- 主色下沿那条 3px 深色带必须 height 同时写成 HTML 属性和 CSS，
  否则 Outlook 把它撑成一行文字高，比例就毁了。
- 用 WCAG 相对亮度判断主色深浅来决定叠在上面的文字用白还是深色。
  简单取平均会把 #00ff00 判成中等亮度（人眼对绿最敏感、蓝最不敏感）。
- 次要文字统一调到 #5f6b78。原来的浅灰在白底上只有 1.84:1，看着"高级"但读不出来；
  现在最低 4.62:1，全部过 AA。

theme-smtp.php
- 删掉 comment_notify / comment_approved 两个钩子及其硬编码模板。这两个钩子与
  wpDiscuz 的 notifyCommentSubscribers 完全重复，是重复收信的直接来源。

纪念日自动哀悼（新增 inc/theme-mourning.php）
- 法定纪念日三个默认勾选：09-03 抗战胜利纪念日、09-30 烈士纪念日、
  12-13 南京大屠杀死难者国家公祭日。依据是 2014 年全国人大常委会两次决定，
  已在代码注释里记下来源。
- 民间通行做法（05-12、09-18 等）默认不勾，由用户自己决定。替用户做价值判断不合适。
- 一次性全国哀悼日（2020-04-04 等）支持 YYYY-MM-DD 写法，只在当年生效。
  不能当周年循环，否则明年 4 月 4 日又自动变黑白。
- 按站点时区判断（current_time），不按服务器时区。服务器在 UTC 时会晚 8 小时生效。
- 只挂 wp_head 而不限定 is_home()：老代码限定首页，详情页不黑白，那是 bug。
- 打印时取消灰度，否则打印出来是灰的。
- 保留旧的 g_rip 手动常开开关。不能因为升级把原本黑白中的站点变回彩色。

options-framework
- 补 multicheck 的渲染分支与 of_sanitize_multicheck。框架原来只在保存侧处理了
  这个类型，没有渲染分支，所以这个类型此前根本不可用。
- 值存成 array(键 => 1|0) 而不是「勾选了的键组成的列表」：列表无法区分
  「用户明确全部取消」和「从未配置」，会导致取消勾选后静默回退到默认值。
- 读取侧用 array_key_exists 判断是否保存过，而不是判断值是否为空。
- 配套补上 of-multicheck 样式，没有样式时 9 个选项会挤成一行流水文字。

去掉广告配置
- 删除主题选项里的广告配置段，以及 single.php 里上下两处广告位输出。

验证
- 全主题 68 个 PHP 文件语法检查通过。
- 行为测试 82 条、multicheck 闭环 25 条、邮件几何 15 条、设计审计 23 条。
- 反向验证 16 个注入 bug 全部被断言抓住（去重失效、不写标记、to 未清空、
  From 未剥离、亮度算法退化、时区改用 date()、全不勾回退默认等）。
- 邮件最低文字对比度 4.62:1；320px 视口下卡片自动收窄到 296px 不溢出。
 2026-10-23 13:55:23 +08:00
laoyang eaabc7717f 把自定义样式从主题目录搬到主题选项，升级不再丢 
原来主题里有个 custom/ 目录（custom.css / custom.js / custom.php），
是给用户随手加样式的入口。问题是它位于主题目录内，而 WordPress 升级
主题的做法是把整个主题目录删掉再解压（class-theme-upgrader.php 里
clear_destination = true，随后 delete_old_theme() 递归删除），
所以每次升级这些文件都会丢。custom.php 还会被 require，
等于在主题里留了一个执行任意 PHP 的口子。

改成后台选项：
- 主题选项新增「自定义代码」组，含自定义 CSS / 自定义 JS 两个输入框
- 内容存在数据库的 kratos 选项里，与主题文件解耦，升级、重装都不影响
- 分别在主题样式和主题脚本之后加载，优先级最高

为此新增了 code 字段类型，没有复用 textarea：textarea 的 sanitizer
走 wp_kses()，CSS 的子选择器 > 和 JS 的 < 会被当成 HTML 标签剥掉，
样式会静默失效。code 类型只去掉 PHP 标签、打断 </style> 和 </script>，
其余原样保留。渲染时也不走公共的 stripslashes —— options.php 已经
wp_unslash 过，再剥一层会把 CSS 的 \f101、JS 的 \n 啃坏。

自定义 CSS 的默认值就是原来 custom.css 的内容，逐字节一致（354 字节），
所以升级瞬间站点外观没有任何变化。清空输入框保存即可彻底去掉。

验证：真实 WP 7.1.3 / PHP 8.5.12 环境 20 条断言全过（含 DB 往返、
子选择器 / 反斜杠保真、危险内容过滤），生产选项指纹前后一致；
反向注入「默认值改空」能立刻被抓到。
 2026-10-23 10:35:56 +08:00
laoyang a826b26bee 从gitee代码库中初始化项目。 2022-01-07 11:15:42 +08:00