Opened 14 months ago
Last modified 13 months ago
#20439 new enhancement
Introduce __return_one function
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | General | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Attachments (1)
Change History (6)
bananastalktome — 14 months ago
I've had to create my own __return_zero() in order to set defaults (which cannot be overwritten by users) with filters pre_option_default_pingback_flag, pre_option_enable_xmlrpc, pre_option_use_trackback, etc., but I could just as easily see someone wanting to force open certain options as well with a __return_one(), which is why I decided to add this patch. Many of the options listed at http://codex.wordpress.org/Option_Reference use 0 or 1 as their value, so quick returns for their filter would be at least useful to some.
We use 1 and 0 because it is easy to store in a DB field. In reality you can simply use __return_true and __return_false.
It should be noted that will work for most situations. blog_public and a few other options could hypothetically have meaningful values > 1.
Replying to scribu:
I would argue that even __return_zero() isn't common enough.
I just had a pretty good use case for __return_zero() — I wanted to hook into pre_option_{$option} and turn an option off. Normally I would use __return_false but that is the value passed in that needs to be changed for the bypass to work (rather than null). So 0 it is.

Let's not get carried away with these.
I would argue that even __return_zero() isn't common enough.