jarednova/timber — pull request #195 by mgmartel (2014-04-02 15:00:30+00:00)
Title: Reworked TimberHelper::transient to be more reliable

Hi Jared,

Another caching thing. I recently did some heavy performance tweaking and started leaning on `TimberHelper::transient` for pretty much every cacheable object that I couldn't reliably invalidate manually and it's been awesome. I did run into a few snags and ended up shuffling the method a bit. Here goes:

**Force parameter**
Originally, if the transient was locked, the user was simply abandoned and false was passed (and the source code only apologized). But I was starting to see the results of a dropped method in my Varnish cache, making that one drop propagate to heaps of visitors.
I added the `force` parameter that defaults to above behaviour for backwards compat (in case somebody relies on the lock to prevent a HTTP request from repeating, for example). If passed `true`, the callback will still execute, without the transient being saved. I also added two filters to control this behaviour sitewide: `timber_force_transients` and `timber_force_transients_{$slug}`.

**WP_DISABLE_TRANSIENTS**
Previously, disabling transients still tried the transient, but didn't continue execution. Now, disabling transients makes the method not touch any of the transients and end up execution the callback every time. Another way of forcing this is by setting the `$transient_time` param to false (like in caching methods).

**Lock timeout**
This caused some headache: the lock has the same expiry as the transient itself. So if the callback fails for some reason, it won't be tried again until expiry. I lowered the lock time out to default to 5 (the same as the default `WP_HTTP` request time out). After 5 seconds, the lock is released and the callback can be executed again.
If you want a method to have more time to execute (because it makes a slow HTTP request), you can pass a higher lock timeout value.