Opened 17 years ago
Closed 17 years ago
#10893 closed defect (bug) (fixed)
get_site_option should activate the same filters as the mu version
| Reported by: | mark-k | Owned by: | westi |
|---|---|---|---|
| Priority: | lowest | Milestone: | 2.9 |
| Component: | General | Version: | 2.8.4 |
| Severity: | normal | Keywords: | reporter-feedback needs-testing |
| Cc: | Focuses: |
Description
No much point in having the same function names if they behave differently.
Namely, call the pre_site_option_${key} filter before getting the option and site_option_${key} to filter the return value.
Attachments (1)
Change History (6)
#1
@
17 years ago
- Keywords reporter-feedback added
- Milestone Unassigned → 2.9
- Owner set to
- Status new → accepted
How is that?
Does this give you the same behaviour.
#4
follow-up:
↓ 5
@
17 years ago
- Keywords needs-testing added
- Resolution fixed
- Status closed → reopened
some feedback on the (as untested marked but comitted) patch:
$key is not validated in any of these functions.
a filter returning false as the value FAILS to work.
#5
in reply to: ↑ 4
@
17 years ago
- Resolution → fixed
- Status reopened → closed
Replying to hakre:
some feedback on the (as untested marked but comitted) patch:
$key is not validated in any of these functions.
The same as the mu function and the same as get_option itself.
a filter returning false as the value FAILS to work.
The same as the mu function and the same as get_option itself.
The idea behind this change was for that same behaviour to be preserved.
Closing as FIXED.
If you wish you could open a new ticket for a future release to all for shortcircuit to return false and be used.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Patch for the filters