Why WP_Query::is_date() returns false when ‘date_query’ argument is set?

WordPress 3.7 introduced ‘date_query’ argument for WP_Query.

That’s pretty useful and allow very complex date-based queries, however something strange happen when using WP_Query conditional methods on query using that argument.

Example:

$args = array(

  'tax_query'=> array(
    'relation' => 'AND',
    array(
      'taxonomy' => 'category',
      'field'    => 'slug',
      'terms'    => 'uncategorized'
    ),
    array(
      'taxonomy' => 'post_tag',
      'field'    => 'slug',
      'terms'    => array('foo', 'bar')
    )
  ),

  'date_query' => array(
     array(
       'year'  => $today["year"],
       'month' => $today["mon"],
       'day'   => $today["mday"],
     )
  )

);

$query = new WP_Query( $args );

The query should returns posts posted today and having ‘uncategorized’ category or ‘foo’ and ‘bar’ tags. And it does, so far so good.

Now consider the following conditional methods:

$query->is_archive();  // returns true, as guessable
$query->is_category(); // returns true, as guessable
$query->is_tag();      // returns true, as guessable

but

$query->is_date();  // returns false
$query->is_day();   // returns false
$query->is_month(); // returns false
$query->is_year();  // returns false

I thought that the problem can be caused by the fact I mixed ‘tax_query’ and ‘date_query’, but that’s not the problem, proof:

$args = array(
  'date_query' => array(
     array(
       'year'  => $today["year"],
       'month' => $today["mon"],
       'day'   => $today["mday"],
     )
  )
);

$query = new WP_Query( $args );

$query->is_date();    // returns false
$query->is_day();     // returns false
$query->is_month();   // returns false
$query->is_year();    // returns false
$query->is_archive(); // returns false this time

Is this a bug, or I’m missing something? (I’ve searched WP Trac, but found nothing related).

The values retrieved by the is_date(), is_day(), etc. methods are set inside the parse_query method and they really seem to be intended for the main query, whether that is explicitly stated (intended) or not. The code parses the public query variables to determine those settings.

My interpretation is that these values aren’t really meant for secondary queries, and really don’t make much sense for secondary queries either. You’ve just run the query, you know that it is a date/tax/whatever query. That part doesn’t need to be determined for you by parsing the query variables.

To did a bit deeper, I’d say the problem stems from WP_Query being a bit schizophrenic. It parsed the request to determine which page ought to load, rather than just being a tool to query the database for posts. It does two jobs, rather than one, which is poor design in my opinion. I think distinct code should parse the request and then pass arguments to WP_Query. Maybe that is just me.

Is it a bug? I’d call it that, at least “weird design”. If WP_Query is going to do both jobs, it should at least set the class variables consistently, or split the class into two each with a single purpose. Of course, I don’t get to canonically declare something a “bug” or not 🙂