Beware because trunk is where the object cache version is too, activate it if you’re brave!

IMHO if you apply the same principle to this issue as you do to the general ‘your .htaccess is out of date cause you turned on mobile support’ situation then I think that’s good enough. Just tell people that they should update it manually based on what’s in the htaccess box. If they notice the problem then they come to the Supercache settings at which point they get the notice.

It might be good to be kind of aggressive about notifying people though (show that message in dashboard and not just on the supercache settings). Now that the setting to not cache logged-in pageviews is there I think a lot of people are completely unnaware that the mobile issue exists because they never see the cached (mobile) version of their sites. My org only noticed cause outsiders were telling us there was a problem, we had hundreds of users all logged in and oblivious to the problem.

Temporary Solution

For anyone else experiencing the problem I came up with some plugin code (functions.php should be a viable place to put it) that fixes the problem temporarily by stopping supercache from ever caching mobile pages.

Here it is: http://pastie.org/788981

Using this means you don’t benefit from caching for mobile users, they will always generate their views fresh, but your normal users won’t ever see the mobile version. It seems that doing this doesn’t interfere with the user-agents that Supercache accounts for (iphone,ipod, android, all the major players), so they will still consistently show the mobile version of the site. For user agents that Supercache isn’t aware of (new ones in mobile-edition or ones you added yourself) they will be sent to any pages that were supercached in the general pool (i.e. normal theme), but if they visit a url that hasn’t been supercached they will see the mobile version.

I’m not sure but maybe using that code inside supercache itself would make sense. Especially if combined with whatever mobile checking you are doing in supercache. I.e. IF mobile-edition thinks its mobile AND Supercache DOESNT think its mobile then don’t cache the file. That situation theoretically shouldn’t exist, and in practice that situation is exactly the one that is creating the bug.

Did you update the user agents in the .htaccess file? I can make the plugin check the list of mobile user agents in that file but I shy away from updating it automatically.

I can’t understand exactly what is happening in the .htaccess file, but it seems like this is a recipe for disaster. It means that if the user agent strings set in wp-cache.php differ from the ones set in the options for WP-Mobile-Edition then those strings that are only in the Mobile Edition settings will effectively get ignored by whatever is happening in .htaccess.

I have a feeling this is what is causing the intermittent bugs we’ve been experiencing. When I try it with my iPhone it works fine because my iPhone user-agent is accounted for in Supercache. But when someone with one of the unsynced user-agents comes Supercache saves the mobile version of the site as a regular cache.

When you first added mobile support, did you just copy the default user-agents from wp-mobile-edition? If so you should at least update the list, as many have been added, notably the ‘Googlebot-Mobile’ user agent, which sounds like it might come by often to cause problems.

Ideally Supercache should recheck the saved list of mobile user agents from mobile-edition regularly to make sure they match. The .htaccess part of Supercache should be auto-generated from that list and the user shoudl be reminded to update their .htaccess if the lists dont’ match.

Hope this makes sense, any insight is very welcome.

I’m going to do some more testing with the debugging, but was wondering if you’ve been hearing about this from other people or have other advice?

Maybe a solution would be to just block all mobile user agents from caching in the “Rejected User Agents” section? Would that work? Maybe just set the DONOTCACHEPAGE constant at ‘init’ if the mobile edition plugin claims its a mobile page?

The plugin did not warn me that compression was enabled. I’ve used earlier versions of your plugin and they worked perfectly in the past. Keep up the good work!