注意:ob_end_flush(）:无法在中发送zlib输出压缩(1）的缓冲区 - Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in

我在本地主机上没有任何问题。但当我在服务器上测试我的代码时，在每一页的末尾我都会看到这个通知。

我的代码：

<?php
ob_start();
include 'view.php';
$data = ob_get_contents();
ob_end_clean();
include 'master.php';
ob_end_flush();  // Problem is this line

我不建议完全禁用wp_ob_end_flush_all()函数，也绝对不会关闭php.ini文件中的zlib.output_compression。这里有一种更好的方法，可以替换导致问题的源代码，并保留底层功能：

/**
 * Proper ob_end_flush() for all levels
 *
 * This replaces the WordPress `wp_ob_end_flush_all()` function
 * with a replacement that doesn't cause PHP notices.
 */
remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );
add_action( 'shutdown', function() {
   while ( @ob_end_flush() );
} );

关于原因的更多细节，以及为什么这可能是最好的方法，可以在这里找到：WordPress ob_end_flush（）错误的快速修复

WordPress试图在关闭时刷新输出缓冲区。它失败了，因为您已经调用了ob_end_flush()。

您应该能够保持压缩，并简单地取消刷新操作：

remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );

现在，您可以手动调用ob_end_flush()，并保持zlib压缩。

在php.ini 中关闭zlib.output_compression时解决

zlib.output_compression = Off

我在我们客户的一个WP站点上发现了一个特定的插件。

在这种情况下，它是由"NextGEN Gallery"插件引起的，但奇怪的是，简单地停用然后激活插件就解决了问题。

对于其他有这个问题的人来说，值得寻找可疑的面向前端的插件并尝试同样的方法。如果在重新激活罪魁祸首插件时发现问题再次出现，则应向插件作者提交问题。

出于安全考虑，您应该始终禁用实时站点上的正面错误。

如果你想在Wordpress中隐藏错误，并获取错误日志以供查看，你可以在wp-config.php文件中执行以下操作：

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

PS：如果你想使用上面alexg的remove_action代码，remove_action('shutdown', 'wp_ob_end_flush_all', 1);，你需要把它放在主题的functions.php文件中。

PPS：您可能还想尝试在wp-config.php文件中使用define(‘WP_MEMORY_LIMIT’,’1024M’);，但是，请注意不要分配超出需要的内容，因为这会影响Wordpress的前端，如果页面上同时有太多点击量，您将面临RAM不足的风险。

只需将其添加到主题函数.php文件

remove_action（'shutdown'，'wp_ob_end_flush_all'，1）

另一个场景：

我在我的直播网站上收到了这个通知，但在localhost和一个登台/演示网站上没有，尽管演示网站和直播网站在同一台服务器上。

事实证明，zlib扩展并没有在现场激活，它引起了通知。一旦zlib扩展被激活，通知就停止了因此不需要代码修复。

将此ob_end_flush()替换为remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 )

**
* Flush all output buffers for PHP 5.2.
*
* Make sure all output buffers are flushed before our singletons are destroyed.
*
* @since 2.2.0
*/
function wp_ob_end_flush_all() {
     $levels = ob_get_level();
     
     for ( $i = 0; $i < $levels; $i++ ) {
         ob_end_flush();
     }
}

更新后的代码应该看起来像这个

function wp_ob_end_flush_all() {
    $levels = ob_get_level();
    for ( $i = 0; $i < $levels; $i++ ) {
        remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );
    }
}

只需在关机挂钩上使用您的代码，并提前定位默认的ob_end_flush（）将识别您的输出并刷新它

    add_action('shutdown', 'your_code', 0);
function your_code(){
/* Your Code Goes here */
}

我尝试了一种有效的暴力方法（我对此不满意，但希望这能帮助到别人）：

在/wp content/themes/<主题目录>functions.php（显然在php闭包"？>"之前）添加以下行：

ob_get_clean();

此错误可能是由于没有关闭?>导致的；该插件在激活期间生成了X个意外输出字符"；然后激活调试。我缩小了index.php中的include文件的范围，使其成为处理/不处理错误的目标文件。然后我进入该文件，并使用PHP标记关闭该文件，因为该文件中有许多函数。之后工作。

不要惊慌，这很简单。只需打开函数php并找到以下代码

**
 * Flush all output buffers for PHP 5.2.
 *
 * Make sure all output buffers are flushed before our singletons are destroyed.
 *
 * @since 2.2.0
 */
function wp_ob_end_flush_all() {
  $levels = ob_get_level();
  for ( $i = 0; $i < $levels; $i++ ) {
    ob_end_flush();
  }
}

在您简单地删除"；ob_end_flush（）"并替换此代码

remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );

解决了100%。

尝试禁用wordpress调试模式，问题就解决了。您可以在/wp-config.php:中禁用WP调试模式

define('WP_DEBUG', FALSE);