WordPress vBulletin Bridge (vbridge) disabling WP Super Cache

As mentioned in my previous post, I’ve been playing with WordPress, vBulletin, vBridge, and some other stuff as part of my work for my other site, TechwareLabs. One of the other plugins I utilize on that site is WP Super Cache, which I discovered was an easier way to accomplish basic static caching instead of trying to jump into the deep end of learning mod_cache, memcache, and other sorts of fancy things for an actual elegant solution.

Unfortunately, these are complicated systems, and vbridge in particular seems slightly less polished than some more widely utilized components (though, in fairness, its user base is considerably smaller than most wordpress plugins).

It was actually in the course of trying to track down the issue of why the TechBargains Hot Deals Widget is such an obnoxious memory hog (full disclosure: it may just be the final straw that’s breaking the camel’s back, but it does legitimately seem to be a pretty damn big piece straw) that I discovered WP SuperCache wasn’t doing its thing any more. After a little initial troubleshooting of my own, I acted on a hunch, and googled wordpress vbridge supercache, and was fortunate enough to immediately find a pertinent result.

As nasium was kind enough to share, the Complete Vbridge Plugin apparently adds a variable ‘ajax’ to the PHP $_POST variable, which WP Supercache’s criteria flags as reason not to cache. I wasn’t entirely convinced his solution of entirely removing these lines from wp-content/plugins/wp-super-cache/wp-cache-phase2.php was appropriate:

  1. if ( $_SERVER["REQUEST_METHOD"] == ‘POST’ || !empty( $_POST ) || get_option( ‘gzipcompression’ ) ) {
  2.     if ( isset( $GLOBALS[ ‘wp_super_cache_debug’ ] ) && $GLOBALS[ ‘wp_super_cache_debug’ ] ) wp_cache_debug( ‘Not caching POST request.’, 5 );
  3.     return false;
  4. }

because they were probably there for a reason. I took a slightly less heavy-handed approach, and just added what I hope is a specific exclusion for this vbridge behavior:

  1. if ( $_SERVER["REQUEST_METHOD"] == ‘POST’ || (!empty( $_POST ) && (sizeof($_POST) > 1 || !array_key_exists(‘ajax’, $_POST))) || get_option( ‘gzipcompression’ ) ) {
  2.     if ( isset( $GLOBALS[ ‘wp_super_cache_debug’ ] ) && $GLOBALS[ ‘wp_super_cache_debug’ ] ) wp_cache_debug( ‘Not caching POST request.’, 5 );
  3.     return false;
  4. }

As such, when the $_POST variable contains more data than just the one ‘ajax’ variable, or contains just an element that isn’t ‘ajax’, then WP Supercache will still abort, as its authors originally intended to do with any $_POST data. (Since I don’t know the full implications or reason behind why it was coded that way to begin with, I’m operating under the assumption that it’s important–I can see how it would be.)

2010-10-10 Edit: When I originally made this change on WordPress 2.8.5 and a slightly earlier version of WP Super Cache, I’d used !isset($_POST[‘ajax’]), and that worked, but after upgrading to WP 3.0.1 and the latest WP Super Cache (as of today, 2010-10-10), I had to change it to !array_key_exists(‘ajax’, $_POST). I didn’t upgrade my PHP version, so I’m not sure why this would’ve changed, but whatever…

Side Notes

While on the hunt, I finally re-found a little web page that gives some useful stats about web page load time, which caters at least slightly to wordpress blogs: IsMyBlogWorking.com. There are plenty of other sites out there that give more/different information, which are also useful, but I like the quick high-level overview here (and it specifically notes when WP Supercache is active).

I also found a reference to a reason WP Supercache might not work with google feedburner links. I added the javascript call, which is easy enough, but still need to figure out actually changing ‘?’ to ‘#’ for incoming links. Anyone know about this?

Tags: , ,

Leave a Reply