Problem with compression

No, that’s a first divano ..

Some questions:
* Are the problems you describe for the admin-pages or for anonymous visitors on the front-end?
* Do you see errors in the PHP errorlog?
* Do you see errors on the browser console?
* Are you sure you’re not causing output to be compressed twice (which typically results in browsers being unable to “understand” the response)?
* Do you have “serve as static files” off in Autoptimize and if so do things work if you re-enable that option?

frank

Hi Frank, thanks for answer.

Following order of your questions:

* Is visible on front-end.
* Error log says: PHP Notice:  ob_end_flush(): Failed to send buffer of zlib output compression (0) in /home/***/public_html/wp-includes/functions.php on line 4979 

So, on function wp_ob_end_flush_all() {
	$levels = ob_get_level();
	for ( $i = 0; $i < $levels; $i++ ) {
		ob_end_flush(); } }

* No error detected by console.
* I don't know honestly, but if you tell me how/where check, I'll take a look.
* Enabled or not, effect is the same.

Thanks so much again.

Error log says: PHP Notice: ob_end_flush(): Failed to send buffer of zlib output compression (0) in /home/***/public_html/wp-includes/functions.php on line 4979

an output buffer error from WordPress core? lots of info to be found on the interwebz, most interesting one being this wordpress core ticket, in which a.o. this statement is made;

Currently WordPress per default is not compatible with zlib enabled.

and this workaround code snippet is proposed for those who _want_ to use zlib compression at PHP level;

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

I don’t know honestly, but if you tell me how/where check, I’ll take a look.

I would check the network tab in the browser developer tools, checking each request for non HTTP-200 (OK) replies and looking at the response body to see if any of those has garbled text.

but why are you trying to zlib.output_compression? what is it you want to accomplish?

Hi,
We haven’t “non http-200” requests, while on thread you’ve linked (started nine years ago) it is also claimed that “turning off compression is NOT an acceptable option, despite all the people who suggest it”, in fact according to all speed and structure tester (thinkwithgoogle, pingdom, gtmetrix, site24x7, uptrends…), performance significantly improves with compression, reason why it was activated.

As always, thanks for the support.

while on thread you’ve linked (started nine years ago) it is also claimed that “turning off compression is NOT an acceptable option, despite all the people who suggest it”

In that case try the code snippet provided by Nacin? ??

in fact according to all speed and structure tester (thinkwithgoogle, pingdom, gtmetrix, site24x7, uptrends…), performance significantly improves with compression, reason why it was activated.

yes, compresssion is a must, but typically compression is (should be?) handled at webserver-level for static resources and is generally handled by the page caching layer for the HTML output.

• This reply was modified 3 years, 3 months ago by Optimizing Matters.