Perhaps one of the most important new features in Weaver II is the automatic support for Mobile devices. Weaver II’s mobile support is cutting edge, and even more state of the art mobile features are planned for the next release 1.1 release.

The realization that integrated mobile device support should be included with each and every WordPress theme is one that will likely gather steam in the near future. Unfortunately, there is a significant current problem with integrated mobile device support: caching plugins.

As you may know, there are WP caching plugins that will create temporary static versions of the pages on your site. These static pages can be delivered to the visitor much faster than dynamically generating the page on the fly. The problem is that the caching plugins don’t know how to handle having several multiple versions of any given page.

Consider this scenario – which is the current state of Weaver II’s mobile support. For any given page on the site, there will be no less than FOUR different versions that need to be served to visitors at the same time:

  1. The standard view – generated for standard browsers on desktops and notebook computers
  2. The tablet view – generated for touch screen tablets such as the iPad.
  3. The compact mobile view – generated for typical smartphones
  4. The full size mobile view – generated when the visitor switches from the compact mobile view to a full size representation by touching a switch view button.

And in the next version, even more specialized views will be added for mobile devices – each which may include a button to toggle to a different view base on the whim of the visitor.

  1. Standard browser view
  2. iPad Specific Views – full view, compact view
  3. iPhone/iPod Specific Views
  4. Generic Tablet views
  5. Generic smartphone views
  6. Android Tablet views
  7. Android Smartphone views

That is a total of at least 13 different views that can be delivered by the theme to visitors – all possibly at the same time. For a caching plugin to work properly, it would have to be able to create and deliver 13 different cached versions of the site – and which version needs to be delivered can only be determined by the theme itself.

Currently, the existing cache plugins seem to be able to deliver a single view easily, and a single alternate mobile view. And there is no simple mechanism for a theme to directly interact with the caching plugins.

Given the growing importance of mobile devices, and the inevitable rise of themes with multiple simultaneous views of a site, it seems essential that the major caching plugins provide programming hooks with themes to support this. Here’s my proposal (in somewhat technical terms):

  1. WP Page Caching plugins should provide an API for themes to help determine which page version is currently being requested – probably by a filter or action. Because of various factors, only the theme itself can determine which version needs to be served. With Weaver II, for example, which page version to deliver is determined by a combination of POST/GET values, cookies, and the HTML user agent value – all which must be evaluated before any content is served.
  2. A Simple Minded Solution – The simplest capability that would ensure that the correct page was delivered by the caching plugin would be a simple deliver cached page/don’t deliver a cached page. The theme could return a true/false value for the busiest page – most likely the standard view. This functionality would likely be simple since the current caching plugins already have the capability of not delivering cached pages when the logged in site admin is viewing pages.
  3. A Better Solution – If the plugin is capable of serving multiple versions of pages (as they are now capable of doing), they could hopefully extend that to any number of versions. The API filter would allow the theme to return an indication of which specific cache should be used. There could be some kind of naming convention – “standard”, “mobile1”, “mobile10”, or “none”. Then the cache plugin could use that to select the proper cache page. If it is not capable of serving a page for each view (disk space restrictions, user settings, whatever), the caching plugin could deliver as many different views as it could, and simply not cache for the rest.

I hope that I will be able to work with the authors of the major caching plugins to come to a resolution. It is seldom easy being on the bleeding edge of WordPress theme development, and this is a case where a significant issue has been discovered.

In the mean time, you can get some of the benefits of the caching plugins by disabling Page caching, and just using the other caching capabilities such as database caching, which so far does not seem to be related to the way the page is delivered.

Follow up – December 22, 2011

Well, it turns out that some of the major caching plugins do include some support to meet some of these issues. Turns out that both W3 Total Cache (W3TC) and Quick Cache have a mechanism to simply not cache pages from mobile devices. This requires a manual setting, including a copy/paste from Weaver II’s help document, but you will deliver the correct view of your site on all mobile devices – that view just won’t be cached.

There are also some options for keeping a separate cache based on a cookie. But none of it is overly well documented, and I’ve gotten no cooperation or help from the major Cache Plugin authors at all. So for now, if you are using a WP cache plugin, use Quick Cache (seems better to me), or W3TC, and follow the manual setting instructions included in the help document.

Comments are closed.