When to use cache and when options?

[Rarst]

Most WP snippets I encounter use options to store stuff. If it need to be temporary timestamp is added, etc.

Was picking apart one plugin and came upon using cache for storing stuff. Seems to be more adequate for time-limited.

What are technical differences (if any) between using options and cache? What is suggested usage for them and why options seem much more common?

[Ryan]

What do mean by "cache"?

[Rarst]

What do mean by "cache"?

Shows how common it is, heh. :)
http://codex.wordpress.org/Function_Reference/WP_Cache

[Rarst]

Ouch... I tried some test code and it failed miserably. Turns out Codex article is horribly misleading (meh, typical) and since version 2.5 cache only works for current session, file cache is gone.

So... Are options only native way to cache data?

[dancole]

Deciding when to use options and when to use cache is like deciding when to use a truck and when to eat an apple... they are completely separate things. WordPress's get_option/add_option/update_option/delete_option are functions that make it simple to store and retrieve data from the database. These functions do take advantage of caching and other techniques to limited the number of database queries, time it takes to load a page, and amount of processing it takes.

As for caching in general, there are different types, such as in the browser, on the server, on the HTTPD (Apache) software, in the PHP compiler, and within WordPress itself. In the case of WordPress, the core software also has some caching techniques, but there are also plugins that improve the caching in different parts of the software.

[Otto]

The WP_Cache and Options are different things. Also, there's now "transients". :)

The object cache is for storing data that you need to retrieve multiple times in the course of a single execution. That last bit is important, because while the object cache is not persistent by default, it should be treated as persistent because it can be. Basically you can install plugins that persist the cache into things like XCache or half a dozen other persistent memory caches, reducing the number of database hits and such. The object cache is used internally all over the place, so any time you get something from the database using a WP function, if you then go get it again, it's a good bet that you won't hit the database at all. Basically, the best use of the object cache is to cache data you get from the database, in case you need to get it again very soon. Updates need to be handled carefully in such a case.

Options are for storing data persistently, although the amount should be kept to a minimum. These store directly to the database, and read from the database as well. Actually, their performance is improved automatically using the WP_Cache mechanisms as well.

Transients are new. They're basically options that expire. They can be stored in the database, but again, the hooks are there for plugins to store them in fast ram using distributed memory solutions, so you shouldn't assume that they live in the database. They are semi-persistent data stores with a forced expiration time. In other words, you can't rely on them being there when you try to get them. They're most useful for speeding up loading of data from external sources (like storing an RSS feed's info). You'll need to refresh that data eventually, so you check the transient, if it's not there, you go get it and then put it in a transient. No more having to store when you got it last.

[Rarst]

@dancole

Disclaimer - I am not too stupid. :) I know about cache in general, it's specifics of native WP implementation that lost me a bit.

@Otto

Thank you for details! I just got confused because cache was persistent and stored in files before 2.5, there is a lot of outdated information on that around.

What started me on this - I use portable WP stack and when I am behind proxy it can't fetch external pages/feeds natively. So I am writing small function with Snoopy to do that through proxy and it got me thinking how to make it cache file content as well.

Will probably just write it as local file and add time check.

[Otto]

Thank you for details! I just got confused because cache was persistent and stored in files before 2.5, there is a lot of outdated information on that around.

That got removed because it didn't help speed any on most sites. There's still a plugin to do it somewhere though/

What started me on this - I use portable WP stack and when I am behind proxy it can't fetch external pages/feeds natively. So I am writing small function with Snoopy to do that through proxy and it got me thinking how to make it cache file content as well.

Will probably just write it as local file and add time check.

No, use transients. This is what they were created for. It's also where WP stores its own feeds.

function set_transient($transient, $value, $expiration = 0)
function get_transient($transient)
function delete_transient($transient)

Works like this:
set_transient('transient_name', $value, 3600);

That sets a transient which expires in 3600 seconds. $value can be anything, a string, an array, an object, whatever.

$value = get_transient('transient_name');

That will get the value back, for up to an hour (3600). After that hour is up, it'll return false.

delete_transient('transient_name') will delete it outright, but it's not necessary to call explicitly, as it's deleted when it expires (as long as you call get_transient). The delete is thus really only used for plugin uninstallation.

[Rarst]

@Otto

In this specific case it is debug code, not production one - convenient to have raw feed as file.

Still transient seem like a handy replacement to what I thought cache is. Need to try using them somewhere. xref, here I come. :)

[Rarst]

One follow-up question on transients - what works best for key?

Simply using URLs seems to fail, should I md5 it or there is some other way considered WP-proper?

Heh, function started as Snoopy+file... Ended up as WP_Http+transient. Cofee brewing is in sight.