In the previous two posts, I’ve talked about the basics of caching and how caching works in WordPress, at least to a degree.

But remember that this series was motivated by an email from someone who thought that I could do a better job of explaining how transients and caching work in WordPress and why it’s important to understand how everything works in tandem with each other.

So in this post, I’m aiming to bring it all together and talk about how the Transients API works in conjunction with MySQL, why it’s important to understand the relationship, and how to handle this moving forward.

How Do Transients Work in WordPress?

How Transients Work

First, according to the Codex, transients work like this:

This page contains the technical documentation of WordPress Transients API, which offers a simple and standardized way of storing cached data in the database temporarily by giving it a custom name and a time frame after which it will expire and be deleted.

Transients API via the WordPress Codex

The idea behind this seems simple enough, right?

  1. You save an option to the database,
  2. Set a time for how long it should exist,
  3. Then it’s stored for that amount of time
  4. And, if requested after expiration, is retrieved and moved back into its transient state.

So where lies the confusion?

As mentioned in the first post, I wasn’t clear about how long the transient information would be available. Rather than being a minimum amount of time the data will be available, it’s a maximum.

This means that if you set something to be available for a day, it will be available for a day. No less; no more. And after that time has expired, then it will have to be recreated into the transient state once again.

At least, this is the conventional wisdom behind it. It’s not wrong but there’s more to it. This is where it gets a bit more technical, though.

What Role Does MySQL Play?

As WordPress, hosting, and other technologies have matured, the underlying databases that power the application have changed, too. This isn’t a good thing or a bad thing (though perhaps we could argue it’s a good thing in a future post).

But it can help explain why transients work the way they do given the stack with which we’re used to working and how they may not work as expected with out database systems.

If you opt to use MySQL as the database for your WordPress installation, which I venture to say that most people still do, then the information that’s in the Options table (which is where transients are stored, too) then the Transients API will work as outlined above.

But what happens when you introduce other forms of caching like object caching through software like Memcached or Redis, and so on?

In that case, the data may not be available as you expect. In short, the caching software can choose to drop information that isn’t requested as often as other information. That is, it gives a level of priority to information that’s more frequently requested.

Moving Forward

When you take all of the above into account, you’re looking at several things:

  1. the Transients API,
  2. a database,
  3. a third-party caching system.

When you have the Transients API and a standard database, you’re going to be fine in that things will work as you expect.

But if you introduce a third-party caching system, the outcome may be different. Specifically, things may not – and likely will not – work in the way you expect.

That is, the third-party caching system can disregard whatever information it wants to drop whenever it thinks it needs to remove it. This means that whatever you think you may have available in cache won’t be there.

Ultimately, the best advice I can give is this:

  1. If you’re using MySQL and the Transients API, then things will work as described in Codex.
  2. If, on the other hand, you’re using another caching system, then it’s important to understand how it works and how you can write code against it so it works as you’d like.

And with that, there’s nothing more to add on this primer for understanding caching in WordPress.