[wp-trac] [WordPress Trac] #31245: Replace alloptions with a key cache

[WordPress Trac]

#31245: Replace alloptions with a key cache
-------------------------------------+-----------------------------
 Reporter:  rmccue                   |       Owner:  rmccue
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Options, Meta APIs       |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+-----------------------------

Comment (by johnjamesjacoby):

 Another really out-there idea:

 * An `WP_Option` class
 * An `WP_Option_Query` class for querying options
 * Introduce a `wp_optionmeta` database table - key/value storage for every
 option
 * Use the metadata API for the above (inherit caching, etc...)

 Treat options like post objects:

 * Query for them
 * Cache them (locally & persistently)
 * Query for their option-meta as needed
 * Abandon the `alloptions` logic entirely
 * Let the cache API sort it all out `¯\_(ツ)_/¯`

 Then core could:

 * Transition some keys from `wp_options` into a new `WP_Option` object
 with related meta
 * Route requests for converted keys from the old option name to the new
 option name
 * Have a legitimate `register_option()` API to begin to replace the ailing
 Settings API

 ----

 Conversely:

 * Abandon `wp_options` completely
 * Dream up a completely new and adequate object & schema for today's needs
 * Consider the same object & meta pairing as above

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