Weaver II Compat (Mobile Flavors)

[jaswrks]

See: http://www.websharks-inc.com/product/quick-cache/#comment-26

Bruce Wampler writes:

I wasn't actually doing anything in my theme other than providing a copy/paste list of user agents for my users to paste into Quick Cache user agent list option. That was the easiest solution for me.

I can see it would be possible to add a filter to auto-add to the exclude_agents option, but I can't see where the free version then processes that option, and I don't yet have the Pro code to see if it is there.

So, if exclude_agents is simply a list of user agents (separated by , or newline?), and the free version processed that option, it would be easy for me to add a filter for METHOD . '__default_options' to add the user agent list. I assume this would work for any user agent based theme.

But the real issue is that since my theme is generating different output based on user agents (there can be 7 different variants of generated code depending on the device detected - desk top + 3 screen sizes each for iOS/other device), the wrong cached version was getting returned to the visitor depending on which browser visit caused the cache update.

Since you understand how the cache works so much better than I, I certainly am open to any other mechanism that would trigger delivery of the proper version. I suppose, ideally, Quick Cache could generate all 8 caches, and a user agent based theme/plugin could deliver some value to Quick Cache to identify which version to deliver. But just delivering the desktop version cache is mostly acceptable now, which I've been using the user agent list to accomplish.

Thanks so much for your response. For a long time, I've Quick Cache has been my #1 caching recommendation for its reliability + ease of use.

[jaswrks]

A hook/filter won't work for this due to WordPress loading the advanced-cache.php file VERY early-on; before any themes/plugins; and before the do_action() function is available.

I'm looking at other alternatives in the free version of Quick Cache.

[jaswrks]

Will consider setting up a plugin architecture for Quick Cache itself in a future release.

[jaswrks]

@ Bruce Wampler

Here is a short-term solution for you that might work. Please confirm; thanks!

Quick Cache (like many WP caching plugins) has always supported a runtime PHP Constant named: QUICK_CACHE_ALLOW and/or DONOTCACHEPAGE works too.

I'm a plugin developer. How can I prevent certain files from being cached?

<?php
define('QUICK_CACHE_ALLOWED', FALSE); // The easiest way.
// or $_SERVER['QUICK_CACHE_ALLOWED'] = FALSE; // Also very easy.
// or define('DONOTCACHEPAGE', TRUE); // For compatibility with other cache plugins.

When your script finishes execution, Quick Cache will know that it should NOT cache that particular page. It does not matter where or when you define this Constant; e.g. define('QUICK_CACHE_ALLOWED', FALSE); because Quick Cache is the last thing to run during execution. So as long as you define this Constant at some point in your routines, everything will be fine.

Quick Cache also provides support for define('DONOTCACHEPAGE', TRUE); which is used by the WP Super Cache plugin as well.

Another option is: $_SERVER['QUICK_CACHE_ALLOWED'] = FALSE. The $_SERVER array method is useful if you need to disable caching at the Apache level using mod_rewrite. The $_SERVER array is filled with all environment variables, so if you use mod_rewrite to set the QUICK_CACHE_ALLOWED environment variable, that will end up in $_SERVER['QUICK_CACHE_ALLOWED'].

All of these methods have the same end result, so it's up to you which one you'd like to use.

The idea I propose for as a short-term solution, is to take your existing list of User-Agent exclusions and instead of asking a site owner to copy/paste these into Quick Cache, simply run your own detection against $_SERVER['HTTP_USER_AGENT']. If it matches a User-Agent that should be excluded, set this PHP Constant at anytime you like, at any place in the code that powers your theme.

define('QUICK_CACHE_ALLOWED', FALSE);

• This works even in the LITE version of Quick Cache.

---

I will come back to this issue in the future and update you regarding our ideas for a plugin architecture. If you (or anyone else) would like to make suggestions, I would be happy to hear them.

[weavertheme]

This sounds promising - it will be trivial for me to add that define when I detect a mobile device.

But - does that just prevent rebuilding the cache page in those cases? Does it leave any existing cache page intact?

