[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