docker pull拉取WordPress5.7升级后，后台带php-error类无报错如何排查？

这个空白不是实际PHP错误触发的，是WordPress 5.7新增的输出检测逻辑直接导致的：

• WordPress 5.7 新增了HTML生成前的缓冲区残留检测机制：只要检测到任何非预期的内容输出到缓冲区（哪怕是BOM头、空行这类无意义内容，不是真的PHP错误），就会自动给页面body标签加上php-error类。
• 这个类的默认CSS自带顶部边距，本来是用来预留PHP错误的展示位置，哪怕没有实际错误输出，只要类被加上，就会在#wpadminbar下方出现固定空白。
• 5.6.2版本没有这套检测逻辑，所以回退版本后问题直接消失。

• 你找不到默认wp-content/debug.log是正常情况：挂载的error-logging.ini已经把PHP全局错误日志路径强制重定向到了./logs/debug.log，WordPress的调试日志也会走这个全局路径，不会单独生成默认日志文件。
• php-error类的触发逻辑是WordPress自己的输出缓冲区检测，和PHP的错误体系完全无关，所以哪怕PHP日志功能正常，也不会记录这类非错误的多余输出，自然找不到相关记录。

第一步：定位具体的残留输出内容 #

在wp-content/mu-plugins目录下新建一个临时PHP文件（比如debug-residual-output.php），写入以下代码，直接捕获缓冲区的残留内容写入日志：

add_action('admin_init', function() {
    if (ob_get_level() > 0) {
        $residual = trim(ob_get_contents());
        if (!empty($residual)) {
            // 写入你已经挂载的自定义日志文件，方便宿主机直接查看
            error_log('Residual output hex: ' . bin2hex($residual) . PHP_EOL, 3, '/var/www/html/wp-content/logs/debug.log');
        }
    }
});

访问一次管理后台后，直接打开宿主机的./logs/debug.log查看输出的十六进制内容：

• 如果开头是efbbbf，说明是UTF-8 BOM头，一般是你挂载到容器的自定义文件带了BOM格式。
• 如果内容只有0a或者0d0a，说明是空行/换行符，一般是PHP文件末尾多留了空行。

第二步：针对性修复 #

情况1：残留来自你挂载的自定义文件 #

• 检查所有挂载到容器的自定义文件，包括wp-config.php、error-logging.ini、自定义插件/主题文件：
  • 用支持无BOM编码的编辑器（比如VS Code）去掉文件开头的UTF-8 BOM头，不要用Windows自带记事本编辑这类文件。
  • 所有PHP文件删掉末尾的?>标签，或者确保?>之后没有任何空行、空格，从根源避免多余输出。

情况2：残留来自官方镜像默认配置 #

如果排查后确认不是自己挂载的文件导致的，直接在docker-compose.yml的WORDPRESS_CONFIG_EXTRA配置块里追加两行设置，关掉多余的输出边距：

WORDPRESS_CONFIG_EXTRA: |
  define('WP_DEBUG', true);
  define('WP_DEBUG_LOG', true);
  // 新增以下配置
  define('WP_DEBUG_DISPLAY', false);
  @ini_set('display_errors', 0);

这套配置不会影响调试日志的写入，同时会禁用WordPress基于输出的错误展示逻辑，从根源去掉php-error类的添加。

临时治标方案 #

如果暂时不需要排查残留来源，可以直接在后台的自定义CSS里给php-error类加覆盖样式，去掉默认边距：

body.php-error {
    margin-top: 0 !important;
}

注意这个只是临时掩盖问题，后续如果真的出现PHP错误，错误内容会直接显示在页面顶部，建议还是尽量找到残留输出的源头修复。

内容的提问来源于stack exchange，提问作者joshmoto