[wp-trac] [WordPress Trac] #42441: Disable autoload for large options

[WordPress Trac]

#42441: Disable autoload for large options
-------------------------------------------------+-------------------------
 Reporter:  markjaquith                          |       Owner:  pbearne
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.5
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion                                        |  performance
-------------------------------------------------+-------------------------

Comment (by flixos90):

 I just reviewed the new PR by @pbearne, and it looks very good to me
 functionally, despite needing a few more changes.

 Separately, I would like to bring the conversation about the new database
 values for the `autoload` column back to this ticket, to decouple from the
 specific PR implementation.

 Including the new values (regardless of whether they're called `default-
 yes`/`default-no` or something else) in the database is not only a "side
 effect" of this change. It is a requirement to make the thresholds for the
 maximum size of an option work reliably. Here's why:
 * Options don't always maintain the same size. An option may be added with
 some very small starter/placeholder value, but later grow much larger
 depending on how the option is used and how the end user interacts with
 the relevant functionality.
 * Because of that, it is crucial that we not only perform the maximum size
 check when adding the option, but also when updating it.
 * For that, unless the developer explicitly passes a value to
 `update_option()` (which is not exactly intuitive to do when you just want
 to update the option ''value''), we need to see whether the autoload value
 previously stored is an explicit one chosen by the developer (`yes|no`) or
 not (`default-yes|default-no`). In the latter case, we must re-check the
 option size. But in the first case, we must not do that, as we need to
 respect the developer's explicit choice.
 * In other words, being able to determine between explicitly set autoload
 values and "chosen by WordPress" autoload values requires this
 differentiation to be made in the database.

 The only alternative to that which I can think of is completely doing away
 with the `$autoload` parameter of all those functions and instead handle
 it as part of either setting registration or a separate way to register an
 option's autoload value independently. That however would have much wider
 implications and affect far more plugins than the currently proposed
 implementation that adds support for two more database values. Only
 plugins that implement their own functionality around autoloading options
 (e.g. certain database optimization plugins) will require an update with
 the current proposal, while a broader shift towards autoloading
 registration would be far more disruptive and affect plugins of all kinds.

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