标签： WordPress
-
收到包含 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 列表的问题，最终完成整个批次，并形成可长期复用的操作规范。
-
在重新评估技术博客广告变现方案后，我停用了原有的 AdSense 手动广告位，仅保留全站基础代码，并正式启用自动广告。本文完整记录了旧广告缓存排查、源站与 EdgeOne 验证、自动广告格式配置、代码块兼容性测试，以及将页内广告最小间距从 200px 调整为 530px 的过程。最终采用较积极的广告密度，同时关闭意向驱动广告，保留页内广告、底部锚定广告和低间隔穿插广告，以测试自动广告能否在不插入代码块、不过度破坏阅读体验的前提下，提高技术博客的广告变现效率。
-
本文记录了将 WordPress 历史文章中的 Gutenberg SyntaxHighlighter 代码块统一转换为 Code Block Pro，并复用既有中文摘要生成与英文覆盖翻译流程的完整实践。通过生产环境只读扫描、固定批次、人工转换、结构验收和状态恢复，第一批 20 篇文章最终全部完成中文摘要写入与英文覆盖翻译。过程中也暴露出批次执行中的网络超时、状态恢复边界和过度设计问题，并据此确定了后续历史文章的标准化处理方案：不同旧格式只负责识别与转换，转换完成后统一进入现有 Gutenberg + Code Block Pro 执行流程，不再重复建设摘要和翻译管线。
-
本文记录了使用 GLM 4.7、GLM 5.2 与 SlyTranslate，安全补全 42 组 WordPress 中英文历史文章摘要的完整过程。流程通过固定候选清单、写入前备份、内容哈希、Polylang 双向校验、状态持久化、断点恢复与自动重试，应对 GLM 超时、REST 连接中断及 SlyTranslate HTTP 500 等真实故障，最终实现 42/42 完成、待处理 0、异常状态 0。
-
在使用 AI 批量补全 WordPress 历史文章摘要之前，我先建立了一套只读格式审计管线，用于受控导出文章、识别 Classic Editor、Gutenberg、SyntaxHighlighter 和 Code Block Pro 等历史格式，并进行风险分类与候选筛选。项目已完成 3 条、20 条和 100 条生产样本验证，143 个自动化测试全部通过，并以中英文文档形式公开到 GitHub。当前阶段不调用 AI，也不写回 WordPress，重点是先明确格式边界、数据安全和失败保护，为后续长期运行的摘要补全流程建立可靠基础。
-
从历史文章摘要为空、文章列表重复显示 Post Views 以及 Yoast SEO 元描述不够准确的问题出发，我逐步梳理了 WordPress AI 翻译工程的下一阶段计划。后续将先盘点经典编辑器、SyntaxHighlighter Evolved、Gutenberg 和 Code Block Pro 等历史内容格式，再使用 GLM-4.7 小规模测试并批量补齐中文 post_excerpt，随后重新覆盖翻译历史英文文章。整个流程将通过 Codex 与 GitHub 管理，并持续评估不同模型的翻译质量、稳定性、速度、API 成本及部署可行性。
-
随着“WP 博客多语言化实操”系列文章增至 38 篇，我将其中以 AI 模型评测、翻译质量优化、代码保护和自动化流程为主的内容，拆分到新系列“WordPress AI 翻译工程实战”。本次共迁移 16 篇中文文章及对应的 16 篇英文文章，并确认通过文章列表按发布时间依次快速编辑后，PublishPress Series 会自动从 1 开始连续排序，无需手动调整。迁移完成后，还清理了 www 与 en 域名下的 W3 Total Cache 页面缓存和对象缓存。
-
在排查 SlyTranslate、GLM-5.2、Polylang、PublishPress Series 与 W3 Total Cache 之间的兼容问题时，传统的“生成命令—手动执行—复制结果—继续分析”方式逐渐变得低效，长时间会话也开始造成浏览器卡顿。本文结合真实的 WordPress 生产环境修复过程，记录如何将源码读取、Hook 定位、最小 Diff、PHP 测试、SHA256 校验、文件备份、原子部署、现有数据修复和回滚验证交给 Codex 执行，同时由人工控制修改范围、架构方向和生产风险。实践表明，Codex 适合承担已经明确的代码分析与部署任务，但是否修改某个插件、是否接受新方案、是否存在功能重复，仍需要人工判断。
-
在 WordPress、Polylang、W3 Total Cache、Redis 与多域名架构下，后台通过 admin 子域名发布文章或清理缓存后，www 与 en 前台仍可能读取旧的页面缓存和对象缓存。本文通过对比源站、CDN、WP_Query 与 Redis 缓存结果，定位到 W3TC 按 Host 隔离对象缓存的问题，并利用缓存组版本机制，配合自定义 MU Plugin，实现语言首页、文章查询缓存及 WPCode 配置缓存的跨域同步失效，同时保留中英文站必要的缓存隔离。