Settings API autoload hook

[hir88en]

Currently all settings registered via Settings API is forced to enable autoload, There is no hook to replace this.

Lets imagine just for example:

1. all wordpress plugins is using this to register their settings data. but not delete this value during uninstall.
2. Average wodpress admin install then uninstall 50 plugins in their lifetime.
3. Average autoloaded setting is 100kb per plugin

there will be 5mb autoloaded options which not used anymore. that event is per pageload. Just imagine that.

[SergeyBiryukov]

#55629 was marked as a duplicate.

[SergeyBiryukov]

An example by @apermo from #55584:

Index: public/wp-includes/option.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/public/wp-includes/option.php b/public/wp-includes/option.php
--- a/public/wp-includes/option.php	
+++ b/public/wp-includes/option.php	(date 1651054674847)
@@ -461,7 +461,16 @@
 
 	/** This filter is documented in wp-includes/option.php */
 	if ( apply_filters( "default_option_{$option}", false, $option, false ) === $old_value ) {
-		// Default setting for new options is 'yes'.
+		/**
+		 * Filter autoload for an option.
+		 *
+		 * @since tbd
+		 *
+		 * @param string|null $autoload Current value of autoload, can be "yes", "no" or null.
+		 */
+		$autoload = apply_filters( "autoload_option_{$option}", $autoload );
+
+		// Default setting for options is 'yes'.
 		if ( null === $autoload ) {
 			$autoload = 'yes';
 		}

[iandunn]

I think this could be useful; I'm auditing a perf issue on a site, and one part of the problem is that several plugins have large settings. Those settings are only needed on a few pages, though, so they shouldn't be autoloaded.

At first glance, it seems like adding a new param to register_setting() would be more convenient than having to setup a callback in addition to registration.

[flixos90]

I just proposed an alternative solution to a similar problem in #58964, I would appreciate your feedback. I believe using the Settings API for this overloads it a bit too much, particularly as using the Settings API is not mandatory when using options, so it would come with additional implications.

Potentially, if the approach proposed in #58964 moves forward, it could be considered to support it in register_setting() as an (optional) wrapper to that approach.

Curious to get your thoughts.

[mukesh27]

This ticket was discussed during the Yesterday Performance bug scrub.

It necessitates the adoption of a precise approach to rectify the issue. The label dev-feedback has been applied to solicit developer input.

Additional props to @joemcgill