It would be nice if the 7.x port had very basic gzip capability soon.
The ability to have separate path structures like it was possible in D6 wouldn't even be necessary (in the beginning). The default behavior could simply be to have an html.gz file written to the same directory for every html file, if compression is enabled.
If you're using nginx, like we are, that's all it takes to make use of its gzip_static capability. Once you turn on this setting, the server will always check for a .gz version of each file in the same directory and deliver it when the browser request suggest it can handle gz.
After all, this is also the way that the D7 core js/css aggregator is doing it.
I made a very simple mod for myself, by appending the following to boost_exit():
boost_write_file($_boost['filename'].'.gz', gzencode($data, 9));
Comment | File | Size | Author |
---|
Comments
Comment #1
DRippstein CreditAttribution: DRippstein commentedI second this. I'm not sure why this is considered such a low priority... so low that it's marked in the 7.x handbook as "depreciated?"... when so many sites I see use gzip actively... but I find small file sizes really boost my site load speed. I know, shocking. Pardon that sarcasm... but depreciated?
Anyway, it's my understanding that checking for a header and enabling gzip doesn't take much code so I hope someone will add this feature in the near future. I'm going to tackle it myself on my site for my needs, but I don't know what's optimal for boost really (very new to it). So awesome module, can't wait for this "little" feature to come back.
Comment #2
bgm CreditAttribution: bgm commentedI'm not sure why the handbook mentioned that (it may be my bad). Fixed it to link to this issue.
Comment #3
voodootea CreditAttribution: voodootea commentedCan you please tell me in which particular file, you modified the code as above? thanks
Comment #4
ralf.strobel CreditAttribution: ralf.strobel commentedIf you take a look at the module, you will find that there is only one file ("boost.module") where all the functionality is implemented.
Comment #5
rogical CreditAttribution: rogical commentedAny patches possible?
Comment #6
wildermuthn CreditAttribution: wildermuthn commentedAdd it to the end of boost_exit(), AND, don't forget to modify your .htaccess file so that \.html in the 'gzip' section actually reads, \.html\.gz
At least, that worked for me.
Comment #7
pmichelazzosubscribing
Comment #8
bgm CreditAttribution: bgm commentedIf you want this to move forward, please provide a patch, it saves us maintainers a lot of time in figuring out exactly the details.
It takes just a few minutes:
* clone the git repo:
git clone --recursive --branch 7.x-1.x http://git.drupal.org/project/boost.git
cd boost
* apply change to boost.module file
* git diff > /tmp/boost-gzip-1416214.patch
* attach patch file to this post.
Once we have a basic patch, we can move it forward from that point and solve the small details.
If you're working under Windows and installing git or using the command line is not obvious (although there are GUI solutions, but I don't know them much), just send a copy of your modified boost.module and we will do a diff/patch.
Thanks in advance :)
Comment #9
ruloweb CreditAttribution: ruloweb commentedInspired on the code from ralf I've created the attached patch.
It creates de gz version on cache folder and changes de htaccess generator.
Take a look please.
Thanks!
(using 7.x-1.x version)
Comment #10
pmichelazzoAfter apply the patch, the boost admin area was gone. I just receive a HTTP Error 500.
Thanks
Comment #11
ruloweb CreditAttribution: ruloweb commentedpmichelazzo that's probably a PHP error, please if you can give us more details it would help! :D
Comment #12
bgm CreditAttribution: bgm commentedCommitted to 7.x-1.x. Thanks for the patch!
Added the following:
* in admin/config/system/boost, added an option to disable gzip compression (enabled by default).
* compress only if the settings say so.
TODO:
* please test!
* test whether the cron will delete/expire the gz files as well.
* test 'expire' hook to see if it expires gz files.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedThere's problems with this update/ patch, if installed and updated
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedI think this patch need to be removed until further investigation. Tests enabling and disabling mod_mime indicate that something is not quite correct, mod_headers is disabled for the test. ForceType is therefore serving zip files to the browser as text
tested on two files where the uncompressed version was removed to confirm that only the gz file was served, files are 3494 and 3793 bytes respectively.
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commentedChecking this through and I continually have the forcetype directive being applied and then no decompression taking place.
Comment #16
bgm CreditAttribution: bgm commentedThanks for the quick feedback. I commented out temporarily the "gzencode" line in boost.module until we have more tests done.
Still requires however to clear the boost cache to delete the .gz files.
Were the rules in your main .htaccess (in the Drupal root directory) updated? (yep, I had forgotten to mention this rather important detail). -- we will need a way to remind people upgrading that their htaccess needs to be updated.
There's also the fact that cache is not expired by cron/expire, I presume, so gzip could show old content.
If it can help debugging, the most important rules for gzip are these:
So the first part should read: "if client does not support gzip, skip the next rule".
The second part has "E=no-gzip:1", which disables mod_deflate to avoid double-compression.
Although, to be honest, I haven't dived into mod_rewrite in a while, and most of this was already implemented by mikeytown2, I only added the .gz suffix.
fwiw, I often use "wget" with the "-S" option (show response headers) to do tests and see headers:
wget -S -O /dev/null http://example.org/
Or to request a page with gzip enabled:
wget -S --header="Accept-Encoding: gzip" -O index.html.gz http://example.org/
(or rename the resulting page to foo.gz, so that it's then possible to open with "vim" or gunzip the file)
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedYes .htaccess files were updated and I also manually deleted the unzipped files from the cache to make sure that only the cached .gz files were being served which is when I spotted the errors. Because I'd been testing out the .htaccess for mod_mime and mod_headers for my previous patches I got junk or a file to download as my test server by chance had them disabled. Possibly there could be a test to fix this, but it would involve a lot of servers and a series of long winded if statements to decide if the ForceType directive was placed inside the if mod_headers... directive. The issue appears to stem from apache itself and the ForceType stately definitively that this a text file even though gzip headers are being sent and altering the bytes sent by a fractional amount.
Comment #18
kent_drupal CreditAttribution: kent_drupal commentedAs per bgm suggestion on http://drupal.org/node/1888736#comment-6939904
I installed latest dev version of boost 7.x from 01/07/2013 date.
After uncommenting the line at 330, I could see .gzip files generated in cache/normal/... folder.
But when I tried fetching them in other browsers (FF & Safari) as anonymous user, I didn't see <---- boost comment line at the end indicating that page delivered is a cached paged --->
Secondly, how do I make sure that gzip version of file is delivered to http request?
I can do some more tests if you want.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedSilly question, but have you altered your .htaccess file ?
Comment #20
kent_drupal CreditAttribution: kent_drupal commentedNot at all silly because I missed it. :)
I kept .htaccess settings from my earlier boost installation.
I am using localhost. Do you think will it still matter to change .htaccess settings?
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedYes and you'll need to check your RewriteBase setting.
Comment #22
kent_drupal CreditAttribution: kent_drupal commentedHi,
I added .htaccess changes generated from default settings under boost.
Didn't have to change any RewriteRule.
I see .gz file generated in cache. Also tested it on pageSpeed. I observed 2 things:
1. In FF, if I enabler Cache, page speed rank is ~78/100. Under Resouces tab, it shows File size = 48k and Transfer size = 8k.
2. In FF, if I disable all Caches, page speed score increases to 98/100. Same values under Resource tab.
Can anybody explain why it's giving better results without browser cache?
Comment #23
kent_drupal CreditAttribution: kent_drupal commentedComment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedPage speed should have a list items as to it's score, but it's not boost relevant, part from that you may have boost working under chrome.
Comment #25
kent_drupal CreditAttribution: kent_drupal commentedI didn't test it under Chrome.
But doing it on Safari now.
Will keep you all posted.
Comment #26
kent_drupal CreditAttribution: kent_drupal commentedSimilar functioning on Safari as well.
Clear cache under performance page, is cleaning all caches which is good.
I am still not sure if this is ready for production site yet.
Comment #27
Anonymous (not verified) CreditAttribution: Anonymous commentedNormally the boost clear cache is split out from the performance page by ticking the box in boost under the cache expiration tab.
Comment #28
kent_drupal CreditAttribution: kent_drupal commentedThough I noticed an unusual behavior.
After boost caching turned ON and sign off , close the browser & then restart the browser.
Clear browser cookies, cache.
So now there's no cache generated yet in boost and browser is also clean.
Now, if start opening pages on site, it caches 2 pages only and rest of them are ignored irrespective of how many times you try, or even on different browser.
All this time, I was browsing as anonymous user but still no cache pages are created under boost dirs.
The only change I did apart from Boost is that I turned Blog comments On. But I haven't visited Blog content yet as anonymous user.
Using FF and Safari. Not sure if this is Boost related or something else.
Comment #29
Anonymous (not verified) CreditAttribution: Anonymous commentedalmost certainly something has trigged the DRUPAL_UID cookie and you should check for it, that will disable both page generation and serving of cached pages and is probably a module assigning you a user id even if anonymous.
Comment #30
kent_drupal CreditAttribution: kent_drupal commentedDo not see DRUPAL_UID cookie set for anonymous user. As soon as I login, I see it and goes off when I log off. I don't think this is the root of above problem.
Besides, this I just installed HTTPRL & Cache Expire & enabled Boost Crawler.
As per instructions, on Cron run it should generate cache but it doesn't seem to be doing it.
I also tried changing a node and saving it, then running manual cron but no luck.
Is this a known issue?
Comment #31
Anonymous (not verified) CreditAttribution: Anonymous commentedNo the crawler doesn't generate a cache ever, it only crawls for pages that have been edited.
Comment #32
kent_drupal CreditAttribution: kent_drupal commentedYou mean it will only crawl pages who's visible content is changed or we can just click edit and save without modifying actual content?
Does crawler checksum old and new file for differences?
Moreover normal boost isn't caching user/login & user/register pages. I tried many times but it's not.
Is it intended functionality or a bug?
Comment #33
Anonymous (not verified) CreditAttribution: Anonymous commentedThe crawler is hooked into most of the functions that edit a page, like posting a comment, deleting content etc... so there is no need for a checksum. Upon any of these action there is an entry in the cron queue table and httprl is used to generate it as an anonymous user.
Comment #34
Anonymous (not verified) CreditAttribution: Anonymous commentedfrom the boost .htaccess rules
It's intentional. Wouldn't want a cached version with someone's username popping up, if by some coincidence the cache was built as they entered the wrong password.
Comment #35
kent_drupal CreditAttribution: kent_drupal commentedAh, I see, this totally makes sense. Thanks.
Comment #36
kent_drupal CreditAttribution: kent_drupal commentedI faced an unusual issue today with Boost.
I have last recommended release installed with BOTCHA 7.14x
There are almost hundred files starting as "boostMxseY", "boostYgRkt", etc.
Any idea what could be causing it?
Comment #37
Anonymous (not verified) CreditAttribution: Anonymous commentedNever used the module myself, but what's in the files ? Having a read through it appear to be javascript spambot protection for forms and I'm guessing there's some element of xml or ajax requests being made, as well as that if it's adding unique fields to forms that differ from the normal one's that are ignored (like login/ registration), then there's quite a high possibility that the form will not work (BOTCHA's description appears to say that it will ignore duplicate form registrations and boost could easily cache a comment/ login on every page form which we've had here before #1616356: Boost Module problem in logged in user and the need to use a register link to post comments, to bypass this).
This should have been a new thread.
Comment #38
kent_drupal CreditAttribution: kent_drupal commentedThe problem with junk BoostZWRse files is resolved here http://drupal.org/node/1890836#comment-6957440.
It was an issue with Botcha module
Thanks.
Comment #39
garbo CreditAttribution: garbo commentedI installed the latest Dev version, uncommented line 330 in boost.module and set the .htaccess rules. But when I test with Pagespeed Insights in Chrome it's still complaining about uncompressed javascripts and CSS files.
Am I missing something?
Cheers,
Bram.
Comment #40
garbo CreditAttribution: garbo commentedp.s. You can see for yourself at http://intermin.bramdeleeuw.nl/
Comment #41
Anonymous (not verified) CreditAttribution: Anonymous commentedBoost would not compress js or css, that would be your apache (or whichever server) setting you are using as it's not running through php. The gzipped part of the module had to be commented out because it only worked in certain server configurations based on the modules loaded and so broke a few browsers including chrome and resulted in blank pages as the first few bytes of the zip file were not sent out. I did the testing and could not find a solution around the issue as it's server based although I may re-evaluate it for apache 2.4 when it becomes more common place.
Comment #42
garbo CreditAttribution: garbo commentedah, appearantly I misunderstood. So I should comment-out line 330 again?
Comment #43
Anonymous (not verified) CreditAttribution: Anonymous commentedIf your particular server is working then there is no need to comment it out as long as it functions cross browser, but it applies only to html files and you will need to look at your rewrite rules and the logs to check the the pages are being served correctly. To compress javascript and css files I suggest that you examine mod_deflate for apache and you can achieve compression without boost for html files although at a slight increase in cpu usage. You need to pay attention to the configuration as otherwise it will try and compress jpgs and pngs and other files which do not compress well.
Comment #44
garbo CreditAttribution: garbo commentedThanks Philip for your info. I will get into it!
Comment #45
znerol CreditAttribution: znerol commented@Philip_Clarke: I've reproduced this issue, especially your finds from #14. It is correct that the current generated htaccess rules depend on
mod_mime
to be present in the apache installation.When I'm not mistaken
mod_mime
is very important for most setups. I cannot think of any case where this module needs to be disabled, rather I think that an apache-configuration without this module will result in all sorts of trouble. IMO we could count on this module being enabled by default.That said I suggest to just document the issue (i.e. serving compressed content with apache requires mod_mime). Also it would be possible to move the
AddEncoding gzip .gz
directive out of theIfModule
condition in the cache.htaccess
. That way users would get error messages when things are not configured properly instead of a gzip-data displayed in a browser window.Comment #46
znerol CreditAttribution: znerol commentedAnother solution would be to do what core does and implement the same checks like core
.htaccess
based onmod_headers
.Comment #47
Anonymous (not verified) CreditAttribution: Anonymous commentedIn the current dev version gzipping was disabled because of the "we can't predict which modules would be installed across many servers", now that you've confirmed the modules, I suggest we just throw the idea away. I've tried various configurations and differing .htaccess set ups with ifModule statements but removed them all because it's an apache module issue rather than boost.
Lighttpd and Nginx can do their own gzip caching so they reduce cpu cycles, it's easy enough to turn gzip on in .htaccess for php, html, js and css files for apache (though at the cost of more cpu cycles and the possibility of making an error with the configuration and trying to recompress jpegs), so I don't believe that gzipping has a place in boost any more because of the module problem, better that boost works consistently across differing servers than trying to force it to work with apache for a reduction in cpu cycles that appears to constantly put delivery of pages to chrome, in particular at risk. It's a substantial amount of server and browser share that is at risk of corrupted delivery or blank pages, not because of "boost" but because of the variance in apache set ups and I just cannot see why we should bend over backwards to compensate for a bug in apache and then field support requests for why boost is not zipping files when a few lines in .htaccess would work and increase delivery speed for other resources on a site.
Comment #48
znerol CreditAttribution: znerol commentedThe drupal-core approach is not too difficult. I propose the following solution:
This is
.htaccess
in drupal root. Note that we simply set the variableboosttrygzip
when both of the following conditions are met: the server hasmod_headers
and the client requests gzip.The cache-
.htaccess
then fixes content-encoding and vary headers when compressed content is to be delivered:This setup works with any combination of
mod_mime
andmod_header
. If the latter is missing, no gzip-content will be served though, but that's exactly what drupal core is doing anyway.Comment #49
Anonymous (not verified) CreditAttribution: Anonymous commentedI'll have to test that later, but I assume that you've tested using chrome ? as that gave the main blank page problem. Also how are you gzipping the files ? have you uncommented the section out from the last dev build.
Comment #50
znerol CreditAttribution: znerol commentedYes.
Yes, patch attached.
Comment #51
znerol CreditAttribution: znerol commentedComment #52
Anonymous (not verified) CreditAttribution: Anonymous commentedI've checked this and I'm afraid it does not work. The good news is that the original bug report I made about gzip not working with mod_headers disabled #1416214-14: Basic gzip support for 7x seems to have been solved in either chrome or apache 2.22 (although that does not mean that the bug would not reoccur in real life across many servers).
I think there is a very simple solution to this as the mod_mime bug is still very much apparent in the latest version of firefox and chrome, which is simply to disable gzip serving in the .htaccess if neither module is present, which I am currently testing.
@zernol it may be that your FORCE_GZIP is the key to the mod_headers issue, the other way around the mod_mime issue may be to add your ForceType directive but this may interfere with the Content-type header. Sorry for the delay, I have a lot of tests to run on various configurations and not being able to reproduce the original mod_headers issue has been a large delaying factor.
Comment #53
Anonymous (not verified) CreditAttribution: Anonymous commentedI've decide to reverse the logic, if mod_mime or mod_headers is not installed then disable. I've also commented the sections and the reason why. The only other modification was to remove Vary Encoding as it appears in the
<IfModule mod_headers.c>
code block above regardless as to whether zipped encoding is chosen or not.
Comment #54
znerol CreditAttribution: znerol commented@Philip_Clarke, thank you for the review.
The reason that Chrome chokes on gzip content when
mod_headers
is disabled is not a bug in Chrome or Apache. Ifmod_headers
is missing,Content-Encoding
cannot be added to the response and the browser is not notified that it needs to decompress the data before attempting to render it. Drupal core.htaccess
implements the exact same check when determining whether gzip-compressed CSS and JavaScript files should be served to the browser - i.e. check whether the browser accepts gzip and also check whethermod_headers
is present. Only when both of these conditions are met, an attempt to serve compressed content (with appropriate headers) is made. If there were bugs in Chrome / Apache in this area, Drupal core would be affected too. I'm sure that the patch fixes the issue. IMO there is not much risk that this problem will crop up again on production systems when this fix gets in.Oh, good catch. It is actually very important that this header is added, regardless of whether the content is compressed or not.
I think the patch from #53 should get in.
Comment #55
Anonymous (not verified) CreditAttribution: Anonymous commentedI've submitted it to bgm to go into dev or production, I'll be adding some documentation to explain that if mod_mime or headers is not installed then gzip disables.
Thank you for pointing us in the right direction, I'd got too bogged down in testing across so many set ups and browsers that I could not see the wood for the trees.
Comment #56
philsward CreditAttribution: philsward commentedAnyone else running into a situation where the first page loads fine, but any subsequent page loads (to anywhere on the site) results in the browser wanting download the gz file instead of rendering it? I've had the problem happen in FF, chrome and IE. Usually a drupal cache flush through admin menu fixes the problem, but it intermittently crops back up...
Comment #57
Anonymous (not verified) CreditAttribution: Anonymous commentedYes many times, the patch is being reviewed to stop this, but you should disable gzipping.
Even when the patch is applied you will not be able to use gzip, your apache configuration is not using either mod_mime or mod_headers or there's a bug in your version of apache, so the first visit creates the gz file but then the web server can't send it correctly, the patch is designed to stop the gz file ever being sent if a problem is detected in the configuration it can't fix an apache configuration.
Comment #58
philsward CreditAttribution: philsward commentedBummer...
I'm showing both mod_mime and mod_headers to be compiled and loaded on Apache 2.2.24 :-/
Comment #59
znerol CreditAttribution: znerol commentedPlease note: After applying the patch you need to recreate all .htaccess files. The one in the drupal root as well as all those within the cache directory. Otherwise the patch will not have any effect.
The mechanism implemented in the patch is the same as the one Drupal 7 core uses for serving compressed js and css files, therefore it should work and break the same way as aggregated and compressed js/css files do.
Comment #60
Anonymous (not verified) CreditAttribution: Anonymous commentedThe patch does try and force the file/ mimetype if the modules are installed which may make a difference but it was apache 2.2.x that the problem first surfaced. Some of the early posts in this thread (up to about 15) detail that files sent out were being sent with incorrect lengths in the headers, but if IE still doesn't respond to the patch then the feature will need to be removed. Someone else will need to test out IE for this as I don't own a windows machine or have access to one.
Comment #61
znerol CreditAttribution: znerol commentedIt would help if you'd try to reproduce your finds from comment 14, then apply the patch, regenerate .htaccess files and retest.
Comment #62
philsward CreditAttribution: philsward commentedIn my situation, it wasn't specific to IE... I initially had the same problem using an incognito window in Chrome.
I updated the core .htaccess to accompany the patch, right after applying the patch. I'll look into the cache .htaccess for possible answers...
Comment #63
znerol CreditAttribution: znerol commentedYou need to make sure that the following fragment is in every .htaccess file in the cache directory:
@Philip_Clarke: If you're referring to that bit when you were saying that "The patch does try and force the file/ mimetype", then that's probably the source of confusion. This fragment is essential configuration when delivering any gzipped content intended to be unzipped by the browser. I initially had problems to understand the difference between
Content-Type
andContent-Encoding
headers. The former refers to the payload (mime-type, character-encoding, etc) while the latter refers to the method used to compress the payload.Comment #64
Anonymous (not verified) CreditAttribution: Anonymous commented@znerol: I was referring to the ForceType Directive. If he removes his .htaccess files in the cache then they should regenerate when his boost configuration is saved. If this problem continues in browsers other than IE then it may be Apache 2.2.x specific and I'll have to load an older VM to test.
Comment #65
znerol CreditAttribution: znerol commentedI do not see the
ForceType
directive in the patch. Therefore I do not understand how that is related to this issue.Comment #66
Anonymous (not verified) CreditAttribution: Anonymous commentedIn the lines above the cache .htaccess file but then for a belt and braces approach then the code
should really be changed to
Although I don't recall there ever having been a ForceType application/gzip which is how the browser appears to interpret it when things go wrong.
Comment #67
znerol CreditAttribution: znerol commentedSuch a configuration actually would be very wrong. ForceType affects the
Content-Type
header and notContent-Encoding
.In my opinion we do not need to make it work on configurations where core would fail to deliver compressed css/js files.
Comment #67.0
znerol CreditAttribution: znerol commentedAdded code example
Comment #68
jetwodru CreditAttribution: jetwodru commentedHi,
Currently I used Authcache with FileCache for Logged-in User whereas Boost for Anonymous users. I found that Authcache does cache for Anonymous users.
I check the cache file generated by Authcache with FileCache is about 10kb++ as compared to Boost which is around 40KB++, so far Boost is running perfectly for Anonymous users but what's bad it does not support compression.
Is it good to abandon Boost and go for Authcache with Filecache completely for the sake of page compression and better bandwidth management ? Sometimes, I'm really afraid of all these patches coz the site would encounter a serious breakdown after upgrade when the latest version does not include the patches made. Thanks
Comment #69
Anonymous (not verified) CreditAttribution: Anonymous commentedThe reason that gzipping was disabled was that without mod_headers and mod_mime, then chrome (but not just limited to that browser) was receiving bad data; blank pages.
However most servers would have mod_deflate installed so there's no reason why a few lines could not be added to your root .htaccess which would turn on gzip compression for the entire site. This method takes up a little extra CPU cycles on the server side but avoids the patching issues.
http://www.jotform.org/general/enable-gzip-compression-using-htaccess/
provides useful reference rules.
Comment #70
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #71
jetwodru CreditAttribution: jetwodru commented#69, thank you. Indeed, Boost is working lightning fast without issues now, I'm also very satisfied with it. However, I'm not so familiar with the technical issues as discussed above and thought that if Authcache would be a better replacement without tweaking and patching since it does support anonymous caching with compression. I don't really know much about the in-depth mechanisms being applied by Boost & Authcache, just configured and they work. Anyway, thanks for the comments.
Comment #72
Anonymous (not verified) CreditAttribution: Anonymous commentedBasically there are lots of different versions of web servers out there. Apache is configured differently by differing hosts. When gzip was implemented we compressed the files and stored them in the cache. We found that in some set ups there were problems resulting in a white screen as the files were unzipped improperly due to the configuration of the server, so the feature was suspended. I have no idea what AuthCache is doing, they may be setting a PHP setting (our cache is HTML so that is out of the question for us) or doing as we did. I'd recommend testing AuthCache with chrome or firefox, if they have storage of files.
With regards to boost just go to the above article, past in the code into your .htaccess file and see if it works, unfortunately there is no reliable way of testing how apache is configured from inside a website and we could not risk breaking a lot of websites when there's a work around that is very low impact and also would speed up delivery of css and javascript files.
Comment #73
kitikonti CreditAttribution: kitikonti commentedThe link from #69 is broken. Is there another resource? I think it would make scene to add this to the Handbook.
Comment #75
tsyvs CreditAttribution: tsyvs commentedBefore thinking of gzip:
1. Check that your server has mod_headers and mod_mime enabled.
2. Navigate to Boost module folder
3. File boost.module:
Uncomment line
boost_write_file($_boost['filename'] . '.gz', gzencode($data, 9));
Replace
with
Replace
with
Replace
with
4. File boost.blocks.inc:
Replace
with
Done.
Comment #76
smitty CreditAttribution: smitty commentedMight it be that #74 is causing the problems described in https://www.drupal.org/node/2421879 ?
Comment #77
mattwmc CreditAttribution: mattwmc commented69 and 75 not working for me. Is there a fix that is understandable anywhere??