Opened 2 years ago
Last modified 8 weeks 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: | 2nd-opinion needs-unit-tests has-patch |
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).
Change History (4)
This ticket was mentioned in PR #7495 on WordPress/wordpress-develop by @debarghyabanerjee.
2 months ago
#2
- Keywords has-patch added; needs-patch removed
Trac Ticket: Core-56548
## Overview
- This pull request introduces a new action for the get_option function in WordPress to allow developers to run specific logic when an option is being retrieved. The action is designed to facilitate the optimization of autoloaded options while ensuring backward compatibility.
## Changes Made
Added Action
: Introduced a new action named get_option that triggers when an option is read. This action accepts three
parameters
:
$option
: The name of the option being retrieved.
$value
: The value of the option.
$is_default
: A boolean indicating whether the value is based on the default rather than being retrieved from the database.
### Documentation
Properly documented the new action to clarify its intended use and to guide developers on how to implement custom logic without impacting performance negatively.
## Purpose
The addition of this action allows developers to optimize their use of options without replacing the existing filter mechanism, which is more suited for filtering option values. This change aims to:
- Enhance the performance of retrieving autoloaded options.
- Provide a clear and structured way for developers to hook into option retrieval processes.
- Ensure that developers are not misled into thinking this is a filtering mechanism.
## Compatibility
This new action is fully backward compatible and will not affect existing functionality. It serves as an enhancement for cases where custom logic is necessary when retrieving options.
@debarghyabanerjee commented on PR #7495:
2 months ago
#3
Hi @mukeshpanchal27 ,
Thanks for letting me know.
The reason I have raised the PR is that the problem statement was straight forward, and if we check on the other functions like add_option
, update_option
and delete_option
, these functions already have the actions implemented, so I generally checked the core's codebase and found that this can be implemented.
Please let me know your thoughts on this. Thanks.
@debarghyabanerjee commented on PR #7495:
8 weeks ago
#4
Hi @felixarntz , can you please take a look into this PR. Thanks.
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.