This webpage is not available ERR_CONTENT_DECODING_FAILED – PHP ob_start() ob_gzhandler – Trailing spaces after closing ?> in WordPress Plugin
This webpage is not available ERR_CONTENT_DECODING_FAILED – PHP ob_start() ob_gzhandler – Trailing spaces after closing ?> in WordPress Plugin
Recently we ran into an issue where a website would not load. We traced the problem to a line in the code which attempted to pass all content to ob_start(‘ob_gzhandler’).
This basically words to zip up all content and send it to the browser. However an error was being thrown ERR_CONTENT_DECODING_FAILED, which showed up in the browser window and in the browser console. After some detailed debugging in PHP using some die commands()
die("die: ".__FILE__.":".__LINE__);
I found that the issue came from an rogue blank character which displayed before the ob_start(“ob_gzhandler”) function could be called.
There were a couple of ways I could deal with this, first I could simply put an ob_start() at the top of the code, and then put an ob_get_clean(); just before the ob_start(‘ob_gzhandler’), however this felt a bit sloppy, so I went in search of the rogue character.
The application that this was in, was one that simply included the wordpress load file so that it could integrate with a WordPress installation, and I found that the characters was coming from the WordPress install. Using a hunch I decided d to look for a recently updated plugin and I quickly found a plugin that had an end php tag “?>” with an extra line after it.
I quickly fixed this and then decided I would figure out a way to quickly identify issues like this. While there are many ways to address this and figure out how to over come it, the issue seems to identify an need to figure out whether plugins conform to some best practices (such as omitting a closing ?> php sign)
If we identify this need, we will write a free plugin to put on the WordPress site, which will go through all plugins on sites to confirm that they use some best practices such as this.