32

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
Paulo Boaventura
  • 1,365
  • 1
  • 9
  • 29
AliN11
  • 2,387
  • 1
  • 25
  • 40

13 Answers13

41

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

Kevinleary.net
  • 8,851
  • 3
  • 54
  • 46
  • 1
    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. – Dvaeer Mar 11 '20 at 18:59
  • 1
    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? – stigzler Jun 15 '20 at 20:45
  • Thanks for sharing this. It worked for me. – Umar Niazi Feb 19 '21 at 06:31
  • I copy and pasted this straight into my index.php for my WordPress plugin, and the error was gone! Magical, thanks. – Spinstaz May 06 '22 at 10:55
  • 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. – Brian C Oct 13 '22 at 04:36
  • @BrianC, the solution `remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );` doesn't work with debug mode enabled. It still generates the notice. – Motivated Nov 01 '22 at 08:33
  • @Motivated 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. – Brian C Nov 09 '22 at 00:50
39

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.

alexg
  • 3,015
  • 3
  • 23
  • 36
  • 2
    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](https://developer.wordpress.org/reference/functions/wp_ob_end_flush_all/)). 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! – Brian C Aug 25 '19 at 13:24
  • add this to your child theme function.php - did the job for me – DevWL Oct 29 '19 at 02:36
  • 1
    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? – bluantinoo Apr 13 '21 at 08:27
  • you mentioned "you should be able to keep compression on" what do you mean? – Pvria Ansari Jun 30 '22 at 05:50
  • @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. – alexg Jul 02 '22 at 14:13
  • 1
    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. – Brian C Oct 13 '22 at 04:34
11

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

zlib.output_compression = Off

AliN11
  • 2,387
  • 1
  • 25
  • 40
  • 23
    Turning off gzip compression doesn't seem like a valid solution to me. – Swen Sep 28 '18 at 11:22
  • 3
    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. – Adambean Oct 09 '18 at 11:40
  • @Adambean ... yes, but gzip deflation is almost always turned on at the webserver level anyway, so having PHP pre-compress can be deemed unnecessary, no? – scott8035 Nov 01 '19 at 17:20
  • This is NOT a solution; removing compression from the site is just lazy and horrible, use one of the other viable solutions above. – Brian C Oct 13 '22 at 04:38
3

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.

Obewan
  • 121
  • 6
2

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.

Adambean
  • 1,096
  • 1
  • 9
  • 18
  • Plugin (WP Smush) caused the issue for me too it seems. Although removing and reinstalling it fixed it rather than disable/reenable. –  May 17 '19 at 17:39
1

Simply Add this to theme functions.php file

remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );
Homesh Paul
  • 141
  • 9
0

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.

Vivek Athalye
  • 2,974
  • 2
  • 23
  • 32
0

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 */
}
Mohamed Saad
  • 368
  • 3
  • 8
0

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 );
    }
}
Al-Amin Sarker
  • 508
  • 3
  • 16
0

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();
sariDon
  • 7,782
  • 2
  • 16
  • 27
0

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.

Spinstaz
  • 287
  • 6
  • 12
-1

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%.

  • 1
    Editing the core files is such a bad idea. – Burgi Apr 06 '21 at 10:27
  • 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. https://wordpress.org/support/article/editing-files/#editing-files-offline – Mission Mike Aug 26 '21 at 21:12
  • 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. – Brian C Oct 13 '22 at 04:41
-10

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

define('WP_DEBUG', FALSE);
DaFois
  • 2,197
  • 8
  • 26
  • 43
  • 3
    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. – Adambean Oct 09 '18 at 11:47
  • 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. – Adrian P. May 06 '20 at 16:31