WordCamp Vancouver 2012 – What Did I Learn?

Another great event & I learnt lots of great stuff.

Probably the most interesting talk of the day, for me, was Zack Tollman’s talk about cache invalidation schemes. Yeah… hard-core, that’s me 🙂

The talk was, obviously enough, very technical and right up my alley. I already knew there was a caching mechanism built into WordPress, even though I’ve never used it, and the talk was well-paced so it wasn’t hard to follow – so most of it wasn’t revolutionary. Except for one throw-away comment that Zack made…

WordPress caches queries by default.

Huh? Why didn’t I know that already? It seems that if you call WP_Query() your results are automatically cached, unless you tell WordPress otherwise… a fact that’s actually documented: it’s right down there at the bottom of the Codex page for WP_Query() – right at the bottom of a very very long page where nobody ever goes.

I was pretty impressed to find this out. The next thought that occurred to me was “So why HASN’T this been anything I’ve needed to know before now? And yet I’m sitting here in an hour long talk about how to be sure you mark your (private data) cache entries as invalid at the appropriate times. Why isn’t this an issue for normal WordPress data under normal use?”.

The reason, I believe, is down to what causes the cached data to become invalid. The only way the WordPress database should get written to is through the WordPress API. So WordPress KNOWS when to invalidate its cached data and can do it transparently from users and theme-level code.

This is just another reason (as though you needed any more) why you shouldn’t run SQL statements on the WordPress tables directly!

 

Comments are closed to reduce the spam. If you'd like to add something, please use the contact form to let me know and I'll reopen comments for you. Thanks