Allow plugins to bypass wp_options when saving transients

[mgibbs189]

In set_transient(), the only way to prevent transients from using the wp_options table is by using a custom object-cache.php drop-in.

This isn't consistent with get_transient(), which does have a filter to short-circuit transient retrieval (pre_transient_*).

This patch allows plugins to bypass the options table when saving transients.

Full disclosure: I'm writing a plugin to store transients in a separate table, instead of cluttering wp_options. Reference: ​https://github.com/mgibbs189/better-transients

[rmccue]

+1 on the concept, if only to match the pre_update_option_{$option} and pre_update_option filters. (Although I think the concept of moving transients to another table is flawed, there are probably other valid use cases regardless.)

That said, the filter should definitely be called pre_set_transient. Also, the above patch is missing the close brace for the if, which is a syntax error.

[mgibbs189]

rmccue, I've updated the patch based on your feedback. Thanks.

[rmccue]

Also, just to beat DrewAPicture to the punch, needs ​hook documentation as well.

[mgibbs189]

rmccue All set.

[rmccue]

Loving it. Let's see if we can sneak this bad boy into 4.1.

[iseulde]

has-patch 4.2-early so moving to 4.2.

[mbrandys]

I think that bypass conditional should be placed before wp_using_ext_object_cache one to match how it it's done in get_transient as it still forces saving data in external data storage when someone uses object-cache.php drop-in.

[DrewAPicture]

The latest patch still applies. I'd love to have a lead weigh in here, maybe @helen, @nacin, or @markjaquith.

[DrewAPicture]

Pushing to future release unless a committer would like to pull it back, for the 4.2 release at least.

[nacin]

Replying to mbrandys:

I think that bypass conditional should be placed before wp_using_ext_object_cache one to match how it it's done in get_transient as it still forces saving data in external data storage when someone uses object-cache.php drop-in.

I agree with this assessment. Thank you @mgibbs189 for your "full disclosure" — this is really helpful to ascertain your use case, and is always something we'll ask for. It also explains why you wanted to do this *after* wp_using_ext_object_cache(). But it shouldn't be to be more generally useful. You however can use wp_using_ext_object_cache() in your callback, so your use case is fine.

Also, I'm not sure I like the filter name. When we have a specific action or filter like "filter_name_$name" combined with a generic one (i.e. "filter_name"), they should do the same thing and function the same way. pre_site_transient_$transient already exists. pre_site_transient should not exist and then do different functionality.

Any proposed changes here should be mirrored to set_site_transient().

I *do* like the idea, it just needs some more work. Also, I bet there's a way to do this by filtering in the options API, so there's at least a hacky workaround.

[mgibbs189]

@nacin @mbrandys thanks for the feedback.

I think it'd be fine to move the hook above wp_using_ext_object_cache() - I had moved it *after* wp_using_ext_object_cache() because I figured external cache would need to take precedence. E.g. with the way it's currently set up, external cache is given a chance to run before the bypass filter.

Also, any suggestions for the filter name? Maybe something like bypass_set_transient?

[jipmoors]

First of all, could you make the diff file from the trunk next time? Perhaps adding the ticket number in front would be a good addition for clearity.

I suggest to move the filter to after the wp_using_ext_object_cache() so hooks won't get the wrong idea that they can manipulate stuff that is ignored later on.

On the naming of the filter, I think it would be adding to the clearity if it represented more of what it's doing, 'allow_set_transient_to_options'.

Setting 'result' to true does not reflect what the code is doing, I can imagine that not calling the actions on a success could result in unwanted behaviour but it sounds like the proper thing to do when you bypass saving the value. Would appreciate 2nd opinion on this.

[jipmoors]

Moved the filter after external cache check and renamed to reflect better what it does

[obenland]

@rmccue, beta is two weeks away. I'm inclined to punt unless you can get it ready soon.

[mgibbs189]

Closing. Looks like this one isn't gonna happen.

[netweb]

Closed tickets shouldn't have a milestone so I've removed the milestone.

Pinging @rmccue, are you still interested in this? If so reopen and milestone etc