[wp-trac] [WordPress Trac] #25834: WP_Date_Query not allowed values possible
WordPress Trac
noreply at wordpress.org
Sat Oct 11 01:36:28 UTC 2014
#25834: WP_Date_Query not allowed values possible
--------------------------+---------------------------
Reporter: ChriCo | Owner: boonebgorges
Type: defect (bug) | Status: accepted
Priority: normal | Milestone: 4.1
Component: Query | Version: 3.7
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
--------------------------+---------------------------
Changes (by boonebgorges):
* keywords: needs-patch needs-unit-tests 4.1-early => has-patch
* owner: => boonebgorges
* status: new => accepted
* milestone: Future Release => 4.1
Comment:
I am a fan of this approach and a fan of the patch. Silently sanitizing is
a bad idea because it can return improper results (if I request stuff from
the 13th month, the correct behavior is to give back nothing). Throwing a
WP_Error is, as noted above, not backward compatible, and may cause fatal
errors on existing installations. So I like the idea of throwing debug
notices.
[attachment:25834.patch] is a cleaned up version of ChriCo's second patch.
I've made the following changes:
* Instead of checking `WP_DEBUG` and calling `trigger_notice()`, use the
`_doing_it_wrong()` wrapper. It serves the same purpose, and is in keeping
with behavior elsewhere in WP. It also plays more nicely with our unit
tests (@expectedIncorrectUsage annotation instead of suppressing errors
with `@`).
* Moved unit tests to the appropriate file.
* Changed the behavior of 'before' and 'after' validation so that correct
errors are generated when these are used in combination with each other
and with other function params (plus a new unit test to demonstrate the
combinations).
* Coding standards, function naming, inline docs, etc.
I think this is a very nice improvement. Posting the patch here because
(a) Viper007Bond said he had some ideas for improving and I want to make
sure he gets a chance to look at it, and (b) I may wait until after #29822
has been settled, because the validation is going to have to work a bit
differently with nested params.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/25834#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list