Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#33858 closed enhancement (worksforme)

Filter for WordPress option

Reported by: sebastian.pisula Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: Options, Meta APIs Keywords: reporter-feedback close
Focuses: Cc:

Description (last modified by johnbillion)

I can add filter to option. Good idea to ACF Page options.

add_filter( 'option', 'acf_options_page' );

function acf_options_page( $value, $option, $default ) {
	if ( $default == false ) {
		return get_field( $option, 'option' );

	return $value;

get_option( 'field_from_acf' );

Attachments (1)

options.patch (1.8 KB) - added by sebastian.pisula 6 years ago.

Download all attachments as: .zip

Change History (7)

#1 @SergeyBiryukov
6 years ago

  • Keywords reporter-feedback added

Hi @sebastian.pisula, thanks for the ticket.

There are three filters already in get_option():

  • pre_option_* to filter the value before it is retrieved and return early.
  • default_option_* to filter the default value.
  • option_* to filter the resulting value.

They should work for your use case too. Could you elaborate on why you think a new filter is needed?

#2 @sc0ttkclark
6 years ago

I can see a use for a general catch-all options filter for handling $default value, when an option isn't set otherwise, for more complicated usage. But I wasn't aware ACF stored options in a *different* place or named differently.

Anyways, it sounds like ACF itself has enough information about the option fields registered to make use of default_option_* filters itself in this case as core stands now. A filter like this should probably be named default_option too, and it would allow for one default callback being able to be set instead of setting 25-30+ callbacks, one for each default_option_*.

This applies to Pods too, as we allow traversal for relationship fields. We allow options to be created too, which store the relationship item ID, but having the ability to use interesting use cases like $color_id = get_option( 'featured_friend.favorite_color.ID' ); could be made possible within about 6-10 lines of code in Pods if this filter were available.

So overall, I'm in favor of a default option catch-all filter, I'm not in favor of the name option, and I'm confused why ACF would store an option value differently from an option name.

#4 @sc0ttkclark
6 years ago

At least in default_option, it wouldn't be run on every option call, so that's a mark towards inclusion of this particular option hook.

#5 @wonderboymusic
6 years ago

  • Keywords close added

I am almost positive that what is being proposed is already possible?

#6 @johnbillion
6 years ago

  • Description modified (diff)
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

As per comments above. The existing filters mean this is already possible.

Note: See TracTickets for help on using tickets.