Prime transient and transient timeout options in `get_transient`

[peterwilsoncc]

On sites without a persistent cache, temporary transients are stored in two options. One containing the transient itself, the other containing the timeout. These are stored as _transient_[transient name] and _transient_timeout_[transient name].

Currently WordPress makes two database queries to get these options. With the introduction of wp_prime_option_caches() in WordPress 6.4 it's now possible to reduce the querying of expiring transients to a single database request.

While a mild improvement on sites using a limited number of transients, I think it could become reasonably significant on sites running plugins that make heavy use of transients. WooCommerce being one example I can think of.

Follow up to #58962.

[peterwilsoncc]

In the ​linked pull request:

• Adds tests for get- and set_transient() to verify the number of database calls is expected
• Primes the caches prior to calling get_option() in both get- and set_transient().

A broken test was pushed prior to each change to demonstrate the improvement.

Thanks @swissspidy. I decided overnight I should test for the specific queries that's the purpose of the change. I've pushed the changes to the test suite in eb8200a103467532a148d94a841e2eea5d248e74, the source remains unchanged.

[peterwilsoncc]

The linked pull request has been ​approved so I am putting this on the milestone for inclusion in WordPress 6.6.

[peterwilsoncc]

In 58134:

Options, Meta APIs: Prime transient options prior to use.

Reduce the number of queries getting and setting transients on sites without a persistent cache.

Transients are stored in two options: one each for the transient value and timeout. Priming the cache reduces the database queries for getting a transient from two to one.

Props peterwilsoncc, swissspidy.
Fixes #61193.

Committed r58134 / ​https://github.com/WordPress/wordpress-develop/commit/ea8bc973b491470dacd1c20bb50cc2a0d7b9e50a

[peterwilsoncc]

@swissspidy I had a foolish moment and forgot about site transients.

For Multisite installs priming site transients will require #61053 be completed but for single site installs it's possible to prime the cache as they are stored in the options table. Do you think it's worth re-opening this to prime single site installs or better to wait for the other ticket to be completed?

[swissspidy]

Depends a bit on the traction on the other ticket I'd say. If you think it's close to land in 6.6 then I'd suggest waiting for it, else handle it here.