分类： 建站系统
-
本文整理了一套每天批量处理 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 的网络问题。
-
本文记录在 SlyTranslate + 智谱 GLM-5.2 一次性全文翻译方案基础上，继续优化 WordPress 技术文章英文质量的完整过程。通过关闭随机采样、修复标题与摘要未接收附加提示词的问题，并将标题、摘要、正文及目标语言规则内置到 MU Plugin，减少了后台重复配置。随后使用智谱官方 API 对深度思考与 GLM-4.7-FlashX 进行 A/B 测试，结果显示深度思考成本明显增加但质量提升不稳定，FlashX 虽然更快但准确性较低。最终确定以 GLM-5.2、关闭深度思考、关闭随机采样和内置多字段提示词作为当前稳定方案。
-
本文记录在 WordPress、Polylang 与 SlyTranslate 环境中，使用智谱 GLM-5.2 对包含大量 Gutenberg 区块和 Code Block Pro 代码块的技术长文进行正文单次翻译的完整排查过程。最初后台返回 invalid_translation_runaway_output，但执行轨迹显示正文其实只调用模型一次，并已成功保存英文文章。真正原因是自定义翻译完成后，SlyTranslate 原始 REST 回调又继续执行。通过将接管入口从 rest_request_before_callbacks 调整为 rest_dispatch_request，最终避免重复翻译，同时验证了 54 个代码块逐字一致、Gutenberg 结构完整、正文无中文漏译，翻译质量也明显优于原生分块流程。
-
在 WordPress、Polylang、W3 Total Cache、Redis 与多域名架构下，后台通过 admin 子域名发布文章或清理缓存后，www 与 en 前台仍可能读取旧的页面缓存和对象缓存。本文通过对比源站、CDN、WP_Query 与 Redis 缓存结果，定位到 W3TC 按 Host 隔离对象缓存的问题，并利用缓存组版本机制，配合自定义 MU Plugin，实现语言首页、文章查询缓存及 WPCode 配置缓存的跨域同步失效，同时保留中英文站必要的缓存隔离。
-
近期博客先后启用了英文子域名、独立后台域名、多 CDN、W3 Total Cache Page Cache 与 Redis Object Cache，并针对 Polylang、W3TC、TMS Extensions for Polylang、SlyTranslate 等兼容问题增加了多项调整。随着缓存失效、语言识别和插件升级风险逐渐显现，本文暂停继续增加补丁，对现有多域名架构进行一次阶段性复盘，明确哪些组件继续保留、哪些第三方插件源码修改需要撤销，以及后续应按照“改动盘点、恢复 W3TC 缓存闭环、实现多语言一键清理、最后接入 EdgeOne 与 Cloudflare 自动刷新”的顺序推进，使整套方案重新变得可控、可维护并具备复用价值。