Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in

Question

I don't have any problem on localhost. but when i tested my codes on server, end of every page i see this notice.

my code:

<?php
ob_start();
include 'view.php';

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

Concentrated

Answer 1

It solved when switched off zlib.output_compression in php.ini

zlib.output_compression = Off

Concentrated

Turning off gzip compression doesn't seem like a valid solution to me. – Recently

I agree with @Swen. Output compression (be it deflate or gzip) almost always offers positive points in SEO benchmarks, including Google's PageSpeed insights. Disabling it can harm your position in search results as it will increase loading times for mobile users. – Feer

@Feer ... yes, but gzip deflation is almost always turned on at the webserver level anyway, so having PHP pre-compress can be deemed unnecessary, no? – Did

This is NOT a solution; removing compression from the site is just lazy and horrible, use one of the other viable solutions above. – Miry

Answer 2

I wouldn't recommend disabling the wp_ob_end_flush_all() function entirely, and I definitely wouldn't turn off zlib.output_compression in your php.ini file. Here's a better approach that replaces the source code causing the issue, and preserves the underlying functionality:

/**
 * 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() );
} );

More details on the cause, and why this is probably the best approach can be found here: Quick Fix for WordPress ob_end_flush() Error

Reinforce

In my case, on a WordPress site, I can confirm that this approach has a positive effect on page-speed, as opposed to @alexg's approach. – Rider

Your approach didn't work for me, Kevin. Put your code in my child theme's functions.php, main theme's functions.php and the one in wp-includes. I found your article a bit ambiguous in places - for instance - we're not deleting the function wp_ob_end_flush_all in wp-includes/functions.php? – Criticism

Thanks for sharing this. It worked for me. – Deerhound

I copy and pasted this straight into my index.php for my WordPress plugin, and the error was gone! Magical, thanks. – Intermission

Modern PHP does an auto-flush of all existing buffers, so it's completey safe to remove this function entirely. This solution should also work just fine. See my comment above for more info. – Miry

@BrianC, the solution remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 ); doesn't work with debug mode enabled. It still generates the notice. – Globeflower

@Globeflower try all the other solutions listed on this page; it appears there are a variety of other causes. Without knowing your WordPress version and server setup it's impossible to comment further. – Miry

Answer 3

WordPress attempts to flush the output buffers on shutdown. It fails because you have already called ob_end_flush().

You should be able to keep compression on, and simply unhook the flush action:

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

You can now call ob_end_flush() manually, and keep zlib compression on.

Katalin

It's a mystery as to why we need to remove the call to wp_ob_end_flush_all() as it actually uses the buffer level (via ob_get_level() - see code here). It should auto-detect the level and run just the correct number of ob_end_flush() calls, but instead it is running one too many. It seems like this is a bug! – Miry

add this to your child theme function.php - did the job for me – Depolymerize

Using this solution produces, quite often, the following notice: "ob_end_flush(): failed to delete and flush buffer. No buffer to delete or flush". And does not respond to a fundamental question: why this does not happen on every wordpress intallation, not on every server? – Derbyshire

you mentioned "you should be able to keep compression on" what do you mean? – Catherin

@PouriaAnsari I meant that, if you remove that action the issue is resolved, you don't need to disable zlib compression at the web server level, as suggested by AliN11 in another answer. But check out KevinLeary's answer too. – Katalin

With some time, it seems this error is caused by having the server PHP option zlib.output_compression on, as it creates an internal buffer which somehow messes up ob_get_level(). PHP itself does an auto-flush of all extant buffers on shutdown, so the wp_ob_end_flush_all() is no longer needed. It was needed for a PHP 5.2 compatibility issue in the distant past, and is fine on most servers, so hasn't been removed. It would be best when WordPress wakes up and removes the function, but for now, removing the shutdown action is fine, and very safe. – Miry

Answer 4

You Should always disable front-facing errors on live sites for security reasons - regardless.

If you want to hide the errors in Wordpress and get a log of the errors for review instead, you can do something like the following in your wp-config.php file:

// 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: If you want to use the remove_action code by alexg above, remove_action('shutdown', 'wp_ob_end_flush_all', 1); you will need to place it in the functions.php file of your theme.

PPS: You may also want to try using define(‘WP_MEMORY_LIMIT’,’1024M’); in your wp-config.php file - however, be careful that you don't allocate more than you need to as this affects the front end of Wordpress and you'll run the risk of running out of RAM if you have too many simultaneous hits on pages.

Yahairayahata

Answer 5

I found a particular plug-in was the cause on one of our client's WP sites.

In this case it was caused by the "NextGEN Gallery" plug-in, but weirdly simply deactivating and then activating the plug-in resolved the issue.

For anyone else having this problem it would be worth looking for suspect front end facing plug-ins and trying the same. If you find that the issue comes back when the culprit plug-in is reactivated you should file an issue with the plug-in author.

Feer

Plugin (WP Smush) caused the issue for me too it seems. Although removing and reinstalling it fixed it rather than disable/reenable. – Cho

Answer 6

Simply Add this to theme functions.php file

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

Unguinous

Answer 7

One another scenario:

I was getting this notice on my live site but not on localhost and a staging / demo site, even though the demo site was on the same server as live site.

It turned out that zlib extension wasn't activated on live site and it was causing the notice. Once the zlib extension was activated, the notice stopped coming. So there was no code fix needed.

Dolf

Answer 8

Just Use Your code on shutdown hook and make the position earlier And the default ob_end_flush() will recognize your output and will flush it

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

Igorot

Answer 9

I tried a brute-force approach which worked (I'm not satisfied with it, but hope this can help someone):

In the last line of the /wp-content/themes/<theme_directory>/functions.php (obviously before the php closure '?>') add the following line:

ob_get_clean();

Maxi

Answer 10

This error can be caused by not having a closing ?> I came here after getting the error of "The plugin generated X characters of unexpected output during activation" and then activating debug. I narrowed down my include files in index.php to be the targetted file that worked with/without the error. Then I went into that file, and closed the file with the PHP tag, as there were a number of functions inside the file. Worked after that.

Intermission

Answer 11

1. Create this file:

wp-content/mu-plugins/fix-zlib.php

create mu-plugins folder if not exists

2. Copy this code inside it and save it

<?php

/**
 * Fix zlib Error
 */
remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );
add_action( 'shutdown', static function () {
  $levels = ob_get_level();
  for ( $i = 0; $i < $levels; $i ++ ) {
      @ob_end_flush();
  }
}, 9999999 );

Done!

Pantaloons

Answer 12

Please try this in wp-config.php:

if (ob_get_level()) {
    ob_end_clean();
}

Haff

Answer 13

Don't be panic, it's so simple. just open function php and find this code

**
 * 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();
  }
}

After you simply deleted "ob_end_flush();" and replace this code

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

solved it's 100%.

Riata

Editing the core files is such a bad idea. – Jackinthepulpit

Editing core files is not the ideal solution for most. The edited file will revert on the next core update. Editing core files can also introduce side-effect issues in other areas of the installation. wordpress.org/support/article/editing-files/… – Meseems

Modifying core files is an amateur-level solution and isn't a fix as the next version of WordPress will just silently obliterate the fix. The other solutions above are fine; it's best to just use remove_action to kill off WordPress's unnecessary end_flush function. – Miry

Answer 14

Replace this ob_end_flush() replace with 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();
     }
}

The Updated code should look like this

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 );
    }
}

Lanford

Answer 15

Try to disable wordpress debug mode and it's resolved. You can disable WP debug mode in /wp-config.php :

define('WP_DEBUG', FALSE);

Macaulay

What @Casper said. This can actually be worse as you may simply end up with a white page with no indication as to what has gone wrong, particularly with the HTTP OK [200] response. Debug mode should remain on until the problem is resolved, turned off thereafter. – Feer

In this particular case, yes it is a bad idea. However, installing a brand new WP 5.4.1 and define( 'WP_DEBUG', true ); as any developer should do, give me this error about zlib.output_compression. Turn it to false make the error disappear. – Viridi