标签： WordPress
-
使用 SlyTranslate 翻译 WordPress 文章时，原有英文标签能够正常继承，刚创建的英文标签却意外遗漏。经过逐阶段检查，发现数据库中的 Polylang 翻译关系正确，但 W3 Total Cache 的不同缓存命名空间保留了不一致的数据。本文记录从 Redis 取证、故障复现，到采用单文件修复方案、增加标签完整性校验，以及生产部署和真实文章验证通过的全过程。
-
使用 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 实际变化场景尚待进一步验证的部分。
-
在排查 GA4 首页浏览次数异常偏高、用户互动时长过短的问题时，我从百度搜索结果发现大量 ?p=ID 形式的 WordPress 历史入口被 CDN 错误处理。进一步测试确认，EdgeOne 的 Query String 归一化规则会过滤 p 参数，使文章请求回源成首页并返回 200。修复 p、page_id 保护后，有效文章恢复 301，无效地址恢复 404；GA4 数据显示，过去 30 天 ?p= 相关访问高达 2479 次。
-
此前已经发现 W3 Total Cache 页面缓存长期很难看到超过 2 天的文件，但当时正在批量处理历史文章，不适合立即判断。等历史处理结束后，借这次 CPU 告警继续排查，最终发现联合预热 Sitemap 长期生成失败，根因是 Yoast SEO 生成 post-sitemap.xml 时触发 PHP 256M 内存耗尽并返回 HTTP 500。将 PHP-FPM memory_limit 提升到 512M 后，中英文 Sitemap 恢复 200，联合预热 Sitemap 也恢复自动更新。
-
一次 WordPress 服务器 CPU 接近 100% 的异常告警，引出了 EdgeOne 短时间内 2 万多次 L7 请求。通过分析缓存状态、客户端 IP 和 URL 分布，确认流量具有明显的分散特征。最终在 EdgeOne 个人版能力范围内，为 www 域名启用独立防护策略，将自适应频控调整为“适中”，并配合 JavaScript 挑战和流量防盗刷，降低异常自动化流量对源站的影响。