Add autoload flag to update_option

[wpdavis]

I think having an autoload flag in update_option would be beneficial in terms of making sure developers aren't unknowingly autoloading every single option. I've created a patch that allows developers to define autoload using update_option and force a change if needed.

[devesine]

An essentially equivalent issue, #5702, was closed ("Most options SHOULD be autoloaded.") some years ago, but it has been my experience that there is fairly widespread use of the Options API to store arbitrary persistent data.

That data is not necessarily relevant to every page request, and there are definite downsides to having too many autoload options. We have in production a database with 60,000 rows in the options table and 1,200 autoload="yes" options; trimming the autoload options down to around 200 shaved off a quarter of a second from page generation time. We also encountered a database with 25,000 rows in the options table of which 24,000 (!) were autoload="yes", and it was generating pages in 10-15 seconds. Trimming that down to roughly 500 autoloaded options brought page generation down to 3-5 seconds. (Obviously there are other performance questions in play as well.)

I don't know what the right solution here is, but I would start the discussion by proposing two things:

1. Add a new parameter to update_option. This could either be $autoload_if_creating, to be passed to add_option but not to the update itself, or $autoload, to be passed to both add_option and the update if it is not NULL. This wouldn't do anything about existing code, but it would allow more straightforward use of the options API for its apparently current "generic data store" usage in the future.

2. Make update_option default to create non-autoloading options if they don't exist. Plugins that use the options API as originally envisioned - add_option during activation, update_option thereafter - would be entirely unaffected. Plugins that use the options API as a generic persistent data store would generally see a benefit, by not expanding the autoloaded options with things that are used infrequently. The only downside would be plugins that expect the update_option functionality to create autoloading options - but I suspect the number of developers who are aware of the distinction is pretty tiny compared to the number using update_option.

Another path forward might be to make a new interface to the options table, specifically for generic, persistent, intermittently-used data storage (as opposed to non-expiring transients, which are generic, non-persistent, and autoloaded, or expiring transients, which are generic, non-persistent, and non-autoloaded).

(Or maybe I'm entirely missing an API intended for that use that already exists?)

[MikeHansenMe]

Duplicate of #26394.

[DrewAPicture]

Duplicate of #26394.