So if there's a cached page built by a desktop visit, that page will remain intact and no new page built when the QUICK_CACHE_ALLOWED is false? Thus, this is a solution that will deliver cached pages for desktops, but deliver dynamic pages when it is false? That would be terrific for now.

[jaswrks]

Does it leave any existing cache page intact?

Right, any existing cache would remain intact. No harm done.

So if there's a cached page built by a desktop visit, that page will remain intact and no new page built when the QUICK_CACHE_ALLOWED is false? Thus, this is a solution that will deliver cached pages for desktops, but deliver dynamic pages when it is false? That would be terrific for now.

Exactly. Glad to hear that might work for you :-)

---

I do still think a feature built into Quick Cache for this would extremely helpful. The trend for mobile sites is moving more toward media queries to detect screen size; which would handle this via CSS alone. However, having the ability to setup groups of the cache based on a configuration of User-Agent patterns could still be helpful in many cases where there is a specific version of the site built specifically for a certain device.

It's a complex issue. We may not go into setting up the full set of functions to do cache grouping in the Quick Cache core code, but a plugin architecture could make accomplishing this much easier in a future release.

[weavertheme]

This almost works, but not quite. What happens:

Only the desktop view (when I don't set QUICK_CACHE_ALLOWED to false) will generate the cached page.

Mobile views don't set the cache, BUT -- they are still delivered the cached page from the desktop view - and not non-cached, dynamic page.

So, visitors from a mobile browser get the desktop cached view, which isn't awful, but is not right. Without setting the QUICK_CACHE_ALLOWED, the desktop view will sometimes get the mobile view, which is usually bad.

It would be much better if when QUICK_CACHE_ALLOWED is false that no cached pages were delivered.

[weavertheme]

We cross-posted! It is true most new WP themes are using pure responsive desing (@media), and my theme does this, too. But I do also use User Agents (which allows cool stuff for iOS, for example). And I'm pretty sure most of the plugin mobile theme replacers (like JetPack's, I'm pretty sure) are User Agent based.

[jaswrks]

:-) Sure, and I can understand that also.

Setting QUICK_CACHE_ALLOWED to a false value prevents a cache "write". Meaning, the page that is being loaded when this is defined, will never make it into a cached version; because QUICK_CACHE_ALLOWED prevents a cache file write.

Hmm, I see there is still a problem though. The desktop view could still be served to a mobile device.

[weavertheme]

That is exactly what happens - the desktop cached view is really always delivered to the mobile devices once a desktop visit has generated the cached page.

[weavertheme]

If I clear the cache, the mobile view works exactly as expected - there is no desktop cached version. But as soon as I view from the desktop, that generates the cached page, and then the mobile device sees that version.

[jaswrks]

Right, I understand now. Thank you.

So, this is not going to work for you. Let me try to find a better way to deal with this. Ideally, a way for you to break things down also, so that each of these variations are actually being cached, instead of just excluded completely for the mobile devices. I will report back tomorrow morning on this.

[weavertheme]

I'm off to dinner, but just one final note - I just double checked with the old version, and if the User Agent list is set, everything works exactly as desired - mobile browsers get a non-cached, dynamic page, and the desktop gets the cached page.

I'm guessing the QUICK_CACHE_ALLOWED is tested after the User Agent list (late instead of early), but if it could work the same, that would solve things. But if your caching setup has to go before the theme loads, there can't be stuff in the theme. But perhaps something from a plugin that could fire before the cache (by using priorities, perhaps - make my plugin fire before yours?)

Or I could just tell all my users to get your Pro version, but build in a filter for your options so they don't have to manually copy/paste as I described earlier.

By the way, the users on my support forum are very grateful we are working on this issue cooperatively.

[jaswrks]

Coming in the next maintenance release.

Example plugin file: https://github.com/WebSharks/Quick-Cache/blob/000000-dev/quick-cache/includes/ac-plugin.example.php

[jaswrks]

