W3 Total Cache and WordPress Mobile Pack?

I think I can check for the UA prefixes in the .htaccess too. I’ll need to do some testing though.

Just checked in support for mobile prefixes. I added a new filter, “cached_mobile_prefixes” and added a second parameter to the update_cached_mobile_ua_list() function for the prefixes. It’s an optional parameter.

It will display a “Rewrite rules must be updated” message on the admin page currently. I’ll get around to doing an auto update later.

In general, if the mobile plugin is powerful enough and does per-device adaptation, you would need to use a cache key per device. My experience is that most plugins produce only 1 output. The most advanced like the Mobile Pack and Mobilepress have 2 or 3 presentations and all devices fall in one of those groups based on the features. My suggestion is that you do the same, i.e. define some groups for devices and use a key for those. This will reduce the cache replication and the produced pages will still be good enough.

At this stage we have a separate file to manage device group detection, see group_detection.php, but we are thinking of bringing together these functions in the lite_detection and make it an integral part of the plugin (rather than the themes as it is now).

The way I’ve done it now in the mobile pack I am completely overriding your detection (i.e. the admin will NOT turn on the mobile checkbox in the admin and the mobile pack plugins in automatically using your add_cacheaction()), so I am not sure if I need all these filters that you are adding. From my perspective, unless these filters let the other plugin affect how you cache the files, I do not need them, as I am happy to use my own detection. My view is that the detection should be in the mobile plugin and your cache plugin should offer a way to plugin (as you already do with add_cacheaction); anything that you do beyond that is a nice-to-have for plugins and themes that do not want to deal with detection (although IMHO they should!).

Finally, about modifying the .htaccess, adding checks such as the presence of the UAProf header is very simple and yet will catch most mobile devices that respect the WAP 2 requirements (not iPhones and Androids, I’m afraid) and that is still the vast majority of the devices on the markets worldwide.

donncha – if you think you will add a function that would allow a plugin like WPMP to update the user-agents and prefixes (as you already do) and then force an update of the rewrite rules, I think that will be interesting for us to use.

Either way, we would appreciate if you would refer to our plugin for the improvements you brought into Super Cache. We want to release a new version of out plugin to use the actions around the weekend as well, so your mention would be very welcome.

Would you mind giving me example mod_rewrite code to check for the UAProf? This is the first I’ve heard of it.

I’ll add a group variable to the plugin, but leave it filterable so plugin authors can modify it. By default I’ll put everything in the one group. I’d rather the plugin authors decide on the capabilities of their plugins rather than the caching plugin.

Sure, I’ll definitely be referring to your plugin in the next release. I appreciate all the help.

donncha the idea of one group and then letting plugin authors to manage them sounds great. Allowing them to “push up” the rules to Super Cache and then Super Cache to suggest the update in the rewrite would be the best.

Here is an example of rewrite rules, I just tested it on my Apache 2 server:

RewriteEngine On
    RewriteCond %{HTTP:X-Wap-Profile} ^[a-z0-9\"]+ [NC,OR]
    RewriteCond %{HTTP:Profile} ^[a-z0-9\"]+ [NC]
    RewriteRule .* https://example.com/mobile_user_see_here [R,L]

I am sure you understand everything, but for the sake of clarity the two conditions check that the header “X-Wap-Profile” OR “Profile” are set. To be honest all you need to check is if the header is set, but since I could not find a better way I used what are meant the be the very first characters (from experience the most common is a proper URL, sometimes starts with a ” other times just with the hostname).
I am also setting the NC (nocase) in case of wacky starting HTTP strings. I’ve seen a few rare ones.

For Apache 2.2 you might also add the NV flag, although I do not think it will ever make any difference.

Thanks, those rules look easy to implement!

Here’s the groups changeset. I added the groups as a param to the update_cached_mobile_ua_list() function as well as adding an appropriate filter to modify them.

And here’s what you’ve been looking for.

This changeset adds the function wpsc_update_htaccess() which will update the rewrite rules after you’ve called update_cached_mobile_ua_list() with the new browser, prefix and group list.

It needs testing but works on ocaoimh.ie

I’ll try and look at it tomorrow or Friday. Thank you.

Just added the rewrite rules for the WAP and Profile checks.

The plugin won’t complain if they’re not there but they’ll be added as soon as someone clicks the “Update mod_rewrite rules” button. That’ll be everyone who upgrades …

Hey guys,

So what would be the requirements for someone trying to make this work. Would it be the following?

1) Intercept cached_mobile_browsers & update_cached_mobile_ua_list and modify based on the user agents the plugin supports? Do these have to be complete UA strings, or will partial strings work as well?
2) Call wpsc_update_htaccess() whenever these change in the admin panel?

Is that basically it? Any gotchas to watch out for? Thanks, I’ll try and update WPtouch today.

1. The mobile_browsers are mostly complete strings, but it’s not a requirement as the check is for .*string.* – it can be partial strings but be careful about matching desktop clients!
2. Yup, that’s basically it. You have to obviously check those functions exist first. Also, I just realised the wpsc_update_htaccess() function doesn’t check if .htaccess is writeable. I’ll have to add that.

I also added support for UA prefixes. It’ll match a 4 char prefix at the start of the user agent. Look for $wp_cache_mobile_prefixes in wp-cache.php

1. Ok. We mostly check for partial, i.e. “iPhone” instead of the huge user agent string with mobile safari in it, that way it doesn’t stop working when the mobile safari version number changes.

2. Any chance calling wpsc_update_htaccess is going to bork anything, or are you pretty confident with it? If we don’t call it, is there some kind of notification in WP Super Cache that the rewrite rules need to changed so they can do it there?

Thanks.

1. Yeah, I use “iphone” too. but the prefixes are even shorter and I presume match a lot more mobile mobile browsers. I’m just working off Andrea’s code.

2. It could break things. I only wrote it yesterday and it works on 2 blogs I tried it on but that’s why I need people to test it and hammer on it!

If you don’t update the .htaccess there will be a warning in the Supercache admin page so the user will at least see that!

Ok great, thanks.

On another note, I tried installed WP Super Cache on my local machine with MAMP and it throws a 500 internal error. I think I narrowed it down to the fact that there’s a space in the path (Development Environments).

RewriteRule ^(.*) /Users/duane/Dropbox/Development Environments/Duane/MAMP/htdocs/temp.duanestorey.com/wordpress/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]

Putting quotes around the path seemed to fix it:

RewriteRule ^(.*) “/Users/duane/Dropbox/Development Environments/Duane/MAMP/htdocs/temp.duanestorey.com/wordpress/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html” [L]

Not sure if that’s the right way to do it, but if you agree this is a problem would be great to have that updated eventually, as I know quite a few people that do most of their plugin development on local machines on a MAC with MAMP instead of live servers.

Thanks! I’ll start those changes now and see if I hit any issues.