[wp-trac] [WordPress Trac] #58962: Provide a way to load multiple specific options with a single database request

[WordPress Trac]

#58962: Provide a way to load multiple specific options with a single database
request
------------------------------------------+--------------------------
 Reporter:  flixos90                      |       Owner:  flixos90
     Type:  enhancement                   |      Status:  assigned
 Priority:  normal                        |   Milestone:  6.4
Component:  Options, Meta APIs            |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  performance
------------------------------------------+--------------------------
Changes (by flixos90):

 * keywords:   => needs-patch needs-unit-tests


Comment:

 To address this problem, we have holistically two options: Either we
 provide a way to directly retrieve multiple options at once, e.g. a
 `get_options( $options )` function. Or we stick to focusing on the
 existing `get_option()` for actually retrieving options, but provide a
 function to prime specific options, i.e. load them into the cache with a
 single database request - similarly to the autoloaded options
 ("alloptions") query, but for a specific set of options.

 I would propose the following solution to the problem:
 * Implement a function `prime_options( $options )` to which developers can
 pass an array of option names. The function will load all options into the
 cache with a single database query, except for those options that are
 already in cache (if any).
 * With this function, a plugin for example could call it when its WP Admin
 screen is loaded, priming all its options in a single database query. It
 could then potentially update these options to use `$autoload = 'no'`. No
 changes would need to be made to how options are actually fetched, as
 `get_option()` would function the same way as before - the values would
 simply be already in cache if primed before.

 The above function would be the central foundation, however we ''could''
 consider implementing additional "wrapper" functions to facilitate
 specific use-cases, for example:
 * A `prime_options_by_group( $option_group )` may be useful as a wrapper
 for `prime_options()`, allowing e.g. a plugin to prime all options
 registered with a specific option group. This would give the benefit of
 not having to remember/hard-code all option names in the priming function
 call, and it would tie in nicely with the existing Settings API, where
 option names have been a required parameter since its origin. The function
 would effectively get all option names in the given group and then call
 `prime_options( $options )` with them.
 * A `get_options( $options )` function may be useful to actually retrieve
 multiple options in one go. The function would effectively call
 `prime_options( $options )` and then `get_option( $option )` for each of
 them, returning an array of key value pairs.

 While we could also implement a ''standalone'' `get_options( $options )`
 function as an alternative (i.e. not using another function to prime
 options), I consider that approach overly limiting, as it would require to
 basically duplicate lots of the `get_option()` function's code, and it
 would be easy to miss some nuances. So focusing the new functionality on
 priming options while keeping the foundation for retrieving options
 untouched makes more sense IMO.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58962#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform