Need more value and preview hooks for WP_Customize_Settings

[dedepress]

There should have more filters to handle settings.

for example:
add

apply_filters( 'customize_value', $this->defaults, $this);

or

apply_filters( 'customize_value_'.$this->type, $this->default, $this);

before

apply_filters( 'customize_value_' . $this->id_data[ 'base' ], $this->default );

add

do_action( 'customize_preview_setting', $this );

before

do_action( 'customize_preview_' . $this->id, $this );

[ocean90]

Related: #29165

[celloexpressions]

I don't think we would want to add non-type-specific filters, like customize_value, but customize_value_$this->type might be useful (do you have a specific use-case or example for that?). I'm not sure that it would make sense to apply any filters to all settings regardless of their type, as they are handled very differently depending on their types. But adding filters by type where there are currently only filters by id may be useful depending on the situation (and I think we would need to come up with some use-cases before implementing them).

[dedepress]

There is filter by type in WP_Customize_Setting->update(), but filter by id_base in WP_Customize_Setting->value(). so, it's hard to modify something via same type of filters for updating and retrieving.

I think

customize_value_$this->type, $this

is better than

customize_value_' . $this->id_data[ 'base' ], $this->default

assumed all of our setting ids is serialized, how to change value of each setting via the id_base filter? pre_option_* and pre_update_option* can achieved my goal, but filter by type will make things easier.

[westonruter]

The current customize_value_{$id_base} is extremely limited in use. We need the type-based filter as well, and these filters need to be passed the WP_Customize_Setting instance.

[westonruter]

We need this for Settings with custom types to be able to properly get values when they aren't previewed (since as of [30102], only dirty settings get sent to preview, leaving unchanged settings to rely on the value-filters). Assigning to 4.2 milestone.

[celloexpressions]

Needs a patch asap if we're going to make the enhancements deadline Tuesday. This is one of our more punt-able tickets.

[westonruter]

We can punt. It is not technically required since you can just add ID-specific filters.

[westonruter]

#34099 was marked as a duplicate, as reported by @shramee:

WP_Customize_Setting::value() doesn't allow filtering all settings with common custom customize setting type, whereas WP_Customize_Setting::update() and WP_Customize_Setting::preview() use hooks based on type name and provide access to properties of current instance ( passing $this as parameter ) hooked functions.

All what's there for custom customize option type in update method is

return apply_filters( 'customize_value_' . $this->id_data[ 'base' ], $this->default );

Which falls short of serving the purpose because,

1. $this->id_data[ 'keys' ] is very much required for array based values so $this (or at least $this->id_data) must be passed.
2. Need to add it individually for each setting creating tons of duplication code smells.

In my opinion

return apply_filters( 'customize_value_' . $this->id_data[ 'base' ], $this->default );

can be replaced with something like this...

$value = apply_filters( 'customize_value_' . $this->id_data[ 'base' ], $this->default );
if ( $this->default == $value ) {
	/**
	 * Filter a Customize setting value not handled as a theme_mod or option.
	 *
	 * The dynamic portion of the hook name, `$this->type`, refers to the type of setting.
	 *
	 * For settings handled as theme_mods or options, see those corresponding
	 * functions for available hooks.
	 *
	 * @since x.x.x
	 *
	 * @param mixed $default The setting default value. Default empty.
	 * @param WP_Customize_Setting $this  WP_Customize_Setting instance.
	 */
	return apply_filters( 'customize_value_' . $this->type, $this->default, $this );
}
return $value;

[westonruter]

#36452 was marked as a duplicate.

[celloexpressions]

Let's reevaluate once we have an updated patch.

[westonruter]

Marking as low priority since all can be accomplished by subclassing WP_Customize_Setting, which is cleaner anyway and more encapsulated.