[wp-trac] [WordPress Trac] #33499: Allow `$autoload` to be set in `WP_Customize_Setting::_update_option()`

[WordPress Trac]

#33499: Allow `$autoload` to be set in `WP_Customize_Setting::_update_option()`
-------------------------+------------------
 Reporter:  dlh          |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.4
Component:  Customize    |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------
Changes (by westonruter):

 * keywords:   => has-patch
 * milestone:  Awaiting Review => 4.4


Old description:

> `WP_Customize_Setting::_update_option()` calls `update_option()` for us,
> but it doesn't currently provide a way to use the `$autoload` parameter
> that was added to `update_option()` in 4.2. So, it seems tricky to avoid
> autoloading options that are managed exclusively through the Customizer.
>
> I'm not sure whether a Customizer-specific filter would be the best way
> to change this behavior, but the attached patch would add one in
> `WP_Customize_Setting::_update_option()`.
>
> Adding a property to `WP_Customize_Setting` didn't seem like the right
> choice because multiple settings can affect the same option. But an
> alternative approach might be something that can be used in any
> `add_option()` or `update_option()` call.

New description:

 `WP_Customize_Setting::_update_option()` calls `update_option()` for us,
 but it doesn't currently provide a way to use the `$autoload` parameter
 that was added to `update_option()` in 4.2 (see #18244). So, it seems
 tricky to avoid autoloading options that are managed exclusively through
 the Customizer.

 I'm not sure whether a Customizer-specific filter would be the best way to
 change this behavior, but the attached patch would add one in
 `WP_Customize_Setting::_update_option()`.

 Adding a property to `WP_Customize_Setting` didn't seem like the right
 choice because multiple settings can affect the same option. But an
 alternative approach might be something that can be used in any
 `add_option()` or `update_option()` call.

--

Comment:

 I think adding Core support for Customizing non-autoloaded options makes
 sense too, but I think it can be done nicely without a filter.

 Take a look at [attachment:33499.2.diff].

 This would allow non-autoloaded options to be registered with just:

 {{{#!php
 <?php

 $wp_customize->add_setting( 'foo', array(
     'type' => 'option',
     'autoload' => false,
 ) );
 }}}

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