WordPress memcached 3.0.0

Some software is so stable that it becomes stagnant. Yesterday’s update of the WordPress object cache drop-in for memcached flings it from both categories, back into active development where it is sure to capture the attention of WordPress site administrators around the world.

So much for drama and spin. All that really happened was this: I pushed a major-version update that finally allows `wp_cache_flush()` to work for WordPress sites using memcached. You probably shouldn’t care at all; you had better click away to a video of a suburban father longboarding with a short-legged dog.

In case you do care, it can only be because you belong to the elite club of techies who administer a WordPress site with the help of memcached. Our records on this population are scarce. By one estimate–surely a miscalculation–there are fewer than ten installations of this software in the world. You may call it hubris but I suppose the number might stretch well into two-digit territory.

What you few need to know is this: upgrading to 3.0.0 will instantly flush your entire cache. This will happen because the key format has changed. I didn’t bother writing any code to gradually migrate keys, nor do I offer any other strategy mitigate this potentially catastrophic effect. You should be keen enough to handle it.

Beyond that, you can look forward to fewer problems along the lines of WordPress getting stuck in a database upgrade loop. This is when you’ve upgraded your database but WordPress keeps insisting that you haven’t, locking you out of wp-admin. That’s what happens when `wp_cache_flush()` has no effect. That’s just how it was for multisite installations because memcached’s own flushing mechanism was too blunt for such use.

How it works is not too hard to invent. Cache keys are automatically prefixed with a number that pseudo-uniquely represents the current “flush count” of either the current site or the global cache. Flushing is accomplished by incrementing that counter so that stale entries are hidden to subsequent accesses. The counters are stored in memcached so they exhibit the same performance characteristics as the cache entries they marshal.

2016 is not the first time we have tried this. Eight or so years ago, the same strategy was attempted on what was and is the world’s largest WordPress installation. Sensing trouble, we backed away from the high road and skirted the problem by inserting proprietary code in our copy of WordPress. If you’re the type that wants to dive into the gory details of these hacks, we have a special place for you.

We revisit the high road now because time has taught us to lean into trouble. We cherish our scars and we regret having sustained so few of them over the years. Second, we want future projects to hold tighter to the ethos of open source software and pushing improvements upstream for all to enjoy.

Like all versions of WordPress and this drop-in extension, 3.0.0 is free of charge. It will cost you one or two cache reads every time WordPress generates a page. If you find this expense immodest then I hope you will contact me about your use case.

I hope 3.0.0 proves stable enough to vanish back into obscurity. If it gives you trouble, come find me and we can make 3.0.1 together.

Thanks to Peter Westwood for reviewing the code and suggesting an improvement.

Published by

Andy Skelton

Code Wrangler @ Automattic youtube.com/AndySkelton