-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Compatibility with gzip_static of Nginx #236
Comments
Also, for future reference, and if anyone still forced to use Apache: https://gist.github.com/bhollis/2200790 Above method should work with this config too. |
@sous-studio Thanks for sharing 👍 |
You're welcome! :) Actually, feels kind of weird - first time for me to share my code with community. It is great responsibility... |
If you decide to add this function, here is an example of options code to add. menu-pages.php:
quick-cache-pro.pot: msgid "GZIP Static Compression" msgid "Use server-side GZIP compression of static files?" msgid "Tip: For the situation when you would d like to have Quick Cache store compressed copies of cached files, next to original files, for later use with something like gzip_static (Nginx). In Nginx, for this to be effective, you should define msgid "No, do not store compressed copies of cached files." msgid "Yes, store compressed copies of cached files.', plugin()->text_domain)." quick-cache-pro.inc
The rest is depends of whether you added real_unlink function from above, or not. If you did, you should just replace old unlink functions everywhere to new one and simplified. Eg.
instead of
Otherwise, you should add something like:
or
or with throw error, if you like. |
@sous-studio Thanks! Hey, I'd like to invite you to contact me through this form; should you be interested in joining our team. Please see: http://www.websharks-inc.com/bizdev/ Any further details about yourself would be great; or even just some links to your work would be nice! Mostly though, just so we can connect privately :-) |
Hey! :-) OK, I sent my details there. On 11.07.2014 20:31, JasWSInc wrote:
|
Great, thanks! I will be in touch shortly :-) |
Hey @sous-studio, Thanks so much for the feature request and all the code! I'll tag this issue as |
Hey, Raam, :-) Always welcome. In fact, I do believe we could optimize QC's code much farther, and add some features like Database Cache, Object Cache, .MO cache and stuff like that. Limits are set only imagination. |
@sous-studio Thanks! Yes, I have many feature requests open here. If you have a few ideas for new Quick Cache features that are not already in GitHub, I'd love to see you add them in here so that I can start tracking those ideas. You can post new feature requests here. Also, in case you're interested in testing beta releases of Quick Cache before the official version comes out, please sign-up to be a beta tester here. :) |
+1 |
Hey, Raam! :-)
As promised, here are full list of my modifications. Done for personal use, so sorry, if a little bit informal.
I've enabled gzip_static, I found it could be a perfect addition to my favorite Quick Cache Pro plugin. Compress all at server, perhaps via cron (although, I do believe there is more elegant, yet not investigated by me, solution of inotify), disable otf compression and you'll reduce CPU load.
What were the caveats?
Naturally, if we gzip all qc's cache, and then cache something with qc (or purge the cache, for that matter), *.html files are all get updated, but Nginx is not aware of that - it just knows, there are *.gz files next to *.html's, which it takes and serves to an unsuspecting user, resulting in old (until the next cron) content to be displayed.
Aha, I thought, I should simply analyze qc's code, find the place responsible for cache clearance, and add "unlink [filename].gz" to that, which I've done in the following code:
quick-cache-pro.inc: @SInCE 140422 First documented version.
this beautiful piece of code (wipe_cache function), we replace with the following code:
esentially, fixing the problem. I do agree, that this fix is quick-and-dirty, and more logical solution would be to include exception catch, like this:
and perhaps increment $counter, or better yet, introduce second counter variable, that would help us to established how many files of cache and how many of their gzip counterparts were purged during "Clear cache", but that is out of our scope here.
So, JIC, I've grep quick-cache-pro.inc for other possible cache clearing function. To my deep surprise, I've found 13 in total; minus one, which unlinks advanced_cache_file (eg. not related here).
This seems too me a bit much, but later about it.
So, we see another piece of "@var $_dir_file \RecursiveDirectoryIterator For IDEs.", which we change in exactly same way as previous:
Next function in question is wipe_htmlc_cache. It is responsible for wipping out of HTML Compressor's cache files. I personally don't use it, since it often breaks layout, yet, if you do use, you should apply this fix:
Even easier, no need to bracket the if statement, just add unlink code. Another function comes up - clear_cache - to "Clear cache for current blog". As before, we just modify (add) one line:
Clear_htmlc_cache - another repeat, so to say, gets modified like this:
Purge_cache for current blog - folks, do we really need to repeat our code in every single function?
Now comes auto_purge_post_cache - as title says, with similiar fix:
And for home page, comes auto_purge_home_page_cache:
Oh, of course auto_purge_posts_page_cache:
Auto_purge_author_page_cache - author's page gets cached too, you know?
So do post terms, in auto_purge_post_terms_cache:
And, finally, cache for user, in auto_purge_user_cache:
Now, for simplification of changes, I would propose using something unified, perhaps, after adding $options['gzip_static'] option, something like that:
..
Now this is just a quick code, untested, but I believe in the right direction.
Anyway, Cache is cleared, life is great! :-) But, huh, what will happen if qc removes cache? New pages will not have gzipped version, hence we'll have to wait for cron, or send over uncompressed data, or enforce it somehow...WHY!?
Solution is in /wp-content/advanced-cache.php
advanced-cache.php: @SInCE 140422 First documented version.
Or, to be exact, in this line:
We use gzencode, to compress existing data (which is about to become a file), add '.gz' extension, and write side by side!
Actually, we can add here some error-control, JIC file cannot be overwritten for some reason, maybe something like this:
So, what do you think?
The text was updated successfully, but these errors were encountered: