2 Commits
Author SHA1 Message Date
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 03b0bc6cc1 3.2.44: 后台配色实时预览 + 全站代码块语言标注统一 #13
需求 A —— 主题设置里选「代码配色」时能当场看到效果:
- 新增 assets/css/highlight-admin.css:只负责预览区布局,不改代码块外观
- 新增 assets/js/highlight-admin.js:监听下拉框,删旧 link 再插新 link,
  回调里重新上色
- inc/theme-highlight.php:新增 yang_hl_admin_assets()/yang_hl_admin_preview_html()
- inc/theme-options.php:在配色下拉框后插入 type=info 的预览面板

几个关键取舍(都有实测依据):
- 切换配色必须真正删掉旧 <link>。20 套配色的规则是裸选择器
  (.hljs-keyword 之类),同场会互相压制,切换看起来像「没反应」。
- 预览复用前台同一份 CSS,另写一套必然与前台不一致。
- 不用 highlightElement(会在已上色元素上再套一层,颜色变脏),
  改为从 textContent 取原文重新 highlight。
- 实测 hljs 的 HTML 转义无损(392 字符逐字符可还原),所以不需要额外的
  data-raw 暂存;那是两份状态,不同步就是 bug 源头。已删该冗余。

需求 B —— 全站代码块语言标注统一(数据侧,不在本次 diff 里):
- 284 块 / 71 篇全部统一为 <pre lang="xxx">,清掉 Enlighter 私有标记与
  code 上的 language-* 类
- 关键发现:站内没有「完全无标注」的块(0 个),但有 87 块标注无效
  (text 47 / generic 28 / raw 8 / jsp 2 / latex 2)—— 问题不是没标,是标是假的
- 87 块逐块判定:bash 174、plaintext 45、yaml 13、ini 9、xml 8、python 8、
  javascript 7、php 6、json 5、java 5、ruby 2、sql 2
- 判定表优先级必须高于「沿用旧标注」:产品把 generic/raw/text 兜底成
  plaintext,而 plaintext 在白名单里,旧逻辑会走 keep 把判定表整批丢弃
  (第一版实测 87 条只有 4 条生效,且结果看起来是成功的)
- 同一篇文章里有 11 对块原文完全相同,str_replace 会全局替换导致整片标错;
  改为按文内序号 + 内容签名定位

验证:
- 后台预览 jsdom 测试 22/0,反向注入 6 组全部真红
- 语言/属性单测 44/0 与 24/0,语言反向 10/0
- 独立审计脚本(另一套扫描逻辑)全绿;反向 3/3 真红
  (去掉 lang / 改成 cobol / 塞回 enlighter 各自都能抓出来)
- 真实页面 4 篇:data-guess 全为 0,正文里已无「猜出来的」代码块
2026-10-26 11:37:42 +08:00