标签： W3 Total Cache
-
一次 WordPress 生产站点根目录清理实战。从 SSH 终端误粘贴产生的 0 字节命令碎片入手，逐步排查 WordPress 核心空文件、历史临时文件、旧主题与插件、PHP 维护脚本、Nginx/W3 Total Cache 配置、搜索引擎验证文件以及多年遗留的安装包。通过源码校验、旧博客溯源、当前配置核对和隔离机制，最终清理无用文件，同时避免误删仍在使用的标签处理脚本、AdSense、IndexNow 和搜索引擎验证文件，并总结生产环境下“先确认用途、优先隔离、最后删除”的安全清理思路。
-
在解决 WordPress 首页性能问题后，对当前服务器进行了完整配置审计，重点检查 Nginx、PHP-FPM、OPcache、Redis、W3 Total Cache、阿里云 RDS/MySQL 以及 WordPress 应用层。最终将 PHP-FPM 最大工作进程从 10 提高到 14，调整 OPcache 内存与 Interned Strings 配置，关闭 Gutenberg 实时协作，并为 SlyTranslate 调试日志增加日志轮转；同时保留大量已经运行健康的参数不变，形成一套更适合当前网站长期运行的服务器配置基线。
-
本文记录在阿里云 ECS 的 OneinStack 环境中，将源码安装的 Redis 7.0.11 升级到 Redis 8.10.0 的完整过程。内容包括升级前环境审计、vm.overcommit_memory 与 Transparent Huge Pages 优化、手动生成 RDB、双重备份与自动回滚、RedisBloom 等附加模块编译失败分析、Redis 核心二进制单独构建、旧版 RDB 兼容检查、临时端口与 PHP Redis 读写测试，以及生产切换后的 WordPress、W3 Total Cache、内存和缓存状态验证。
-
本文记录在 OneinStack 生产环境中将 PHP 从 8.1.19 升级到 8.5.9 的完整过程。升级期间，PHP 主体、PHP-FPM、Redis 和 LDAP 扩展均安装成功，但 Imagick 3.8.0 因 PHP 8.5 头文件兼容问题编译失败，最终改用 Imagick 3.8.1，并明确指定现有 ImageMagick 7.1.1-10 的安装路径完成编译。随后继续验证 WordPress、WP-CLI、REST API、Polylang 多域名输出，以及 W3 Total Cache Redis Object Cache 的跨请求持久化和中英文域名 Host 隔离，确认中文站、英文站和后台域名均正常运行。
-
阿里云 ECS 再次频繁触发 CPU 告警后，我结合云监控与 EdgeOne 离线日志，确认自动化抓取和大量回源 MISS 是主要诱因，而 W3TC 未预缓存归档分页只是放大因素。考虑到服务器长期运行在 1 核 2G、内存占用接近 60%，且后续还要部署 Go Tour，最终将实例升级为 2 核 4G。本文记录了告警分析、规格选择、快照备份、升配重启，以及 Nginx、PHP-FPM、Redis、W3TC 和三个域名的完整验证过程。
-
在将 W3 Total Cache、EdgeOne 与 Cloudflare 的主要 HTML 缓存统一延长到 4 天后，我发现新文章发布后，首页和 Sitemap 可能继续命中 CDN 中的旧缓存。本文记录如何在保留普通页面 4 天长缓存的同时，仅将中英文首页和公开 Yoast Sitemap 的 Edge TTL 缩短到 2 小时，并分别通过 EdgeOne 与 Cloudflare 实测缓存过期、重新回源和 HIT 行为。最终在内容新鲜度、缓存命中率和维护成本之间取得更合适的平衡。
-
在将 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 中英文归档页增加 Adsterra Native Banner 时，前台始终无法及时显示最新模板内容。经过对 WPCode、PHP Snippet、Shortcode、Language Visibility、Block Template、CDN、W3 Total Cache Page Cache 与 Redis Object Cache 的逐层排查，最终确认 www 与 en 不同 Host 下的 W3TC Object Cache 保留了旧版 wp_template。分别清理两个域名上下文的 Object Cache，并重新生成对应 Page Cache 后，中英文广告均恢复正常。此次问题也暴露出现有多域名缓存同步机制对 wp_template 等结构性内容覆盖不足，下一步将重点完善已有 MU 插件，并继续处理首页最新文章仍停留在 7 月 28 日的问题。
-
在再次出现 CPU 告警后，我暂时停止继续追查瞬时负载根因，转而重新启用 W3 Total Cache 页面预缓存，并从 900 秒 × 5 页 的保守配置逐步优化。通过准确统计中英文 Yoast Sitemap，确认真正需要预缓存的页面为 6270 个，并自动生成 www + en 联合 W3TC 专用 Sitemap，每小时同步更新。最终将 W3TC Page Cache、EdgeOne 中文站和 Cloudflare 英文站的缓存生命周期统一调整为 96 小时，同时采用 300 秒 × 7 页 的低批量持续预热策略，在降低冷缓存回源和 PHP 动态生成压力的同时，避免预缓存本身制造新的 CPU 峰值。