If you use the WPTouch mobile plugin, or the preload function in my caching plugin, or noticed that annoying but random and (thankfully) rare “front page isn’t showing my front page” bug then you might like to try the development version of WP-Super-Cache located on this page.
Mobile plugins need to tell WP Super Cache what user agents they support. I documented the filters you can use (“cached_mobile_browsers” and others) to do this but I don’t think they’ve been used by any plugin. It’s not hard to do and I added code that checks for WPTouch so when you visit the WP Super Cache settings page it updates the mobile user agents. So far it works for me but please feel free to view this site on your mobile phone and tell me if it looks ok! I also added support for the theme switcher in WPTouch based on code posted on the wporg forum.
It appears that the “random post on the front page” problem is a side effect of how PHP works. WordPress incorrectly reported that the current page wasn’t a search page, even though it was. I put an extra bit of code in checking if $_GET is non empty and that fixed it, so far.
Just in case anyone else is interested, this is why is_search() fails randomly when run during PHP shutdown. When a PHP process shuts down it starts by killing off objects. Unfortunately this happens before PHP stops executing your code, something that changed after PHP4.
Anything that runs when the output buffer finishes or that is registered by register_shutdown_function() better not depend on objects or classes. That means no using $wpdb, the object cache may disappear or to be completely paranoid don’t expect $wp_query to be around either! The functions is_search(), is_feed() and other related WordPress functions depend on $wp_query so you should cache the values of those functions earlier in the process. I’m thinking of hooking into wp_head but that depends on the theme unfortunately. Not every theme uses that action.
Many years ago I changed the format of the cache “meta file” from an object to an array because of the way the PHP desctruction process works. More recently, but still two years ago I had to remove all calls to get_option() and update_option() in the output buffer handler because occasionally people saw the error, “Call to a member function get() on a non-object in cache.php” in their error log. The object cache object had been destroyed by PHP! That was a right pain to figure out as the code looked perfect yet didn’t work right some of the time.
To help figure out problems I’ve added a lot more debugging to the plugin too. If $wp_query disappears it’ll appear in your debug log, and preloading will generate a lot more messages now.
Next up is caching is_search(), is_feed(), is_single() etc. Where should those be cached? The “init” action is too early for is_search and probably others but I don’t want to depend on actions that may not be in a theme.
