[phpBB Debug] PHP Notice: in file /includes/functions.php on line 4044: ob_start() [ref.outcontrol]: output handler 'ob_gzhandler' conflicts with 'zlib output compression'
I see this error everytime I am pressing on a link here at rippers.
Using Firefox 3.6.11
[phpBB Debug]
Moderator: crazyankan
-
crazyankan
- Crazy Editor!
- Posts: 1041
- Joined: Sun Nov 27, 2005 7:30 pm
- Location: Tiphares/Sweden
Re: [phpBB Debug]
2 Ripper:
Yes, I've noticed it too, but I've ignored it due to my lazyness to report it - nothing serious.
This is because of the output buffering gzip compression - compression set by script conflicts with the default compression handler defined in php.ini.
Have you updated php or phpbb recently? Maybe you have.
There are two ways to fix this:
1) Change handler in the script to zlib instead of gz.
2) Change the default handler in /etc/php/php.ini (usually it's there, although the path may vary (chroot, for example)) to gz instead of zlib, restart Apache (if you're using mod_php), or restart php service (if you're using standalone php-fpm/spawn_fcgi php version).
Also, error reporting. You have display_errors = 1 in your php.ini - that's awful. Never enable it on the production server - that's a giant security risk.
Change it to 0 immediately.
What about the error reporting - you have it very high and verbose, it slows down the server quite a bit.
As I've guessed, you have error_reporting = E_ALL, change it to E_ERROR, this will display only critical errors, but will omit everything else (even warnings) - this is a production server after all!
Of course, on the development server you can have it E_ALL, or even E_ALL & E_STRICT.
PS.
2 Crazyankan: It doesn't depend on the browser at all, don't worry - it's a server side issue.
PSPS.
Hope it helped.
Yes, I've noticed it too, but I've ignored it due to my lazyness to report it - nothing serious.
This is because of the output buffering gzip compression - compression set by script conflicts with the default compression handler defined in php.ini.
Have you updated php or phpbb recently? Maybe you have.
There are two ways to fix this:
1) Change handler in the script to zlib instead of gz.
2) Change the default handler in /etc/php/php.ini (usually it's there, although the path may vary (chroot, for example)) to gz instead of zlib, restart Apache (if you're using mod_php), or restart php service (if you're using standalone php-fpm/spawn_fcgi php version).
Also, error reporting. You have display_errors = 1 in your php.ini - that's awful. Never enable it on the production server - that's a giant security risk.
Change it to 0 immediately.
What about the error reporting - you have it very high and verbose, it slows down the server quite a bit.
As I've guessed, you have error_reporting = E_ALL, change it to E_ERROR, this will display only critical errors, but will omit everything else (even warnings) - this is a production server after all!
Of course, on the development server you can have it E_ALL, or even E_ALL & E_STRICT.
PS.
2 Crazyankan: It doesn't depend on the browser at all, don't worry - it's a server side issue.
PSPS.
Hope it helped.
ac8dad43d497508fe83d143ee096c252
Re: [phpBB Debug]
php.ini woes....
The compression was my fault, but strange i didn't see these errors before.
Also the php.ini missed some of my tweaks.
Seems the host updated some shit again.
I don't have root access but can make a custom php.ini.
However when they upgrade or whatever MY php.ini gets overwritten with a stock one.
Imagine having magic_quotes_gpc, register_globals, expose_php etc etc suddenly enabled by default!
Now hopefully my coding is good enough so that shouldn't be much of a problem, but still...
zlib is off, error reporting set to E_ERROR and some other misc crap set otherwise.
Anyway i'm still looking into ways to load the site faster.
Like the music pages have 800 thumbnails >_>
This nifty google addon called "page speed" for firefox suggested using sprites.
Loading one file instead of 20-100 per page by using background positioning.
Still experimenting...
The compression was my fault, but strange i didn't see these errors before.
Also the php.ini missed some of my tweaks.
Seems the host updated some shit again.
I don't have root access but can make a custom php.ini.
However when they upgrade or whatever MY php.ini gets overwritten with a stock one.
Imagine having magic_quotes_gpc, register_globals, expose_php etc etc suddenly enabled by default!
Now hopefully my coding is good enough so that shouldn't be much of a problem, but still...
zlib is off, error reporting set to E_ERROR and some other misc crap set otherwise.
Anyway i'm still looking into ways to load the site faster.
Like the music pages have 800 thumbnails >_>
This nifty google addon called "page speed" for firefox suggested using sprites.
Loading one file instead of 20-100 per page by using background positioning.
Still experimenting...
Re: [phpBB Debug]
Don't bother about the single image and offsets.
You should set an expiration date on all static content (google apache mod_expires) - it will be cached permanently on the user-side.
However, you'll have to append something like "?some_random_number" to EVERY image,css,js,whatever you've cached, so you will be able to update it user-side each time you change it, just by changing the ?number.
What about the page speed... don't even bother about YSlow or google meter. It solely depends on the bandwidth you have - 100 mbit is over the top for your purposes - you have a low hit rate.
If you want it to work faster, you should consider optimizing the page generation time on the server. Anyway, don't bother about it - for your purposes it's enough at all.
You should set an expiration date on all static content (google apache mod_expires) - it will be cached permanently on the user-side.
However, you'll have to append something like "?some_random_number" to EVERY image,css,js,whatever you've cached, so you will be able to update it user-side each time you change it, just by changing the ?number.
What about the page speed... don't even bother about YSlow or google meter. It solely depends on the bandwidth you have - 100 mbit is over the top for your purposes - you have a low hit rate.
If you want it to work faster, you should consider optimizing the page generation time on the server. Anyway, don't bother about it - for your purposes it's enough at all.
ac8dad43d497508fe83d143ee096c252