TLC Transients — On the fly WordPress transients with soft expiration and one-liner chained syntax.

README.md

TLC Transients

TLC Transients lives here now: https://github.com/markjaquith/WP-TLC-Transients

Mark,

I'm working with a large site containing 4,000 videos (cpt). The client is asking to track hits on single videos within a two week period for use with displaying a "What's Popular Now" widget. What are your thoughts performance wise using a transient approach to track hits stored as such day->video_id->hits. Day transients would expire after two weeks. Thanks for the great writeup.

@aaroncampbell — see the update. Like that?

@inspectorfegter — This should probably not be used for stuff that changes frequently. The way it works is that it essentially "forks" and runs each update in its own process. This is great for long-running updates that happen less frequently than once a minute. Transients should never be used as primary storage for any data, as they can go away at any time. For your hit counter, if it's not super-critical that the information be 100% accurate, you could store it in a transient and then write the transient value to a permanent storage location if the number of hits is divisible by 10, or 20, or 50, etc. That way you're not constantly writing to a permanent storage location. And if you unexpectedly lose the transient, you repopulate from the master, and at worst you lose the contents of the hit buffer.

Wouldn't returning a WP_Error be more WordPress like for avoiding the cache update? Especially cases where you may normally receive a WP_Error result anyway.

Not only that, but if the update failed for whatever reason, not updating the timestamp on the current transient makes the site keep trying constantly. There needs to be a way to say don't try again for x-time when failing.

Thanks Mark. That's exactly what I'm looking for.

@markjaquith - Yep, that's exactly what I did.

@prettyboymp - I suppose WP_Error would the "WordPress way". I feel like WP_Error is sort of the poor mans Exceptions because we weren't able to use Exceptions. I can see your point though, especially in the cases where you can do something like use wp_remote_request() directly with updates_with(). It means some errors are handled automatically by WordPress. However, not having your own function between the two means you can't handle things like empty (but successful) responses, invalid JSON or XML, etc.

As for a timeout for failed attempts, I suppose that would make sense but should probably be different from the expires_in, so you could set expires_in(30)->retry_in(5) to make it retry 5 minutes after a failed update and 30 minutes after a successful one.

@aaroncampbell — expires_in() takes a seconds input, FYI. :-) I like the retry_in() idea.

@markjaquith - Yeah, my examples were bad...in my plugin I'm using it right though :-)

Hey all. TLC Transients live here now: https://github.com/markjaquith/WP-TLC-Transients