@weavertheme The new plugin architecture was designed initially for site owners like you, who need more control over the way cache groups are formulated; giving you the ability to create salted variations of the cache.

Here is a quick example that I wrote and tested in the development version of Quick Cache. https://github.com/WebSharks/Quick-Cache/blob/000000-dev/quick-cache/includes/ac-plugin.example.php ~ This will work in the LITE version of Quick Cache also; once this is released.

To implement this in your case, you would take the contents of this file; modify the salt shaker to your liking, and save it here: /wp-content/ac-plugins/my-ac-plugin.php (giving the file whatever name you like, so long as it ends with .php; and it MUST go in this special directory).

I would suggest that your theme handle the creation of this file dynamically, but of course that's up to you.

Very little documentation on this currently, so please let me know if there are questions :-)

[jaswrks]

See also: WebSharks/Quick-Cache#17

[jaswrks]

Plugin Architecture: This was released officially in Quick Cache and Quick Cache pro v131128 http://wordpress.org/plugins/quick-cache/changelog/

[weavertheme]

I will try to test this soon - the holiday weekend might slow me down.

But assuming this works as stated, this will certainly mean that Quick Cache will be by clear #1 recommendation to my users since it will then be caching mobile devices as well as desktop.

A possible new issue just occurred to me - do you know how this might interact with CloudFlare? CloudFlare says they work with WP cache plugins, but I wonder if it is refined enough to handle caches for multiple devices? Will CloudFlare interaction have to be handled in the ac-plugin code? Using the old technique of not caching mobile devices seems to work with CloudFlare.

I do know CloudFlare has become an important issue since at least some hosting companies (Blue Host, for example) are now pushing the use of CloudFlare for sites they host.

Pure responsive is certainly simpler to cache, but there are things one can do with User Agents to get really customized sites for specific devices that pure responsive can't handle. Reduced content is a good example - sending excerpts vs. full posts, smaller or no images, not sending sidebar content.

[jaswrks]

CloudFlare, good question. Forking a new issue for this here. See: https://github.com/WebSharks/Quick-Cache/issues/22

[jaswrks]

But assuming this works as stated, this will certainly mean that Quick Cache will be by clear #1 recommendation to my users since it will then be caching mobile devices as well as desktop.

Sure :-) Please report any trouble. Very welcome. Thanks for working with us too, we appreciate it!

[weavertheme]

Seems to work perfectly - I'd forgotten that the mobile view from each device has two different views - a mobile view, and a desktop view (slightly different than the standard desktop view). There are links on each to switch the view on the mobile device - a common practice in User Agent based mobile themes. And that was trivial to add to my plugin file.

I plan to support this via an existing add-on "extras" plugin to my theme so I don't need to go through any theme review to get it active. (And if you have an affiliate program for QC Pro, I'll add a link to it on the relevant options page in my theme.)

The only mod to the interface might be to add an option to specify the ac-plugins location which would allow users to add the plugin file to their /uploads directory if they wanted - would also provide an alternate way for themes/plugins to provide support without adding the auto-setup in the theme or plugin.

[jaswrks]

Seems to work perfectly - I'd forgotten that the mobile view from each device has two different views - a mobile view, and a desktop view (slightly different than the standard desktop view). There are links on each to switch the view on the mobile device - a common practice in User Agent based mobile themes. And that was trivial to add to my plugin file.

Awesome!

I plan to support this via an existing add-on "extras" plugin to my theme so I don't need to go through any theme review to get it active. (And if you have an affiliate program for QC Pro, I'll add a link to it on the relevant options page in my theme.)

No affiliate program yet, but that's something we're taking a look at for sure. I'll keep you in mind for this :-)

You can promote s2Member if you like though :-) See: http://www.s2member.com/affiliates/

The only mod to the interface might be to add an option to specify the ac-plugins location which would allow users to add the plugin file to their /uploads directory if they wanted - would also provide an alternate way for themes/plugins to provide support without adding the auto-setup in the theme or plugin.

