标签： Page Cache
-
在 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 实际变化场景尚待进一步验证的部分。
-
在将 WordPress 英文站从 /en/ 迁移到独立子域名后，我发现部分新发布的英文译文虽然已经与中文文章建立 Polylang 关联，但中文详情页仍然缺少语言切换器和 hreflang。排查确认，问题来自 W3 Total Cache Redis Object Cache 在多 Host 环境下缓存了旧的 post_translations_relationships 数据，随后 Page Cache 又继续保存错误 HTML。本文记录了 WP-CLI、真实 HTTP Runtime、精确 Object Cache 删除和 Page Cache 验证过程，并说明为什么最终暂时不引入复杂的跨 Host Redis 清理逻辑，而选择保持现有 TTL，让该低优先级问题自然恢复。
-
将 WordPress 英文站从 /en/ 迁移到独立子域名后，我排查了 Polylang 多域名、独立后台 Host、W3 Total Cache Page Cache 与 Redis Object Cache 之间的缓存失效问题。最终确认并修复了英文文章更新后语言首页 Page Cache 未完整失效，以及 posts 对象缓存跨 Host 失效的问题，并将方案整理为 MIT 许可的独立 MU Plugin。真实后台 Update 验证后，Origin 层已能够正确返回最新内容，剩余问题进一步定位到 EdgeOne、Cloudflare 等 CDN 层。
-
本文记录了一次 WordPress 英文文章页面横向滚动条的完整排查过程。在 Polylang 多域名、Twenty Twenty-Five 区块主题、W3 Total Cache Page Cache 与 W3TC Object Cache（Redis 后端）的组合下，页头搜索框的 `min-width: 250px` 导致英文语言切换器被挤出父级 Flex 容器。将其修改为 `min-width: 0` 后，英文页面却仍然输出旧 CSS。进一步对比 Cloudflare、源站响应、数据库原始内容与 `get_post()` 返回值后确认：数据库中的 `wp_global_styles` 已经更新，但 W3TC Object Cache 仍在返回旧的文章对象。最终通过 `clean_post_cache()` 精确清理对应对象缓存后，新 CSS 正常生效，横向滚动条消失。本文同时结合此前 Polylang 英文子域名迁移经历，总结了 W3TC Page Cache 多域名识别、旧 Polylang option 和旧全局样式对象缓存等问题的排查思路。