I agree that a mix is good though, nice to blog about your life, that’s one of the reasons I visit your site, would love to see some pics of things you do, perhaps a workstation pic, or what ever, just personal stuff. At the same extent I’d be interested in pieces of code as I know you’re a great programmer, or information about what you’re working on and so forth – I guess these are all personal things afterall, of which I’m sure you’re passionate about anyway.

Well, that my 10 cents, hope it helps

Ps. Can’t comment on your blog via iPhone, this textarea goes white and you can’t see what you’re typing, however it’s perfect on my iPad

No, I don’t remember reading anything that prompted this. Just something I’ve been thinking about.

Yeah, the code example above and the example of an expensive query is more just an example, really.

I mostly lean towards transients when making requests from an external API or resource that I need to make periodically (ie: exactly as you said… as a poor man’s caching).

Yeah, I watched the “Otto and Nacin Show” a few weeks back… learned a ton. Thanks man.

Transients are stored in the database (unless you have a “persistent object cache” set up, in which case they go there). So, it doesn’t really help you much to store data that you got from the database back into the same database only in a different place. It can help slightly if you have large amounts of processing going on, but honestly the benefits are generally small enough for a better approach to be taken.

If you are having problems with lots of database overhead, a much better long-run solution is to set up a persistent object cache. memcached, xcache, APC, any of these will work. I recommend the W3 Total Cache plugin to let WordPress then use this memory cache for storing objects. This will lower the number of DB queries over the whole site and is generally good enough. If you still need to optimize further, you can then avoid the (minor) overhead of the Transient API and just use the object caching functions directly to store your objects.

Me and Nacin discussed this somewhat at WordCamp San Francisco 2011. Video is here: http://wordpress.tv/2011/09/07/otto-wood-andrew-nacin-the-otto-and-nacin-show/

Here’s a better way to get a transient and check it in one fluid step:

if (false === ($data = get_transient( $transient_key ) ) ) {
… no data in the transient …
} else {
… data in the transient that was not exactly “false” …
}

When I work with transients, I find it best to store the results of the database lookups (for example, running get_posts() and then storing the results), rather than storing the actual markup. This means I can freely change the markup without having to worry about the data lookup (essentially splitting the task into the database lookup and the output as separate tasks).

In some cases, if the HTML processing itself is quite intensive, it may be worth caching the HTML in a transient as well (maybe even a separate transient to the lookup data) and for a shorter time. Even a few minutes cached could make a difference.

One question: Initially I only stored the queries but read a few posts about actually storying the entire loops instead, markup and all. Have any insight as to which might be better or worse and why?