That's a good idea. @raamdev This your call, but I think the /wp-content/ac-plugins directory sets a good permanent standard as the location for these plugins. Like /wp-content/mu-plugins or /wp-content/plugins; plugin developers can count on this location (that's a good thing IMO).

However, I also think @weavertheme makes a good point about this being more difficult from a user's perspective. Perhaps we could add support for a configuration option that would also allow for a custom series of plugin locations (perhaps one per line); or a custom directory that might contain AC plugin files; like the /uploads directory. Although, there could be some security issues to consider in the /uploads directory.

[weavertheme]

Just FYI:

http://weavertheme.com/weaver-ii-quick-cache/

[jaswrks]

@weavertheme Awesome! :-) Thank you very much. We'll be sure to recommend your theme too when an opportunity arises.

[jaswrks]

@weavertheme Hope this finds you well :-)

Just wanted to shout in your direction again. We've had some reports of a conflict between pagination in your theme and Quick Cache. It seems to be occurring mostly in premium themes; but since we worked with you in the past I wanted to see if you would mind sending over a copy of the most recent release of Weaver for us to test with?

If so, we'll reciprocate of course. You can send it here if you're interested. websharks@websharks-inc.com

[weavertheme]

Attached. We've not revised our Quick Cache code (for mobile devices) since we last worked with you, nor anything to do with the pagination code (which is generated by WordPress core in any event.)

Our Quick Cache code is found in our plugin - Weaver II Theme Extras. The latest version of that is available from WordPress.org plugins. The code is in the shortcodes.php file.

JasWSInc mailto:notifications@github.com June 19, 2014 at 3:53 PM

@weavertheme https://github.com/weavertheme Hope this finds you well :-)

Just wanted to shout in your direction again. We've had some reports of a conflict between pagination in your theme and Quick Cache. It seems to be occurring mostly in premium themes; but since we worked with you in the past I wanted to see if you would mind sending over a copy of the most recent release of Weaver for us to test with?

If so, we'll reciprocate of course. You can send it here if you're interested. websharks@websharks-inc.com mailto:websharks@websharks-inc.com

— Reply to this email directly or view it on GitHub https://github.com/websharks/quick-cache/issues/12#issuecomment-46621894.

---

Bruce Wampler, Ph.D.

Software developer Creator of first spelling checker for a PC Creator of Grammatik(tm), first true grammar checker e-mail: weaver at weavertheme dot com

[jaswrks]

Great! Thanks @weavertheme :-) At this point we aren't sure what the problem really is; it could very well be with Quick Cache itself. Your theme is only one that we have seen this report on, but it seems like a great place to begin the hunt. Something we are missing somewhere :-) Now we can take a closer look and try to reproduce the issue being reported.

ASIDE: I updated your account at websharks-inc.com to provide you with access to Quick Cache Pro for your own personal use in whatever way you like. Your username over ther is weaver. See: http://www.websharks-inc.com/wp-login.php

[weavertheme]

THanks.

If you find anything in the theme, let me know. Does seem puzzling - didn't change any of our code, nor get the reports until WP 3.9.1.

We pretty much exclusively recommend Quick Cache for our users, and most people seem to switch.

Bruce

JasWSInc mailto:notifications@github.com June 19, 2014 at 4:45 PM

Great! Thanks @weavertheme https://github.com/weavertheme :-) At this point we aren't sure what the problem really is; it could very well be with Quick Cache itself. Your theme is only one that we have seen this report on, but it seems like a great place to begin the hunt. Something we are missing somewhere :-) Now we can take a closer look and try to reproduce the issue being reported.

ASIDE: I updated your account at websharks-inc.com to provide you with access to Quick Cache Pro for your own personal use in whatever way you like. Your username over ther is |weaver|. See: http://www.websharks-inc.com/wp-login.php

— Reply to this email directly or view it on GitHub https://github.com/websharks/quick-cache/issues/12#issuecomment-46626566.

---

Bruce Wampler, Ph.D.

Software developer Creator of first spelling checker for a PC Creator of Grammatik(tm), first true grammar checker e-mail: weaver at weavertheme dot com