[Plugin: WP Super Cache] Integrated Mobile Theme Support breaks

Have you tried the mobile related filters listed here? Also enable debugging in the plugin as that will help you too.

I prefer to keep discussion to the forum, that means other people will benefit later on.

I hunted all over your site, and could not (and still cannot) find a link to that page.

Well I guess I could spend a whole lot of my time looking all through that, or perhaps you could give me a hint.

What I think must be done is to add a filter that simply stops all caching for the page being requested. Like I would expect that somewhere in your plugin, you must have something like:

if (dont_cache_this_page())
stop_caching();

I just need to trigger that swtich based on the fact that the site is being rendered on a mobile browser or not, and of course, that check has to be done dynamically each and every time the page is loaded.

And allowing a separate cache for the mobile version vs. the standard browser version will not work because the mobile view allows the user to switch to the standard view from the mobile browser (think iPhone) – thus adding yet another possible cache: standard, mobile mobile view, mobile standard view.

And although I know you need to work with lots of different themes, Weaver has tens of thousands of installed sites already. Its new approach to mobile view is as far as I know right on the bleeding edge of theme design, so I may be among the first themes hitting this wall.

I’m just assuming from my own experience that you would know just which filter to add that can give your code a cache/don’t cache check.

And given your main cache competitor seem to be ignoring my requests for information about the same problem, I will be able to recommend your cache to all my users if there is a way around this problem.

Take a look in wp-cache-phase1.php – the mobile functions near the end of that file detect the user agent and then the system looks for an index-mobile.html (new in 1.0 released today).

You should also look in wp-content/wp-cache-config.php where you’ll see a list of mobile user agents and string fragments. The filters on the developer docs act on those.

Of course, you could disable caching of a page BUT if the particular url is cached already and mobile support isn’t enabled then the cached page will be served. It’s possible to stop a page being cached but not possible to stop it being served if it’s cached already.

Try the DONOTCACHETHISPAGE constant. It’s right there in the developer docs. ??

I’m sorry, I apparently am not stating the problem clearly enough. I don’t think any of those things you pointed out will help the problem.

Here’s the behavior required.

1. The user visits the site from a non-mobile browser
a. The cached pages are served
b. Pages added to cache in standard fashion

2. The user visits the site from a mobile browser
a. The site is served dynamically –
no cached pages are served
b. The pages are not cached (no new cached pages generated)

From what I’ve discovered by some code reading, if ‘wp_super_cache_error_checking’ returns false, then no cached pages will be served, and no new cached pages will be generated. Is that true?

That would mean I could potentially add another filter for that that could return false if the device is mobile, thus stopping all cache action.

A followup on the mobile device support. If I understand the mobile support code, what happens is this:

1. A mobile device is detected.
2. A new $cache_key is generated in response, resulting in different names for the cached pages
3. A different set of cached pages are generated/delivered to the mobile device.

That solution fails with my mobile support because depending on the user’s choice, either a mobile page will be delivered, or an alternate full size page will be delivered to the mobile device. Both of these pages look different than the standard browser view. Extensive research with users indicate this kind of behavior – the ability to switch between a mobile specialize view, and a “pinch/expand” standard view on the mobile device are very important to the end user. It is that behavior that breaks the strategy for mobile devices as I understand it.

So you don’t want the mobile view cached at all?

When you enable mobile support in the plugin it adds a list of user agents to the rewrite rules so those browsers are handled by PHP. Then in wp-cache-phase1.php it finds that the visitor is an “anonymous” visitor who isn’t logged in or left a comment and tries one last time to serve a supercached cache file. In this code it detects the visitor as a mobile user and (by default) returns “mobile”. This is added to the cache filename making index-mobile.html (.gz for compressed html) and then served to the visitor.

If there’s no cache file then the page is handled by the system, and your theme should display a mobile friendly theme, and cached with the filename index-mobile.html (.gz…)

If this isn’t happening try the debug system in the plugin as that will tell you a lot about what’s happening.

Let me re-ask the question. Sorry I confused things with my follow up comment.

From what I’ve discovered by some code reading, if ‘wp_super_cache_error_checking’ returns false, then no cached pages will be served, and no new cached pages will be generated. Is that true?

No, that has nothing to do with generating cached pages or serving them.

After another day of considering this problem, and working with some of my testers, I’ve determined this incompatibility is even more dire that I thought.

Currently, it is possible for Weaver II to need to deliver to simultaneous different visitors FOUR different views of the same page: standard, iPad, smartphone compact view, smartphone full view. The next version will allow up to THIRTEEN different views. Thus, to do this properly, it would take THIRTEEN different caches – iOS devices, Android devices, generic mobile devices, each in two different views.

I strongly believe that while Weaver may be cutting edge on this issue right now, in the near future it will become common for many WordPress themes to support different views views based on specific devices – even if that is just the iPad.

Please trust me – this will become a significant issue, and I think it is essential that your caching plugin provide an easy to use and understand API for themes to help control this vital functionality.

I have some specific proposals, and would greatly appreciate it if you could read my take on the issue here: https://weavertheme.com/weaver-caching-and-mobile-devices/

The plugin should be able to handle what you want. Unfortunately I don’t have time to read that post right now, I’ll have a look this evening. Take a look again at the wp_cache_check_mobile function in wp-cache-phase1.php. There’s no reason you couldn’t have 13 different index.html files in each supercache directory:
index-iphone.html
index-android.html
index-ipad.html

etc.

This is exactly what this was built for. If you can, send me a dev version of your theme and I’ll try it on a test site. As long as your list of devices matches the ones in the plugin it should be easy to get working.

That is not what the theme want or needs to do.

It does not, nor should it need to, have a separate .html file for each view. That is not how the pages are built. All the page names are the same for every site, they just don’t get the same content depending on the device being used to view the site.

Or am I misunderstanding, and supercache automatically generates the index-iphone.html, index-android.html, etc? If that is the case, then that really isn’t very clear anywhere.

My impression of reading the code/doc, is that the function specifying my own names in wp_cache_check_mobile is to give an alternate page I know about which is not how the theme works.

LOL, you’re totally misunderstanding. Supercache will automatically generate the right cached file for each device IF you create groups for each device. See the function wp_cache_mobile_group in wp-cache-phase1.php

You can use the cached_mobile_groups filter to modify that list of groups. See the developer docs above for more info.

Yes, docs are sorely needed for all this but there hasn’t been time to do it or motivation.

No, wp_cache_mobile_group does not do what needs to be done. One could add whatever names one wanted, but from how I read the code, that function is driven from $_SERVER[ “HTTP_USER_AGENT” ]. The problem is that for any given user agent value, there will be TWO different views. So it is not possible to create two different caches for a single instance of a mobile device browser – assuming I am reading this line:
return $cache_key . ‘-‘ . wp_cache_mobile_group( $user_agent );
correctly. $user_agent, as far as I can tell, comes only from the HTTP_USER_AGENT value.

Instead of using the concept of adding more groups to the list of cached user agent determined browsers to create new caches, it would be very useful to have the opposite – don’t use the cache. Sort of kills the purpose of caching, but at least the sites would display correctly.

Ah ha. So you probably need to modify the cache_key using a WP Super Cache plugin in wp-super-cache/plugins/ – your theme will have to copy the file in there as those files are loaded when the phase1 file is loaded, BEFORE WordPress is loaded.

The function will have to I guess use the user agent and whatever other detection your theme does.

That will generate legacy files so if you have lots of visitors those files need to be cleaned up regularly as they don’t scale up quite as well as supercache ones. (Each file needs to be opened when doing garbage collection)

Sorry. I am 100% convinced that more and more themes will be having this issue – generating multiple views from the same mobile browser and the same session. Just today I added essential user features that will mean there can be THREE or more views from the same visit from the same browser. At this point, I think it is up to you to provide the tools for modern themes to handle this situation easily.

While not ideal, this whole issue could be solved by allowing a setting to disable caching when a mobile agent is detected. Admittedly your list and my list won’t be the same (I just added a whole bunch of new tablets, for example), but it would be better than nothing.

At this point, I am going to add a notice to my theme that it will not work with WP Super Cache, and suggest an alternative cache that does have a runtime API to handle the problem.