Opened 3 years ago
Last modified 14 months ago
#55584 new enhancement
Settings API autoload hook
Reported by: | hir88en | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Options, Meta APIs | Keywords: | dev-feedback |
Focuses: | performance | Cc: |
Description
Currently all settings registered via Settings API is forced to enable autoload, There is no hook to replace this.
Lets imagine just for example:
- all wordpress plugins is using this to register their settings data. but not delete this value during uninstall.
- Average wodpress admin install then uninstall 50 plugins in their lifetime.
- 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.
Change History (6)
#3
@
3 years ago
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'; }
#4
@
2 years ago
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.
#5
@
15 months ago
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.
#55629 was marked as a duplicate.