TLC Transients lives here now: https://github.com/markjaquith/WP-TLC-Transients
-
-
Save markjaquith/1149945 to your computer and use it in GitHub Desktop.
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
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.