标签： WordPress
-
2026 年 8 月 6 日，我曾在 PHP 8.5 环境中排查 WordPress 插件兼容性问题，并向 PublishPress Series 官方 GitHub 仓库提交 Issue #1163，报告 SplObjectStorage::attach() 与 contains() 在 PHP 8.5 下产生 Deprecated 警告。升级至 PublishPress Series Free 3.1.3 后，我重新检查了这个问题：Issue 已由上游关闭，生产环境源码中的旧调用也已经全部替换为 offsetSet() 与 offsetExists()，实际运行测试得到 DEPRECATIONS: 0，确认旧问题已经解决。不过，这次升级又带来了一个新的 Gutenberg 保存异常：新发布的中文文章虽然仍然属于正确的系列，却不再自动获得 Series Part 编号，而对应 English 文章仍然正常。全站扫描最终发现 6 篇受影响中文文章。恢复正确编号后，全站缺失 Series Part 的文章重新归零。为了避免修改插件源码或降级版本，我增加了一个最小 MU Plugin，在 Gutenberg REST 保存完成后调用 PublishPress Series 自己的排序函数自动补齐编号。本文随后作为修复后的第一篇真实中文文章发布，并成功自动成为「WordPress 性能优…
-
今天继续整理 WordPress 生产站的站点健康状态。最初后台显示 6 个“推荐的改进”，包括未启用的插件、未启用的主题、陈旧的 SQL 服务器、公开可访问的调试日志、评论分页，以及固定链接中没有文章名。排查过程中删除了 5 个不再使用的旧主题和 12 个已经没有实际用途的插件，升级 Akismet，关闭 WordPress 调试日志，并结合当前页面缓存与 CDN 架构，最终决定关闭文章评论及 Pingback/Trackback，同时保留历史评论数据。处理完成后，站点健康推荐项由 6 个减少到 3 个；剩余项目则分别因为 Cloudflare 插件暂时保留、阿里云 RDS MySQL 5.7 暂时无法升级，以及现有固定链接结构不适合为消除提示而贸然修改，因此选择保持现状。
-
在持续处理 WordPress 历史文章摘要、旧代码格式、SyntaxHighlighter 短代码及中英文覆盖翻译之后，这一轮历史迁移终于正式收尾。最终 67 个固定批次、1281 篇历史文章全部完成，remaining=0、integrity=ok。为准备退役 SyntaxHighlighter Evolved，又重新同步并审计了 1438 篇中文已发布文章，最终只有 14 篇进入人工检查，真正需要迁移到 Code Pro 的文章不到 5 篇。审计工具、配置、测试和历史迁移状态也已完成 Git 收口，503 项测试通过。发布本文前，SyntaxHighlighter Evolved 已正式停用，插件文件暂时保留约 5 天，等待旧页面缓存自然退出后再彻底删除。
-
此前在测试 WordPress 的 EdgeOne 与 Cloudflare Query String 缓存归一化时，由于没有找到真实存在的日期归档分页，/YYYY/MM/DD/page/N/ 场景一直没有完成验证。随着 2026 年 8 月 15 日日期归档出现第 3 页，这次重新补测中文站与英文站。EdgeOne 中随机 Query String 直接命中已有缓存且正文完全一致；Cloudflare 中虽然原始 HTML SHA-256 每次不同，但最终确认差异仅来自 /cdn-cgi/l/email-protection 邮箱地址混淆。归一化该动态字段后，Clean 与 Dirty 四份 HTML 完全一致，最终确认两个 CDN 的日期归档分页 Query String 归一化均工作正常。
-
在一篇包含大量 Gutenberg 段落、引用、列表、图片和 90 个 Code Block Pro 区块的超长文章中，我继续验证 WordPress 中文到英文整篇 AI 翻译流程。排查过程中先后发现受保护标记过多、普通段落边界过度保护、Plaintext Code Block Pro 内容字段被误判为结构变化，以及空白 freeform 导致 PARAGRAPH_RUN 结构签名漂移等问题。通过引入普通段落区域、区分内容字段与结构配置、修正最终 Gutenberg 结构签名后，受保护标记降至 506 个，最终仍以一次完整 GLM-5.2 请求成功生成英文译文，并通过 Gutenberg 编辑器实际验证。
-
在 WordPress 后台使用 SlyTranslate + GLM-5.2 翻译技术文章时，一次看似普通的尾部 STRUCT Token 缺失，最终定位为两个 INLINE Token 为适应自然英文语序发生了合法换位。主校验允许这种变化，但 Tail Repair 仍要求完整 raw Token 序列保持原始前缀，导致安全的尾部结构修复被错误阻断。本文记录从 first_mismatch_index=814 定位真实差异、修正 Tail Repair 为 fixed Token 前缀判断、补充回归测试，到生产部署并验证同一文章最终翻译成功的完整过程。
-
本文记录 WordPress 历史文章批处理过程中，一篇文章在中文摘要生成阶段持续触发 GLM HTTP 400，并进一步确认错误码为 1301、属于内容安全过滤的完整处理过程。经过排除输入长度和普通网络波动后，没有为了迎合模型审核而修改历史正文，而是改由 ChatGPT 人工生成中文摘要、英文标题、摘要和完整译文，再通过扩展后的 mark-manual-completed 对 excerpt_failed 进行生产只读验收和人工完成确认。最终既保留了原始 excerpt_generation_failed 与 HTTP 400 evidence，又将 workflow 安全收敛到 completed，整批 20 篇全部完成。
-
这次访问 admin.shuijingwanwq.com 时，Firefox 突然出现 PR_END_OF_FILE_ERROR。排查发现服务器端 Nginx、SSL、WordPress 以及公网 443 端口均正常，真正异常的是 Clash Verge / Mihomo 分流链路：本应国内直连的域名未命中预期规则，最终落入 MATCH → Proxy 并连接超时。由于现有“国内直连、国外代理”规则此前长期正常运行，没有为单个域名增加强制 DIRECT，而是更新 GeoData 并重启 Mihomo 内核，随后后台恢复正常。本文完整记录从浏览器报错、Clash 日志定位、服务器与源站直连验证，到 GeoData 更新恢复的排查过程，并说明为什么目前更适合将根因判断为 GeoData 或 Mihomo 规则运行状态异常，而不是直接认定规则设计错误或 GeoData 文件损坏。
-
本文记录了一次 WordPress 历史文章英文覆盖翻译过程中遇到的 HTTP 400 内容安全拦截问题。排查最初从网络访问相关技术术语入手，但连续进行中文名称和中性表达改写后仍然失败。随后转向文章中的国家和地区流量统计内容，通过逐步概括相关表达并重新建立当前中文源基线，最终成功完成 GLM-5.2 英文覆盖翻译。文章同时总结了内容安全错误的定位思路、WordPress 图片 ALT 对翻译输入的影响，以及历史文章处理中优先采用等义改写而非直接删除内容的实践原则。
-
英文站从 www.shuijingwanwq.com/en/ 迁移至独立子域 en.shuijingwanwq.com 后，Google Search Console 出现大量“已抓取 – 尚未编入索引”页面。本文通过检查 Sitemap、301 重定向、canonical、实时网址测试及历史搜索表现，逐步排除常见技术 SEO 故障，并随机抽查 3 篇已由 GLM-5.2 重翻译且被 Google 再次抓取的文章，发现它们仍未进入索引。现有证据更支持英文站正处于迁移后的重新抓取、索引接管与质量重新评估阶段，后续将继续推进历史英文文章重翻译，并持续观察索引数量与搜索流量变化。