I'm not sure if this is a bug or a missing feature, but here goes:

You can't filter by date fields with EFQ Views like you can with a regular Views.

I've created a test content type with a single date type field. Then, I created a regular View that shows those nodes, and added a filter for the date field. As expected, the modal window gives the date-specific filtering options.

Creating a similar View with EFQ Views, and adding the date field as a filter, the modal window gives filtering options like those of a text field.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Do you use the Date module?

firebird’s picture

Yes.

chx’s picture

Category: bug » feature

That's gonna be a challenge. I can not promise anything any time soon. I will try to slot this in some time in June. (I will check with my boss and if it's a priority for 10gen then obviously it will get done ASAP but he didn't indicate anything like that) My priority right now is entityreference.

firebird’s picture

Status: Active » Needs review
FileSize
4.24 KB

Well, I decided to give it a go myself. Here's the patch. Very brief testing suggests that it works, but seeing as I have no experience in coding for Views, let alone EFQ Views, someone should go through the patch.

chx’s picture

Just like that and it works? Wowsie. Nice job. I havent yet applied but don't you need a field handler for proper output options?

firebird’s picture

Umm... I don't know. I just checked how it was done with the other content types and copied off that.

The patch includes a file called "efq_views_handler_filter_field_date.inc" . Is that a field handler?

What output options do you mean? How does a filter have output options?

I did check the options in the Views UI's "Fields" section, the date field's modal settings window, and they look like the ones in a regular View's date filter.

You know what to test and look for, so please apply the patch on a test installation and have look, when you have the time.

firebird’s picture

I think I messed up the patch regarding the newly added files. This might work better.

chx’s picture

I do not mean the filter, I mean display settings: field (which I think is the default) and then add field. I will check myself this the weekend if you don't get to it.

chx’s picture

Oh sorry: the issue is about filter handlers and I was talking field handlers. Will take another look today.

japerry’s picture

Doesn't apply cleanly to the latest version of efq_views

patching file efq_views.info
Hunk #1 succeeded at 33 (offset -6 lines).
Hunk #2 FAILED at 42.
1 out of 2 hunks FAILED -- saving rejects to file efq_views.info.rej
patching file efq_views.views.inc
Hunk #1 FAILED at 222.
1 out of 1 hunk FAILED -- saving rejects to file efq_views.views.inc.rej
patching file handlers/efq_views_handler_filter_date.inc
patching file handlers/efq_views_handler_filter_field_date.inc

japerry’s picture

Status: Needs review » Needs work

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /admin/structure/views/view/event_listing/preview/page/ajax
StatusText: OK
ResponseText:
( ! ) Fatal error: Call to undefined function efq_views_op_prepare() in modules/efq_views/handlers/efq_views_handler_filter_field_date.inc on line 5
Call Stack
#TimeMemoryFunctionLocation
10.0001725736{main}( )../index.php:0
20.487164865064menu_execute_active_handler( )../index.php:21
30.499867032096call_user_func_array
( )../menu.inc:516
40.499867032520views_ui_build_preview( )../menu.inc:516
50.510467569848views_ui_preview( )../admin.inc:954
60.554370447760view->preview( )../admin.inc:176
70.557470598800views_plugin_display->preview( )../view.inc:1360
80.557470598848view->render( )../views_plugin_display.inc:2673
90.557470598896view->execute( )../view.inc:1184
100.557470598896view->build( )../view.inc:1116
110.576872112904view->_build( )../view.inc:987
120.577072114616efq_views_handler_filter_date->query( )../view.inc:1098
130.577172121752efq_views_handler_filter_field_date->op_simple( )../efq_views_handler_filter_date.inc:60

chx’s picture

Title: Support for date field filtering » Add tests for date field filtering
Category: feature » task
Status: Needs work » Fixed

Date module support has been added although it isn't using anything from this patch. Tests would be welcome.

chx’s picture

Status: Fixed » Active
japerry’s picture

Status: Active » Needs review
FileSize
20.27 KB

I've re-rolled a patch that adds granularity and other date functions to the date filter.

majorrobot’s picture

I've also run into the need for granularity, etc. in the date filter. I applied the patch from #14 and discovered that the patch only helps in the case of datestamp fields (aka Date (Unix Timestamp)).

I'm new at working with Views handlers, but it looks like the issue is in the op_simple() method where strtotime() is called on $value. This, of course, converts the value — with which we're performing the EFQ — into a Unix timestamp. If your field is a type of date field that is not datestamp, the query will likely return nothing.

To get around this, I'd recommend a few changes to the patch.

In op_simple(), add a switch statement to treat $value differently, depending on field type:

function op_simple($field) {
    $raw_value = $this->get_filter_value('value', $this->value['value']);
    
    switch($this->date_handler->date_type){
    	
    	case DATE_DATETIME:
    	  $value = $raw_value;
    	break;
    	
    	default:
    	case DATE_UNIX:
    	  $value = strtotime($raw_value);
    	break;
    }
    
    return $value;
  }

This, of course, only helps in the case of datetime fields — the iso_date type should be added, as well. I did play with that one for a bit, but did not make any progress.

I also noticed that the init() method doesn't discriminate between type of date field either. Therefore, I'd recommend moving the creation of the date_handler after the call for field info:

function init(&$view, &$options) {
    parent::init($view, $options);
    module_load_include('inc', 'date_api', 'date_api_sql');
    
    if (!empty($this->definition['field_name'])) {
      $field = field_info_field($this->definition['field_name']);
      if (!empty($field) && !empty($field['type'])) {
        $this->date_handler = new date_sql_handler($field['type']);
        $this->date_handler->date_type = $field['type'];
      }
      $this->date_handler->db_timezone = date_get_timezone_db($field['settings']['tz_handling']);
      $this->date_handler->local_timezone = date_get_timezone($field['settings']['tz_handling']);
    }
    $this->form_submitted = FALSE;
    $this->date_handler->granularity = isset($options['granularity']) ? $options['granularity'] : 'day';
    $this->format = $this->date_handler->views_formats($this->options['granularity'], 'sql');

    // Identify the base table for this field.
    // It will be used to call for the right query field options.
    $this->base_table = $this->table;

  }

I'm not certain whether this changes much, but seems to be a step in the right direction if the code is depending on a date_handler.