WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 2 months ago

#29316 new enhancement

Need more value and preview hooks for WP_Customize_Settings

Reported by: dedepress Owned by:
Milestone: Future Release Priority: low
Severity: normal Version: 3.4
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description

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 );

Attachments (1)

class-wp-customize-setting.diff (1.6 KB) - added by mehulkaklotar 3 years ago.

Download all attachments as: .zip

Change History (19)

#1 @SergeyBiryukov
4 years ago

  • Type changed from feature request to enhancement

#2 @ocean90
4 years ago

Related: #29165

#3 @celloexpressions
4 years ago

  • Focuses administration removed
  • Version changed from 3.9.2 to 3.4

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).

#4 @dedepress
4 years ago

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.

Last edited 4 years ago by dedepress (previous) (diff)

#5 @westonruter
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

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.

#6 @westonruter
3 years ago

  • Milestone changed from Future Release to 4.2

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.

#7 @celloexpressions
3 years ago

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

#8 @westonruter
3 years ago

  • Type changed from enhancement to feature request

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

#9 @westonruter
3 years ago

  • Milestone changed from 4.2 to Future Release
  • Type changed from feature request to enhancement

#10 @westonruter
3 years ago

#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;
Last edited 3 years ago by westonruter (previous) (diff)

#11 @westonruter
2 years ago

  • Summary changed from Need more filters for WP_Customize_Settings to Need more value and preview hooks for WP_Customize_Settings

#12 @westonruter
2 years ago

#36452 was marked as a duplicate.

#13 @westonruter
2 years ago

  • Milestone changed from Future Release to 4.6

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


2 years ago

#15 @celloexpressions
2 years ago

  • Milestone changed from 4.6 to Future Release

Let's reevaluate once we have an updated patch.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


15 months ago

#17 @westonruter
15 months ago

  • Priority changed from normal to low

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

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


2 months ago

Note: See TracTickets for help on using tickets.