在 3.2.34 的 CDN 加速功能上补三件事。
当前设计是「CDN 地址留空即关闭」。改成显式开关:
预制内容(用户指定,13 个后缀):
.avif .css .gif .jpeg .jpg .js .json .mp3 .mp4 .pdf .png .svg .webp
放「跟安全相关、本来就绝不该走 CDN」的后缀,例如 .php 一类。
.php
预制项硬编码在主题代码里,运行时无条件参与匹配;输入框里放的只有用户额外补充的规则,两者叠加。
理由:
std
kratos_option()
输入框的说明文字里会列出预制了什么,用户看得见。
预制项统一用带点写法(.avif 而不是 avif)。
.avif
avif
原因:规则引擎里单个纯字母词会同时按「扩展名」与「路径子串」匹配(这是为了救 uploads 那条规则)。avif 作子串会命中 /wp-content/uploads/avif-optimized/a.jpg 这类路径;带点之后子串是 .avif,不会误伤。
uploads
/wp-content/uploads/avif-optimized/a.jpg
.jpg
.css
*
提交 adcf80a,已推送 main。更新包与 readme 已发布到主题更新通道,update.json 的 version 已落到 3.2.35。
adcf80a
update.json
3.2.35
建单时写的是「预制项硬编码在主题里 + 运行时叠加」。实现前经确认改成了:
预制内容写进白名单/黑名单输入框的默认值(std),用户可以直接改,保存后以用户改的为准,主题不再覆盖。
这个差别很重要,也相应改了实现与验证口径:判据不再是「源码里有这 13 个字符串」,而是「这 13 项真的被预填进了 textarea 的可见内容里」。前者在「硬编码进函数但没进 std」时也是绿的,而那恰好是被否决的方案。
1. 「启用 CDN 加速」复选框
should_rewrite
rewrite_html
buffer_start
yang_cdn_active()
2. 勾了但地址留空 → 整个保存被拒绝
保存回调返回旧值即可(WP 自己会把旧值写库,结果与没保存等价),并 add_settings_error 提示必须填地址。
add_settings_error
这里有一条硬红线:回调里绝不能 update_option() 把旧值写回去 —— 那会在 sanitize_option_kratos 过滤器上递归触发自己,吃爆内存(3.2.11 的事故,报错还会落在区块解析器上,看那个报错会完全找错方向)。
update_option()
sanitize_option_kratos
顺带补了一个进页面提示(admin_init):老站点若正卡在「勾着但地址空」的历史状态,一进后台就能看到「功能当前没有生效」。
admin_init
3. 预制白名单 / 黑名单
白名单 13 项,逐项逐序照需求:
黑名单 13 项(安全相关):
.php .php3 .php4 .php5 .phtml .phar .env .sql .bak .log .ini .sh .htaccess
黑名单优先于白名单不变 —— 所以哪怕白名单写成 *,这些后缀也照样不走 CDN。.env 里是数据库密码、.sql 是整库备份,一旦被推到第三方节点缓存上等于公开,源站权限拦不住。
.env
.sql
每一项前面都带点(.jpg 而非 jpg):不带点的单词会同时按「扩展名」和「路径子串」匹配,avif 会命中 /uploads/avif-optimized/a.jpg 这种路径。
jpg
/uploads/avif-optimized/a.jpg
4. 升级不丢加速
开关的默认值按「CDN 地址是否非空」推算:
主机名校验。parse_url 对主机极其宽容,实测:
parse_url
parse_url('https://not a url at all') → host = 'not a url at all' parse_url('https://exa mple.com/x') → host = 'exa mple.com' parse_url('https://cdn..example.com') → host = 'cdn..example.com'
只判 empty($host) 全挡不住。后果不是「少加速一点」,而是全站静态资源一起被拼成畸形地址、站点直接没有样式,而用户在后台看到的只是一个「填了地址」的框。已加主机字符集 / 首尾点 / 连续点 / 子路径空白校验。
empty($host)
_cdn335_logic.php
_cdn335_falsify.php
_admin335_cdn_check.py
_admin335_falsify.py
_pkgcheck335.py
_pkgcheck335_falsify.py
反向验证里每条注入都必须红在对应的那一条判据上,不是「随便红了就算」。这一轮从中抓出并修掉了 6 处假绿 / 空转判据,其中两处值得一提:
checked
"checked"
<div id="section-cdn_enable"
<input>
input.checked
update_option
kratos_yang.zip
4ae6eb6c...
php -l
cdn.yangyq.net
功能本身可用了。以下两点是按合理判断定的,如果和你想的不一样请说一声:
.env / .sql / .bak / .log / .ini / .sh / .htaccess
用户确认功能没问题,关单。
最终形态见上一条评论。有一条流程上的补充:按约定没有解包覆盖服务器主题目录,线上跑的是 3.2.34,3.2.35 通过主题更新通道下发,需在 WP 后台「外观 → 主题」点升级才会生效。
No dependencies set.
The note is not visible to the blocked user.
需求
在 3.2.34 的 CDN 加速功能上补三件事。
1. 加一个「启用 CDN 加速」复选框
当前设计是「CDN 地址留空即关闭」。改成显式开关:
2. 白名单给一份预制项(写死在主题里)
预制内容(用户指定,13 个后缀):
3. 黑名单也给一份预制项
放「跟安全相关、本来就绝不该走 CDN」的后缀,例如
.php一类。4. 生效条件(用户原话整理)
设计决定(需确认是否同意)
预制项硬编码在主题代码里,运行时无条件参与匹配;输入框里放的只有用户额外补充的规则,两者叠加。
理由:
std在运行时完全不起作用 —— Options Framework 的std只服务「后台预填」和「恢复默认」,kratos_option()取值时压根不看它。所以把预制项写进std,老站点(已保存过配置的)取到的仍然是空值,预制等于不存在。输入框的说明文字里会列出预制了什么,用户看得见。
写法确认
预制项统一用带点写法(
.avif而不是avif)。原因:规则引擎里单个纯字母词会同时按「扩展名」与「路径子串」匹配(这是为了救
uploads那条规则)。avif作子串会命中/wp-content/uploads/avif-optimized/a.jpg这类路径;带点之后子串是.avif,不会误伤。验收标准
.jpg.css等 13 类资源走 CDN。.php等不在预制的资源仍保持原地址。*,预制黑名单仍然挡住它。收尾:已完成并发布 v3.2.35
提交
adcf80a,已推送 main。更新包与 readme 已发布到主题更新通道,update.json的 version 已落到3.2.35。一、最终实现与建单时的一处差异(已确认后调整)
建单时写的是「预制项硬编码在主题里 + 运行时叠加」。实现前经确认改成了:
这个差别很重要,也相应改了实现与验证口径:判据不再是「源码里有这 13 个字符串」,而是「这 13 项真的被预填进了 textarea 的可见内容里」。前者在「硬编码进函数但没进 std」时也是绿的,而那恰好是被否决的方案。
二、三件事怎么落的
1. 「启用 CDN 加速」复选框
should_rewrite/rewrite_html/buffer_start都过yang_cdn_active()),前台一个字节都不改,不是「少改一点」。2. 勾了但地址留空 → 整个保存被拒绝
保存回调返回旧值即可(WP 自己会把旧值写库,结果与没保存等价),并
add_settings_error提示必须填地址。这里有一条硬红线:回调里绝不能
update_option()把旧值写回去 —— 那会在sanitize_option_kratos过滤器上递归触发自己,吃爆内存(3.2.11 的事故,报错还会落在区块解析器上,看那个报错会完全找错方向)。顺带补了一个进页面提示(
admin_init):老站点若正卡在「勾着但地址空」的历史状态,一进后台就能看到「功能当前没有生效」。3. 预制白名单 / 黑名单
白名单 13 项,逐项逐序照需求:
黑名单 13 项(安全相关):
黑名单优先于白名单不变 —— 所以哪怕白名单写成
*,这些后缀也照样不走 CDN。.env里是数据库密码、.sql是整库备份,一旦被推到第三方节点缓存上等于公开,源站权限拦不住。每一项前面都带点(
.jpg而非jpg):不带点的单词会同时按「扩展名」和「路径子串」匹配,avif会命中/uploads/avif-optimized/a.jpg这种路径。4. 升级不丢加速
开关的默认值按「CDN 地址是否非空」推算:
三、过程中顺带修掉的一个真 bug
主机名校验。
parse_url对主机极其宽容,实测:只判
empty($host)全挡不住。后果不是「少加速一点」,而是全站静态资源一起被拼成畸形地址、站点直接没有样式,而用户在后台看到的只是一个「填了地址」的框。已加主机字符集 / 首尾点 / 连续点 / 子路径空白校验。四、验证结果
_cdn335_logic.php_cdn335_falsify.php_admin335_cdn_check.py_admin335_falsify.py_pkgcheck335.py_pkgcheck335_falsify.py反向验证里每条注入都必须红在对应的那一条判据上,不是「随便红了就算」。这一轮从中抓出并修掉了 6 处假绿 / 空转判据,其中两处值得一提:
checked判据是假绿:原来在 HTML 串里搜"checked",但那一段只到<div id="section-cdn_enable"就截断了,属性在几十个字符之后的<input>上,恒真。已改成量真实的input.checked。update_option」时,下一个函数上方的注释里正好写着「这里绝对不能调 update_option()」,不剥注释就会误判。已改成先按大括号配平取精确块、再剥注释。五、部署情况
kratos_yang.zip的 md5 与本地一致(4ae6eb6c...),下载回来重新解压校验通过。php -l通过。cdn.yangyq.net)。需要更新时请在 WP 后台的「外观 → 主题」里点升级。六、待你确认
功能本身可用了。以下两点是按合理判断定的,如果和你想的不一样请说一声:
.php系,还放了.env / .sql / .bak / .log / .ini / .sh / .htaccess。这些不在「改了站点会坏」的硬性排除里,但一旦被推到 CDN 就等于公开。用户确认功能没问题,关单。
最终形态见上一条评论。有一条流程上的补充:按约定没有解包覆盖服务器主题目录,线上跑的是 3.2.34,3.2.35 通过主题更新通道下发,需在 WP 后台「外观 → 主题」点升级才会生效。