全局搜一遍还有哪些文件写了旧路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php'修复
最稳的是直接把旧路径批量换成容器里的真实路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' \
| xargs sed -i 's|/usr/share/nginx/html|/var/www/html|g'
docker restart wp-app嫌麻烦也可以进后台把 WP Super Cache 禁用再启用，插件会用新路径重新生成这些文件；或者手动改 advanced-cache.php、wp-cache-config.php、wp-cache.php 三处的路径。
验证
docker logs wp-app --tail 30 # Warning 应该没了
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' # 应返回空记住这几点
- Docker 里目录结构跟宿主机不是一回事，任何写死绝对路径的配置，迁移或换挂载点后都会爆。
- 插件是路径硬编码重灾区：缓存类（WP Super Cache）、安全类（Wordfence）都会生成带绝对路径的文件。
- 迁完环境，先全局 grep 一遍旧路径，往往能揪出被忽略的隐患。
- 502/500 先看对应容器日志（docker logs wp-app），别光盯着 Nginx——Nginx 只是把上游的错误透传出来。
- 插件要是改用 WP_CONTENT_DIR 这类 WordPress 常量拼路径，就不怕目录变了。
这个坑修完，缓存命中率恢复正常，也提醒我：容器化隔离了环境，但应用层对路径的敏感一点没少。
再看报错文件里写的是啥路径。宿主机上 /opt/wordpress/html 挂载到容器 /var/www/html，所以直接看宿主机这份：
cat /opt/wordpress/html/wp-content/advanced-cache.php全局搜一遍还有哪些文件写了旧路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php'修复
最稳的是直接把旧路径批量换成容器里的真实路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' \
| xargs sed -i 's|/usr/share/nginx/html|/var/www/html|g'
docker restart wp-app嫌麻烦也可以进后台把 WP Super Cache 禁用再启用，插件会用新路径重新生成这些文件；或者手动改 advanced-cache.php、wp-cache-config.php、wp-cache.php 三处的路径。
验证
docker logs wp-app --tail 30 # Warning 应该没了
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' # 应返回空记住这几点
- Docker 里目录结构跟宿主机不是一回事，任何写死绝对路径的配置，迁移或换挂载点后都会爆。
- 插件是路径硬编码重灾区：缓存类（WP Super Cache）、安全类（Wordfence）都会生成带绝对路径的文件。
- 迁完环境，先全局 grep 一遍旧路径，往往能揪出被忽略的隐患。
- 502/500 先看对应容器日志（docker logs wp-app），别光盯着 Nginx——Nginx 只是把上游的错误透传出来。
- 插件要是改用 WP_CONTENT_DIR 这类 WordPress 常量拼路径，就不怕目录变了。
这个坑修完，缓存命中率恢复正常，也提醒我：容器化隔离了环境，但应用层对路径的敏感一点没少。
先看日志定位出错文件（我们博客的 WordPress 跑在 wp-app 容器里）：
docker logs wp-app --tail 50再看报错文件里写的是啥路径。宿主机上 /opt/wordpress/html 挂载到容器 /var/www/html，所以直接看宿主机这份：
cat /opt/wordpress/html/wp-content/advanced-cache.php全局搜一遍还有哪些文件写了旧路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php'修复
最稳的是直接把旧路径批量换成容器里的真实路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' \
| xargs sed -i 's|/usr/share/nginx/html|/var/www/html|g'
docker restart wp-app嫌麻烦也可以进后台把 WP Super Cache 禁用再启用，插件会用新路径重新生成这些文件；或者手动改 advanced-cache.php、wp-cache-config.php、wp-cache.php 三处的路径。
验证
docker logs wp-app --tail 30 # Warning 应该没了
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' # 应返回空记住这几点
- Docker 里目录结构跟宿主机不是一回事，任何写死绝对路径的配置，迁移或换挂载点后都会爆。
- 插件是路径硬编码重灾区：缓存类（WP Super Cache）、安全类（Wordfence）都会生成带绝对路径的文件。
- 迁完环境，先全局 grep 一遍旧路径，往往能揪出被忽略的隐患。
- 502/500 先看对应容器日志（docker logs wp-app），别光盯着 Nginx——Nginx 只是把上游的错误透传出来。
- 插件要是改用 WP_CONTENT_DIR 这类 WordPress 常量拼路径，就不怕目录变了。
这个坑修完，缓存命中率恢复正常，也提醒我：容器化隔离了环境，但应用层对路径的敏感一点没少。
首页能打开，但 PHP 日志里反复出现类似这样的报错：
PHP Warning: include_once(/usr/share/nginx/html/wp-content/plugins/wp-super-cache/wp-cache-phase1.php): failed to open stream: No such file or directory in /var/www/html/wp-content/advanced-cache.php on line 42页面能渲染，但缓存功能失效，后台持续报错。报错里的旧路径 /usr/share/nginx/html 已经是上一台机器的目录了。
根因
WP Super Cache 启用时会生成 advanced-cache.php 和 wp-cache-config.php。生成时用 __FILE__ / dirname() 拿当前文件的绝对路径写进去。如果 WordPress 根目录从 /usr/share/nginx/html 变成了容器里的 /var/www/html，这些写死的旧路径就找不到了。
本质上是同一个问题：应用层把和环境绑定的绝对路径硬编码了。Wordfence 的 .user.ini 里 auto_prepend_file 也是这么干的。
排查
先看日志定位出错文件（我们博客的 WordPress 跑在 wp-app 容器里）：
docker logs wp-app --tail 50再看报错文件里写的是啥路径。宿主机上 /opt/wordpress/html 挂载到容器 /var/www/html，所以直接看宿主机这份：
cat /opt/wordpress/html/wp-content/advanced-cache.php全局搜一遍还有哪些文件写了旧路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php'修复
最稳的是直接把旧路径批量换成容器里的真实路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' \
| xargs sed -i 's|/usr/share/nginx/html|/var/www/html|g'
docker restart wp-app嫌麻烦也可以进后台把 WP Super Cache 禁用再启用，插件会用新路径重新生成这些文件；或者手动改 advanced-cache.php、wp-cache-config.php、wp-cache.php 三处的路径。
验证
docker logs wp-app --tail 30 # Warning 应该没了
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' # 应返回空记住这几点
- Docker 里目录结构跟宿主机不是一回事，任何写死绝对路径的配置，迁移或换挂载点后都会爆。
- 插件是路径硬编码重灾区：缓存类（WP Super Cache）、安全类（Wordfence）都会生成带绝对路径的文件。
- 迁完环境，先全局 grep 一遍旧路径，往往能揪出被忽略的隐患。
- 502/500 先看对应容器日志（docker logs wp-app），别光盯着 Nginx——Nginx 只是把上游的错误透传出来。
- 插件要是改用 WP_CONTENT_DIR 这类 WordPress 常量拼路径，就不怕目录变了。
这个坑修完，缓存命中率恢复正常，也提醒我：容器化隔离了环境，但应用层对路径的敏感一点没少。
作者：司陌笙
环境：阿里云 ECS / Alibaba Cloud Linux 3（Docker Compose：wp-app / wp-db）
标签：Docker、PHP、WordPress、运维学习
用 Docker 跑 WordPress 有个坑值得单独记一笔：WP Super Cache 这类插件会把运行时的绝对路径写死到它生成的 PHP 文件里。一旦 WordPress 根目录的路径变了（比如从一台机器迁到 Docker、或者重建容器时挂载点不一样），缓存就直接挂，PHP 日志还会一直刷 Warning。下面是我在这个博客环境（wp-app 容器，WordPress 根在容器里的 /var/www/html）上总结的排查和修法。
故障现象
首页能打开，但 PHP 日志里反复出现类似这样的报错：
PHP Warning: include_once(/usr/share/nginx/html/wp-content/plugins/wp-super-cache/wp-cache-phase1.php): failed to open stream: No such file or directory in /var/www/html/wp-content/advanced-cache.php on line 42页面能渲染，但缓存功能失效，后台持续报错。报错里的旧路径 /usr/share/nginx/html 已经是上一台机器的目录了。
根因
WP Super Cache 启用时会生成 advanced-cache.php 和 wp-cache-config.php。生成时用 __FILE__ / dirname() 拿当前文件的绝对路径写进去。如果 WordPress 根目录从 /usr/share/nginx/html 变成了容器里的 /var/www/html，这些写死的旧路径就找不到了。
本质上是同一个问题：应用层把和环境绑定的绝对路径硬编码了。Wordfence 的 .user.ini 里 auto_prepend_file 也是这么干的。
排查
先看日志定位出错文件（我们博客的 WordPress 跑在 wp-app 容器里）：
docker logs wp-app --tail 50再看报错文件里写的是啥路径。宿主机上 /opt/wordpress/html 挂载到容器 /var/www/html，所以直接看宿主机这份：
cat /opt/wordpress/html/wp-content/advanced-cache.php全局搜一遍还有哪些文件写了旧路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php'修复
最稳的是直接把旧路径批量换成容器里的真实路径：
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' \
| xargs sed -i 's|/usr/share/nginx/html|/var/www/html|g'
docker restart wp-app嫌麻烦也可以进后台把 WP Super Cache 禁用再启用，插件会用新路径重新生成这些文件；或者手动改 advanced-cache.php、wp-cache-config.php、wp-cache.php 三处的路径。
验证
docker logs wp-app --tail 30 # Warning 应该没了
grep -rln '/usr/share/nginx/html' /opt/wordpress/html --include='*.php' # 应返回空记住这几点
- Docker 里目录结构跟宿主机不是一回事，任何写死绝对路径的配置，迁移或换挂载点后都会爆。
- 插件是路径硬编码重灾区：缓存类（WP Super Cache）、安全类（Wordfence）都会生成带绝对路径的文件。
- 迁完环境，先全局 grep 一遍旧路径，往往能揪出被忽略的隐患。
- 502/500 先看对应容器日志（docker logs wp-app），别光盯着 Nginx——Nginx 只是把上游的错误透传出来。
- 插件要是改用 WP_CONTENT_DIR 这类 WordPress 常量拼路径，就不怕目录变了。
这个坑修完，缓存命中率恢复正常，也提醒我：容器化隔离了环境，但应用层对路径的敏感一点没少。