Wildcat Media
Well-known member
I think this may have gotten overlooked in another thread of mine.
I had reported some screwy issues with XF that were style-related--a password feature would not work, the XF logo was not animated in the admin control panel, etc..
What it turned out to be was that the XF coding was not compatible with the gzip setting I used on our server. For several years, I have used the following in htaccess to gzip-compress our outgoing HTML data to browsers, and it saved us a lot of bandwidth and decreased page loading times:
There is something gzip is doing that does not "play nice" with the code in XF.
My initial thought is that it may be a result of compressed and/or "minified" CSS or JS files. I have not dug into the code enough to see if that is the case. I do know that the issues were not enough to cripple the forum entirely (other than the "lost password" link), but a few of the nice extras just were not working as they should have.
For now I had to disable the gzip in our XF forum directories.
I also do not know if the Apache module mod_gzip would cause the same problem. Our host may have added that option for us--back when I first did this via the PHP route, they did not offer that for us. If they do have it available, I may enable it and see if the issue can be repeated there as well.
I could see adding gzip support in future XF versions as well, like vBulletin does. Although I would not ship XF to have it set to "on" by default--you can imagine what happens when you have two gzip operations on top of each other!
If the developers can't duplicate it here (or want to), let me know and I can setup a test version on one of my servers. It should be possible with most PHP/Apache configurations to turn it on via htaccess like I did above.
I had reported some screwy issues with XF that were style-related--a password feature would not work, the XF logo was not animated in the admin control panel, etc..
What it turned out to be was that the XF coding was not compatible with the gzip setting I used on our server. For several years, I have used the following in htaccess to gzip-compress our outgoing HTML data to browsers, and it saved us a lot of bandwidth and decreased page loading times:
Code:
php_value output_handler ob_gzhandlerThere is something gzip is doing that does not "play nice" with the code in XF.
My initial thought is that it may be a result of compressed and/or "minified" CSS or JS files. I have not dug into the code enough to see if that is the case. I do know that the issues were not enough to cripple the forum entirely (other than the "lost password" link), but a few of the nice extras just were not working as they should have.
For now I had to disable the gzip in our XF forum directories.
I also do not know if the Apache module mod_gzip would cause the same problem. Our host may have added that option for us--back when I first did this via the PHP route, they did not offer that for us. If they do have it available, I may enable it and see if the issue can be repeated there as well.
I could see adding gzip support in future XF versions as well, like vBulletin does. Although I would not ship XF to have it set to "on" by default--you can imagine what happens when you have two gzip operations on top of each other!
If the developers can't duplicate it here (or want to), let me know and I can setup a test version on one of my servers. It should be possible with most PHP/Apache configurations to turn it on via htaccess like I did above.
