Opened 6 years ago
Last modified 6 years ago
#43704 new defect (bug)
pre_option_{$option} filter is case sensitive although options are not.
Reported by: | programmin | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 4.9.5 |
Component: | Options, Meta APIs | Keywords: | |
Focuses: | Cc: |
Description
I noticed the filter "pre_option_{$option}" for myOption wouldn't filter get_option('MYOption') for example, yet get_option(name) and MySql in general does not seem to care what case the option is. Perhaps it should also do pre_option_(strtolower($option)) when necessary?
Was there a reason this particular filter is case-sensitive?
Change History (2)
#2
@
6 years ago
How would this break "a lot of things"? Are people using the filter to purposely get_option('mYopTION') so they can filter 'pre_option_mYopTION' and only filter certain cases you're getting an option?
In general I'd think this would help developers like myself that had debugged an hour or more and then realized various parts of code just aren't get_option() with the exact same case. Backward-compatibility comes first though I suppose. Can there be a pre_option_nocase_{option} filter perhaps?
This stems from MySQL.
select * from wp_options where option_name = 'siteUrl';
is equal to
select * from wp_options where option_name = 'siteurl';
select * from wp_options where binary(option_name) = 'siteUrl';
is not equal to
select * from wp_options where binary(option_name) = 'siteurl';
The former is used in the Options API. This is expected.
As for your suggestion to do
pre_option_(strtolower($option))
, please note that:add_filter( 'pre_option_MyOption' )
!=add_filter( 'pre_option_myoption' )
You would need to make filter and action tags case-insensitive. This might break a lot of things out there.