Make WordPress Core

Changes between Initial Version and Version 3 of Ticket #33499


Ignore:
Timestamp:
08/21/2015 09:44:05 PM (9 years ago)
Author:
westonruter
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 33499.2.diff.

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

<?php

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #33499

    • Property Keywords has-patch added
    • Property Milestone changed from Awaiting Review to 4.4
  • Ticket #33499 – Description

    initial v3  
    1 `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.
     1`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.
    22
    33I'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()`.