WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 19 months 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:
PR Number:

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)

#1 @soulseekah
19 months ago

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.

#2 @programmin
19 months 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?

Note: See TracTickets for help on using tickets.