分类： WordPress
-
一次阿里云 ECS CPU 接近 100% 的告警，最终从 Nginx 499、PHP-FPM max_children、Slowlog、W3 Total Cache Object Cache 和 Redis 一路排查到 Page Cache 冷缓存。实测发现服务器仅有 1 vCPU，而 /page/9/ 在 Cold MISS 时 TTFB 高达 10.6 秒，缓存命中后仅约 0.016 秒。最终没有提高 PHP-FPM 并发、关闭 Redis 或开启缓存预热，而是将 W3TC Page Cache 最长生命周期从 1 小时延长到 12 小时，以降低历史页面反复动态生成带来的 CPU 压力。
-
在通过 EdgeOne 屏蔽异常 Sogou UA 流量、解决 WordPress 502 后，阿里云 ECS 仍然偶发 CPU 95%～100% 告警。进一步结合 PHP-FPM Slow Log、Nginx 请求日志和 W3 Total Cache 实测发现，大量带 Query String 的前台请求会导致 W3TC Disk: Enhanced 页面缓存无法复用，使请求重新进入 PHP-FPM，完整执行 Gutenberg、Polylang、Post Views Counter、Redis Object Cache 和数据库查询。正常 URL 第二次请求 TTFB 仅约 0.1 秒，而带参数 URL 每次仍需约 7～11 秒。最终决定不逐个封禁参数，也暂不升级服务器或修改 W3TC 内部逻辑，而是在 EdgeOne 与 Cloudflare CDN 层进行 Query String 缓存键和回源 URL 规范化，从根源减少动态参数造成的缓存穿透。
-
在 WordPress 历史文章迁移过程中，将原有流程图内容转换为 MerPress Mermaid 区块后，前台出现 Syntax error in text，并显示 Mermaid 11.9.0。最初将错误的 流程图 TD 修改为 flowchart TD 后问题仍未解决，最终发现关键在于节点文本写法。将 A[节点文本] 统一调整为 A[“节点文本”] 后，包含 test()、main()、go test() 以及中英文混合内容的流程图恢复正常渲染。本文记录完整排查过程，并总结适用于 WordPress 历史内容迁移的 Mermaid 节点编写与验收规则。
-
收到包含 8 个中文文章 URL 的内容整改清单后，我没有直接删除 WordPress 文章，而是通过 MU Plugin 保留文章发布状态和系列标题，同时让指定中文页面真实返回 HTTP 404，并限制 REST API、RSS 与 Sitemap 继续输出正文。随后结合 W3 Total Cache、EdgeOne、Cloudflare 和 Polylang 完成缓存排查，最终仅下线清单中的中文文章，对应英文译文继续正常访问。
-
本文整理了一套每天批量处理 20 篇 WordPress 历史文章的完整流程，包括 SyntaxHighlighter 向 Code Block Pro 迁移、代码语言核对、生产只读验证、中文摘要生成、英文覆盖翻译、有限重试和失败恢复。本次实操还修复了 Plaintext 行数校验过严，以及 Ctrl + S 被误判为 Markdown 列表的问题，最终完成整个批次，并形成可长期复用的操作规范。
-
在持续优化 WordPress 中文技术文章英文翻译流程后，我将相关定制代码、测试脚本、问题分析和生产验证记录整理到 GitHub 私有仓库 wordpress-ai-translation-pipeline。本文记录了仓库创建、本地目录改名、远程绑定、main 分支与标签推送、路径修正、敏感信息审计以及 .gitignore 完善过程。GitHub 的引入让翻译优化工作从临时排查转向可追踪、可回退、可长期维护的工程流程，也标志着本阶段翻译质量优化工作告一段落。
-
一份用于同步 Polylang 中英文标签的批处理脚本，长期存在 WordPress 后台标签总数与脚本读取结果不一致的问题。此前两次排查分别修复了 Polylang 翻译关系缓存残留和动态分页导致的数据集变化，但问题仍会复发。最终通过对比 WP-CLI 与直接 PHP 执行环境，确认根因是 get_terms() 命中了持久化的旧 WP_Term_Query 查询缓存。脚本在源标签查询中加入 ‘cache_results’ => false 后，终于从旧的 8915 个标签恢复为正确的 8928 个。本文记录完整排查过程，并总结多语言数据维护脚本在缓存、运行上下文、统计验证和幂等性方面的实践经验。
-
在完成 SlyTranslate 与智谱 GLM-5.2 的 WordPress 长文章整篇翻译定制后，英文正文虽然能够正常生成，但实际发布流程仍出现分类、标签、PublishPress Series、Series 部分编号和特色图片未正确迁移等问题。本文根据真实测试过程，记录如何将新英文译文由自动发布调整为草稿，利用 Polylang 将中文 Taxonomy 关系迁移到已建立的英文分类、标签和 Series，并让 PublishPress Series 在人工发布时自动生成顺序编号。同时还修复了 GLM 压缩保护 Token 前导零以及英文特色图片缺失的问题。最终，新英文草稿已经能够保留 Gutenberg 结构，并自动关联正确的分类、标签、Series 和特色图片。中文语言切换器及多域名 Object Cache 失效问题则留待后续单独处理。
-
本文记录了在 WordPress、Polylang 与 SlyTranslate 环境下，为 GLM 5.2 整篇翻译流程增加 Plaintext 智能判断的完整优化过程。通过结构占位、区块顺序校验、Code Block Pro 原样保护、最终正文精确写回及 SHA-256 校验，实现了自然语言 Plaintext 可翻译、URL 和代码保持不变，同时修复了 Gutenberg 编辑器中的无效区块提示。文章还记录了英文文章分类、系列与标签因多域名对象缓存未及时失效而未能在前台正确显示的问题。
-
在完成 SlyTranslate 与智谱 GLM 5.2 的整篇翻译定制后，我进一步申请并接入 DeepSeek API，通过本地脚本对 glm-5.2 与 deepseek-v4-pro 进行了相同内容、相同提示词下的标题、摘要和正文翻译测试。结果显示，DeepSeek V4 Pro 的响应速度明显更快，但在信息完整性、技术表达和 Gutenberg 段落衔接方面，并未表现出稳定优于 GLM 5.2 的质量优势。考虑到现有 GLM 5.2 定制插件已经包含代码区块占位、HTML 与 Gutenberg 结构保护、整篇翻译和内容还原等完整处理流程，当前没有必要再为 DeepSeek 重复投入开发。后续若继续追求更高翻译质量，将优先在本地测试 OpenAI，确认其是否具备足够明显的优势，再决定是否解决阿里云杭州服务器访问 OpenAI API 的网络问题。