Opened 2 years ago
Last modified 2 years ago
#56548 new enhancement
Introduce `get_option` action
Reported by: | flixos90 | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Options, Meta APIs | Keywords: | needs-patch 2nd-opinion needs-unit-tests |
Focuses: | Cc: |
Description
There has been the option_{$option}
filter for a long time, and it makes sense that this filter should be used to tweak options when reading them.
However, there is sometimes a need for running certain logic for when an option is being read. For example, the WordPress performance team is currently working on a feature to optimize the autoloaded options list.
For such purposes, we would like to add a new get_option
action:
- The reasoning for making it an action is to not falsely encourage developers to think they could use this to filter an option value (which would be excessive since it would be running for every option read).
- The action would get parameters for the option name, the value, and whether the value is based on the default (rather than being looked up from the database).
- The action name would be aligned with the existing actions
add_option
,update_option
, anddelete_option
. - It would be documented so that it should only be used for special cases (similar to e.g. the
all
filter).
Note: See
TracTickets for help on using
tickets.
One alternative idea that could solve this for here and other places in core would be a new suite of functions aallong the lines of:
do_dynamic_action
apply_dynamic_filters
add_dynamic_action
This could work in a backwards compatible way that allows
add_dynamic_action( 'option_{$option}', 'callback_on_them_all');
. One of the benefits I see is that we wouldn't need to worry about keeping two hooks in sync.