I’ve been doing a lot of work with a 3rd party API over the past year. One of my frustrations has been how long it takes to request information from the API. Some of the requests could take up to 30+ seconds. The user visiting the site would have to wait during that time for the page to finish loading. I then started using Transients to cache the API calls for a specified period of time. This worked great until the transient expired and a visitor had to wait for the API to return the data again or if the site didn’t get much traffic and the transient expired before the next visitor got to benefit from it.

My first idea was to not return the API data on the page load, but instead request the data after the page had loaded via an AJAX call. At least the page would finish loading, then I could display a spinner or something to let the visitor know that content was still loading in that particular section of the page. Still not idea since the visitor would be required to wait for the data, just at a different stage of the page load.

Then, about a week ago when TechCrunch open sourced their WordPress Async Task Library, it got me thinking. I could do the same thing with my transients! I then did a search and found that Mark Jaquith had created something very similar. I refrained from looking at the source code for either of these projects because I wanted to figure it out on my own. I mean, how else am I going to learn unless I challenge myself, right? I know that my code can be improved, so I will take a look at their source code now that I’ve got mine working.

Here’s how my class works. It has its own version of set_transient() and get_transient(). The function to set the transient has the same options as the WordPress version, except that it sets two transients. The first one is set with the expiration that was passed to the function. The second (fallback) transient is set with the expiration that was specified when the class was constructed, which defaults to 1 week. When requesting the transient, there are a few extra parameters. Along with the name of the transient, ->get_transient() also requires a hook and the arguments to pass to that hook. The hook is a function that needs to be registered with add_action(). When a transient is requested, the main transient is checked for data. If that transient is valid, then the data is returned, but if it has expired, then the fallback transient is checked for data. If the fallback transient is valid, then the data is returned and the hook is scheduled to run using wp_schedule_single_event(). If the fallback transient has also expired, then the function returns false and you can act accordingly. When the scheduled event fires, make sure that it repopulates the transient using ->set_transient().

There is also a cleanup function that can be turned on when the class is constructed. This function will purge expired transients created by the class on a daily basis.

I’ve put the class up on GitHub if you’d like to take a look. Feel free to give me some feedback or use it in your own projects.

FireTree-Transient-Fallback class for WordPress