laoyang
6f50533e8e
3.2.10 修复邮件页脚显示字面量 ©
邮件正文会被 yang_mail_escape_for_wpdiscuz() 无差别地把 & 加倍，用来抵消
wpDiscuz 在过滤器之后又做的那一次 html_entity_decode —— 不加倍的话，访客
评论里的 <script> 会在解码时还原成活标签。
但这个替换是全局的，连模板骨架里手写的字符实体也一起被加倍。于是
© 变成 &copy;，能否正常显示完全取决于后面那次解码有没有执行：
走了解码 → 还原成实体 → 浏览器显示 ©；没走 → 只解析一次 → 收件人看到
字面量 ©。用户遇到的正是后者。
修法不是在转义函数上开口子（那会重新打开脚本注入口），而是让骨架不再
依赖实体：版权符号与 3px 分隔条的不换行空格一律输出 UTF-8 字符本身。
整封邮件本就声明 charset=UTF-8，这样无论被解码几次都不会变形。
用户数据（站名、标题、URL）仍走 esc_html/esc_url —— 那类 & 的转义是
必要的，加倍后能由那次解码还原，属于应当保留的一类。
assertions: run_tests 89 → 95 条（新增 1e 组 6 条）
- 骨架里零手写实体（0 次 decode 也不露原文）
- 经 0~5 次 html_entity_decode 始终是 ©、从不露实体原文
- URL/站名里的 & 仍被转义（不能把 esc_html 一起废掉）
- 分隔条是 U+00A0 裸字符，过过滤器后仍是裸字符
falsify 20 → 22 条，两处注入（页脚退回实体、分隔条退回实体）都能抓住。
全量流水线 14 组 / 465 条断言全绿。
2026-10-23 17:29:37 +08:00
..
2026-10-23 13:55:23 +08:00
2026-10-23 13:55:23 +08:00
2026-10-23 12:55:41 +08:00
2026-10-23 12:55:41 +08:00
2026-10-23 12:55:41 +08:00
2026-10-23 12:55:41 +08:00
2026-10-23 17:29:37 +08:00
2026-10-23 14:43:47 +08:00
2026-10-23 14:43:47 +08:00
2026-10-23 14:43:47 +08:00
2022-01-07 11:15:42 +08:00
2026-10-23 14:43:47 +08:00
2026-10-23 13:55:23 +08:00
2026-10-23 12:55:41 +08:00
2026-10-23 13:55:23 +08:00
2026-10-23 12:55:41 +08:00