标签： MU Plugin
-
使用 SlyTranslate + GLM-5.2 翻译 WordPress Gutenberg 文章时，遇到 A paragraph run did not contain a top-level paragraph. 错误。排查后确认，问题来自自定义 Paragraph Run parser 只能识别裸 ，无法兼容模型偶发返回的 或 。最终通过最小范围修改，在保留原有段落 merge/split 与 Gutenberg 结构保护能力的前提下完成修复，并通过自动测试和生产真实文章验证。
-
在 WordPress 多语言生产环境中，修改自定义 taxonomy series 的系列描述后，W3 Total Cache 再次出现整站 Page Cache 全量失效。通过 Page Cache 快照、Full Flush Tracer 与 Nginx 后台日志，最终确认 series 的 edited_term 进入现有兼容插件的 fallback，并调用 w3tc_flush_posts()。本文记录如何仅将 series 加入允许最终一致性的 taxonomy，完成 Git 提交、生产部署与连续两次真实编辑验证，同时区分这一问题与此前已经存在的 Object Cache / Redis 旧对象问题。
-
W3 Total Cache 的 Page Cache 明明设置了 4 天生命周期，实际缓存却长期活不过一天。经过对缓存文件、*_old ctime、WordPress Hook 和调用栈的持续追踪，最终确认了两条提前触发全量缓存失效的真实路径：Polylang 标签与翻译关系更新触发 edited_term / delete_term，以及 Yoast SEO 的 wpseo_detect_default_seo_data 每日 Cron 通过 WPSEO_Utils::clear_cache() 调用 w3tc_flush_posts()。本文记录两条根因的定位、独立 MU Plugin 修复、真实双语文章发布流程验证，以及修复后 Page Cache 首次存活超过 24 小时的结果，同时保留 Yoast option 实际变化场景尚待进一步验证的部分。
-
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 动态首页性能问题的完整排查与优化过程。绕过 EdgeOne、Cloudflare 和 W3 Total Cache 后，发现中文首页真实动态生成时间接近 19 秒。通过 PHP-FPM slowlog、MySQL EXPLAIN 与实际 SQL 基准测试，最终定位到 Post Views Counter 的热门文章排行榜查询：完整 wp_posts.* 参与 SUM、GROUP BY 和 ORDER BY，导致 MySQL 5.7 创建磁盘临时表。通过 MU Plugin 将查询改造成“轻量排名 + Top N 完整文章加载”的两阶段结构后，中文动态首页降至约 0.83～0.89 秒，英文首页稳定在约 0.87～0.96 秒，同时保持排行榜顺序、浏览量和 Polylang 语言过滤正确。
-
将 WordPress 英文站从 /en/ 迁移到独立子域名后，我排查了 Polylang 多域名、独立后台 Host、W3 Total Cache Page Cache 与 Redis Object Cache 之间的缓存失效问题。最终确认并修复了英文文章更新后语言首页 Page Cache 未完整失效，以及 posts 对象缓存跨 Host 失效的问题，并将方案整理为 MIT 许可的独立 MU Plugin。真实后台 Update 验证后，Origin 层已能够正确返回最新内容，剩余问题进一步定位到 EdgeOne、Cloudflare 等 CDN 层。
-
收到包含 8 个中文文章 URL 的内容整改清单后，我没有直接删除 WordPress 文章，而是通过 MU Plugin 保留文章发布状态和系列标题，同时让指定中文页面真实返回 HTTP 404，并限制 REST API、RSS 与 Sitemap 继续输出正文。随后结合 W3 Total Cache、EdgeOne、Cloudflare 和 Polylang 完成缓存排查，最终仅下线清单中的中文文章，对应英文译文继续正常访问。
-
在排查 SlyTranslate、GLM-5.2、Polylang、PublishPress Series 与 W3 Total Cache 之间的兼容问题时，传统的“生成命令—手动执行—复制结果—继续分析”方式逐渐变得低效，长时间会话也开始造成浏览器卡顿。本文结合真实的 WordPress 生产环境修复过程，记录如何将源码读取、Hook 定位、最小 Diff、PHP 测试、SHA256 校验、文件备份、原子部署、现有数据修复和回滚验证交给 Codex 执行，同时由人工控制修改范围、架构方向和生产风险。实践表明，Codex 适合承担已经明确的代码分析与部署任务，但是否修改某个插件、是否接受新方案、是否存在功能重复，仍需要人工判断。
-
本文记录在 SlyTranslate + 智谱 GLM-5.2 一次性全文翻译方案基础上，继续优化 WordPress 技术文章英文质量的完整过程。通过关闭随机采样、修复标题与摘要未接收附加提示词的问题，并将标题、摘要、正文及目标语言规则内置到 MU Plugin，减少了后台重复配置。随后使用智谱官方 API 对深度思考与 GLM-4.7-FlashX 进行 A/B 测试，结果显示深度思考成本明显增加但质量提升不稳定，FlashX 虽然更快但准确性较低。最终确定以 GLM-5.2、关闭深度思考、关闭随机采样和内置多字段提示词作为当前稳定方案。