[wp-trac] [WordPress Trac] #33858: Filter for WordPress option

[WordPress Trac]

#33858: Filter for WordPress option
--------------------------------+------------------------------
 Reporter:  sebastian.pisula    |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Options, Meta APIs  |     Version:  4.3
 Severity:  normal              |  Resolution:
 Keywords:  reporter-feedback   |     Focuses:
--------------------------------+------------------------------

Comment (by sc0ttkclark):

 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.

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