标签： W3 Total Cache
-
在 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 自动刷新”的顺序推进，使整套方案重新变得可控、可维护并具备复用价值。
-
为解决 WordPress 后台经过 EdgeOne 时出现的核心升级 524 超时问题，本文将后台迁移至独立的 admin.shuijingwanwq.com 子域名，并通过 DNS Only 直连源站。整个方案包含独立 Nginx 虚拟主机、ECC HTTPS 证书、W3 Total Cache 多域名兼容补丁、WordPress MU 插件 URL 重写、前台后台入口统一跳转，以及 admin-ajax.php、admin-post.php 和文章密码提交接口的保留处理。迁移完成后，后台资源不再经过 EdgeOne 或 Cloudflare，www、en 及裸域的后台入口统一跳转至 admin，并成功通过新后台域名将 WordPress 升级到 7.0.1，未再出现 524、维护模式残留或 core_updater.lock。
-
本文记录 WordPress 英文站从 /en/ 路径迁移到 en.shuijingwanwq.com 后，围绕 Yoast SEO 站点地图进行的完整调整与验证过程。内容包括薄内容标签页设置 noindex 并从 XML Sitemap 排除、W3 Total Cache 与 Cloudflare 多层缓存清理、重复标签导致的 Sitemap 误判排查，以及 Google、Bing、360、百度和搜狗等搜索平台中的资源添加与站点地图更新。最终，中英文站均统一使用 Yoast 生成的 sitemap_index.xml，英文子域的 Sitemap、robots、canonical 和搜索引擎提交状态均得到验证。
-
本文记录 WordPress + Polylang 英文站从 /en/ 迁移至独立子域名后，对首页和分类归档页错误链接的完整排查与修复过程。问题涉及分类下拉列表仍使用中文主域名、站点标题和面包屑 Home 指向默认语言首页、导航与侧栏保留旧 /en/ 链接，以及 W3 Total Cache Object Cache 导致英文 Host 无法及时加载最新 WPCode 片段。最终通过前端事件补丁、区块模板链接调整、按 Host 刷新对象缓存及源站验证，恢复英文站分类、导航、面包屑和多域名链接的正确跳转。
-
本文记录了 WordPress 英文站日历链接被错误拼接为双重 URL 的完整排查过程。问题最初源于旧版 WPCode 代码仍按 `/en/` 目录模式处理链接，在英文站迁移到 `en.shuijingwanwq.com` 后，将完整子域名 URL 再次拼接到旧地址后方。代码升级为兼容 Polylang 多域名模式的版本后，英文 Host 仍因 W3 Total Cache Object Cache 中的旧状态继续执行旧代码。最终通过按 `en.shuijingwanwq.com` Host 加载 WordPress 并调用 W3TC 对象缓存清理接口，使新版代码立即生效，日历链接恢复正常，并将清理流程整理为可重复使用的服务器脚本。
-
本文记录了一次 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 和旧全局样式对象缓存等问题的排查思路。
-
本文继续记录 WordPress + Polylang 英文站从 /en/ 迁移到 en.shuijingwanwq.com 之后的 CDN 与缓存配置过程。前一篇文章已经解决了源站侧的 Polylang 多域名配置、W3 Total Cache Page Cache 兼容、Redis Object Cache 旧配置缓存等问题。本文重点处理 en.shuijingwanwq.com 接入 Cloudflare、启用 HTML 页面缓存、验证首页与文章页 MISS 到 HIT、确认登录用户 Cookie、REST API、登录页和后台入口不会被缓存，并最终通过 Nginx 将非 www 域名下的后台入口统一 301 到 www.shuijingwanwq.com。
-
本文记录一次将 WordPress + Polylang 英文站从路径模式 /en/ 迁移到独立子域名 en.shuijingwanwq.com 的完整排查过程。迁移过程中并不是简单修改 Polylang URL 设置就结束了，而是连续遇到了 Polylang 保存失败、扩展插件 Fatal Error、W3 Total Cache 将英文子域名误判为 foreign domain 并 301 回主域名、Redis Object Cache 缓存旧语言配置等问题。最终通过修复 Polylang 扩展插件、添加 W3TC 兼容 mu-plugin、清理 Redis 对象缓存，并验证 html lang、canonical、hreflang 和 W3TC 页面缓存文件，完成了英文子域名的源站侧迁移。
-
这篇文章记录了将 WordPress 历史图片资源迁移到 `media.shuijingwanwq.com` 后，EdgeOne 仍然持续出现 301 请求的排查过程。通过 EdgeOne 状态码分析、`curl` 验证、旧文章源码检查和 Better Search Replace dry run，最终确认问题并非 EdgeOne 回源异常，而是历史文章正文中仍然保存着迁移前的 `www.shuijingwanwq.com/wp-content/uploads/` 图片地址。文章详细记录了如何安全替换完整旧图片 URL、清理 W3 Total Cache 缓存，并说明为什么不应无脑替换所有 `/wp-content/uploads/` 相对路径，以避免破坏技术文章中的路径说明内容。