I'm having a view using dates to sort out what nodes to show. The dates are possible to input via the exposed filters and overall it works fine. the problem I have though is that I want the users to have to specify start and end dates, thus I leave the Optional checkbox unchecked. Still, the output of the exposed filters contains options along the line of '-Year' and -Month' (shown like that WITH the Html code in Safari in the select list as well) which, when selected, results in all nodes being shown.

For the Taxonomy filter of the View I've checked and unchecked the Optional checkbox and the option is abled/disabled as it should there, so it seems to be a problem only with dates.

The View exported:

$view = new view;
$view->name = 'regionskarta';
$view->description = 'Hämtar alla noderna i det län som skickas som argument';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
  ),
  'body' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => 'test',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'exclude' => 0,
    'id' => 'body',
    'table' => 'node_revisions',
    'field' => 'body',
    'relationship' => 'none',
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'aktivitet' => 'aktivitet',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Override',
    ),
  ),
  'tid' => array(
    'operator' => 'or',
    'value' => array(),
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'tid_op',
      'identifier' => 'tid',
      'label' => 'Län:',
      'optional' => 0,
      'single' => 1,
      'remember' => 1,
      'reduce' => 0,
    ),
    'type' => 'select',
    'limit' => TRUE,
    'vid' => '1',
    'id' => 'tid',
    'table' => 'term_node',
    'field' => 'tid',
    'hierarchy' => 0,
    'relationship' => 'none',
    'reduce_duplicates' => 0,
  ),
  'tid_1' => array(
    'operator' => 'or',
    'value' => '',
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'tid_1_op',
      'identifier' => 'tid_1',
      'label' => 'Typ av aktivitet:',
      'optional' => 1,
      'single' => 0,
      'remember' => 0,
    ),
    'type' => 'textfield',
    'limit' => TRUE,
    'vid' => '2',
    'id' => 'tid_1',
    'table' => 'term_node',
    'field' => 'tid',
    'hierarchy' => 0,
    'relationship' => 'none',
    'reduce_duplicates' => 0,
  ),
  'date_filter' => array(
    'operator' => '>=',
    'value' => array(
      'value' => NULL,
      'min' => NULL,
      'max' => NULL,
      'default_date' => 'now',
      'default_to_date' => '',
    ),
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'date_filter_op',
      'identifier' => 'date_filter',
      'label' => 'Från:',
      'optional' => 0,
      'remember' => 0,
    ),
    'date_fields' => array(
      'node_data_field_date.field_date_value2' => 'node_data_field_date.field_date_value2',
    ),
    'date_method' => 'AND',
    'granularity' => 'day',
    'form_type' => 'date_select',
    'default_date' => 'now',
    'default_to_date' => '',
    'year_range' => '-0:+3',
    'id' => 'date_filter',
    'table' => 'node',
    'field' => 'date_filter',
    'relationship' => 'none',
  ),
  'date_filter_1' => array(
    'operator' => '<=',
    'value' => array(
      'value' => NULL,
      'min' => NULL,
      'max' => NULL,
      'default_date' => 'now +7 day',
      'default_to_date' => '',
    ),
    'group' => '0',
    'exposed' => TRUE,
    'expose' => array(
      'use_operator' => 0,
      'operator' => 'date_filter_1_op',
      'identifier' => 'date_filter_1',
      'label' => 'Till:',
      'optional' => 0,
      'remember' => 0,
    ),
    'date_fields' => array(
      'node_data_field_date.field_date_value' => 'node_data_field_date.field_date_value',
    ),
    'date_method' => 'AND',
    'granularity' => 'day',
    'form_type' => 'date_select',
    'default_date' => 'now +7 day',
    'default_to_date' => '',
    'year_range' => '-0:+3',
    'id' => 'date_filter_1',
    'table' => 'node',
    'field' => 'date_filter',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Override',
    ),
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('items_per_page', 0);
$handler->override_option('use_more', 0);
$handler->override_option('distinct', 1);
$handler->override_option('style_plugin', 'gmap');
$handler->override_option('style_options', array(
  'grouping' => '',
  'macro' => '[gmap height=300px | width=100%]',
  'datasource' => 'location',
  'markers' => 'static',
  'markertype' => 'alltforbarn marker',
));
$handler->override_option('row_options', array(
  'inline' => array(),
  'separator' => '',
  'hide_empty' => 0,
));
$handler->override_option('exposed_block', TRUE);
$handler = $view->new_display('block', 'Block', 'block_1');
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);
$handler = $view->new_display('panel_pane', 'Gmap Panel', 'panel_pane_1');
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
  ),
));
$handler->override_option('style_options', array(
  'grouping' => '',
  'macro' => '[gmap height=300px | width=100%]',
  'datasource' => 'location',
  'markers' => 'taxonomy',
  'markertype' => 'alltforbarn marker',
));
$handler->override_option('pane_title', 'regionskarta-Gmap');
$handler->override_option('pane_description', '');
$handler->override_option('pane_category', array(
  'name' => 'View panes',
  'weight' => 0,
));
$handler->override_option('allow', array(
  'use_pager' => FALSE,
  'items_per_page' => FALSE,
  'offset' => FALSE,
  'link_to_view' => FALSE,
  'more_link' => FALSE,
  'path_override' => FALSE,
  'title_override' => FALSE,
  'exposed_form' => FALSE,
));
$handler->override_option('argument_input', array());
$handler->override_option('link_to_view', 0);
$handler->override_option('inherit_panels_path', 0);
$handler = $view->new_display('panel_pane', 'HTML-lista', 'panel_pane_2');
$handler->override_option('style_plugin', 'list');
$handler->override_option('style_options', array(
  'grouping' => '',
  'type' => 'ul',
));
$handler->override_option('pane_title', 'regionskarta-html');
$handler->override_option('pane_description', '');
$handler->override_option('pane_category', array(
  'name' => 'View panes',
  'weight' => 0,
));
$handler->override_option('allow', array(
  'use_pager' => FALSE,
  'items_per_page' => FALSE,
  'offset' => FALSE,
  'link_to_view' => FALSE,
  'more_link' => FALSE,
  'path_override' => FALSE,
  'title_override' => FALSE,
  'exposed_form' => FALSE,
));
$handler->override_option('argument_input', array());
$handler->override_option('link_to_view', 0);
$handler->override_option('inherit_panels_path', 0);
CommentFileSizeAuthor
#25 681450-25-views.php_.txt8.96 KBjbylsma
#15 681450.view_.txt3.06 KBBevan
#8 date-681450-2.patch1.41 KBjbylsma
#7 date-681450.patch617 bytesmaijs
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Project: Views (for Drupal 7) » Date
Version: 6.x-2.6 » 6.x-2.x-dev
Component: exposed filters » Code

AS per the submission guidelines.

FreddieK’s picture

FreddieK CreditAttribution: FreddieK commented
Project: Date » Views (for Drupal 7)
Version: 6.x-2.x-dev » 6.x-2.6
Component: Code » exposed filters

The problem seems to be that no matter if the date filters are set to 'optional' => 0, or 1 the result is the same, with the any option showing.

Oh, and what I meant is that in the Select list the string output is including the html tags, literally outputting them in the list.

-<span id="thmr_62" class="thmr_call">Year</span>
FreddieK’s picture

FreddieK CreditAttribution: FreddieK commented
Project: Views (for Drupal 7) » Date
Version: 6.x-2.6 » 6.x-2.x-dev
Component: exposed filters » Code

(Sorry, was writing the last reply while you answered so accidently changed back the values)

FreddieK’s picture

FreddieK CreditAttribution: FreddieK commented
Status: Active » Needs work

So, this far I've found that I can solve my problem (not a nice solution though) in the function date_select_process() in date_api_elements.inc.

//Ca line 250 in date_api_elements.inc
//No such variable as $element['#required'] available makes this expression always evaluate as false.
    $part_required = ($element['#required'] && is_object($date)) ? TRUE : FALSE;

// Bad fix
    $part_required = TRUE;
    if($part_required == TRUE) {
		$element['#date_label_position'] = 'none';
   }
// End bad fix

I can't find where the 'optional' variable from Views disappears to set it as $element['#required'] which would be the general solution to get the 'optional' checkbox to work.

Also, when $part_required is set to true, it should also change $element['#date_label_position'] from 'within' to 'none', otherwise the extra option will still be created (and given the name, if only $element['#date_label_position'] is changed an empty select option will still generate).

gunzip’s picture

gunzip CreditAttribution: gunzip commented

I've the inverse problem for an exposed optional date filter. Even if i leave the defaults blank in the filter settings, no matter what, i still obtain a where clause ( = 2010-01-01 ...) that shouldn't be there. It looks like optional exposed date filter for view doesn't work (i've tried with both stable and dev version) at all...

chellman’s picture

chellman CreditAttribution: chellman commented

Subscribing. There's a more recent issue #717682: Views filter "optional" option not working? that seems to be a duplicate, but has some other, different code as well.

maijs’s picture

maijs CreditAttribution: maijs commented
Status: Needs work » Needs review
FileSize
date-681450.patch617 bytes

chellman, I think it's not a duplicate of #717682: Views filter "optional" option not working? rather than a bug in Date API. I found that in date_api_elements.inc file, there is an uncommented line that makes all the difference with '#required' element in form array. With this fix, I don't get any (= 2010-01-01) statements in sql query if field it empty.

Patch is provided for 6.x-2.x-dev, will also do for 6.x-2.4.

Patch for date_api_elements.inc is quite simple (around line 154).

   // Keep the system from creating an error message for the sub-element.
   // We'll set our own message on the parent element.
-  //$element['date']['#required'] = $element['#required'];
+  $element['date']['#required'] = $element['#required'];
   $element['date']['#theme'] = 'date_textfield_element';
   if (isset($element['#element_validate'])) {
jbylsma’s picture

jbylsma CreditAttribution: jbylsma commented
FileSize
date-681450-2.patch1.41 KB

The patch appears to work as expected, but it appears that the view would still use a default value if the exposed filter wasn't set (the initial loading of a view). I added a check in the "includes/date_api_filter_handler.inc" file that will allow the view to not set a default value if the filter has been marked optional. The attached patch file includes maijs' patch from comment #7. I have checked this against 6.x.-2.4 but not against the dev branch.

In doing this, I realized that the filter isn't behaving correctly if the field is required. Filters that are optional are working just fine. I wrote out what I anticipated as the expected behaviors below:

  • If filter is required
    • Initial loading of view uses default date value
    • Initial loading of exposed filter populates default date value
    • Submission of an empty exposed filter returns an error
    • Submission of a valid exposed filter returns the proper subset
  • If filter is optional
    • Initial loading of view shows all matches
    • Initial loading of exposed filter is empty or "all" value
    • Submission of an empty exposed filter does not effect query
    • Submission of a valid exposed filter returns the proper subset

I'm generally familiar with Views and the Date module, but if I'm missing something or this isn't what the default behavior should be, please let me know! Fixing the required field isn't a priority for me, but hopefully I might get some time in the future to address it.

YK85’s picture

YK85 CreditAttribution: YK85 commented

subscribing

YK85’s picture

YK85 CreditAttribution: YK85 commented

Is this related to #856238: exposed filter of created date with "Is between" and optional returns empty results?

gunzip’s picture

gunzip CreditAttribution: gunzip commented

the patch works for me.

crea’s picture

crea CreditAttribution: crea commented

Subscribing

Bevan’s picture

Bevan CreditAttribution: Bevan commented
Title: Exposed date filter optionality not optional? » Views optional exposed date filter does not work without value
Priority: Minor » Major
Status: Needs review » Reviewed & tested by the community

The patch from comment #8 fixes the bug. It will take longer to test this more extensively, but here is more detail on how to reproduce the bug consistently. Unless otherwise specified, use default settings on all forms;

  1. Install a new Drupal 6 site with current stable versions of Drupal 6, CCK & Date and Devel Generate and dependencies.
  2. Install Views 3 dev as of November 24. Other reports above suggest this is also reproducible on Views 2 stable.
  3. Add a Date field (any of the date types) to a content type.
  4. Create content of that type with Devel Generate. (It will automatically populate the date field.)
  5. Create a new node view.
  6. Set the row style to node teasers or add a title field, So the the view is valid and the preview functions.
  7. Note that the generated nodes are returned in the preview area, and that the SQL query is pretty straight forward with no WHERE clause.
  8. Add a Date filter
  9. Set the "Date form type" to "Text". (Some reports, such as #717682: Views filter "optional" option not working?, suggest this is reproducible with "Select" too, though I have had trouble consistently reproducing the error with the "Select" widget.)
  10. Select the CCK date field that you created earlier.
  11. Click "Update"
  12. On the next configuration form, click "Expose"
  13. Click "Update"
  • Expected behaviour: The preview has the same content and SQL query is the same, since the exposed date filter is (by default) "Optional" and no value was set to filter by.
  • Actual behaviour: The preview is empty (0 rows) and the SQL query has the following clause WHERE DATE_FORMAT(ADDTIME(STR_TO_DATE(node_data_field_date.field_date_value, '%Y-%m-%%dT%T'), SEC_TO_TIME(46800)), '%Y-%m-%%d') = '2010-01-01'. Note especially the presence of "2010-01-01", which is seemingly being generated from nowhere.
  1. Apply the patch from comment #8. (No need to clear caches)
  2. Click "Preview"
  3. Note the SQL query and preview now match the "Expected behaviour" above.
Bevan’s picture

Bevan CreditAttribution: Bevan commented

yaz086; #856238: exposed filter of created date with "Is between" and optional returns empty results is about date filters for node dates that are supported in views, while this ticket is about CCK Date fields, supported by date module. Though the bugs are very similar, the causes and fixes are entirely unrelated.

Bevan’s picture

Bevan CreditAttribution: Bevan commented
FileSize
681450.view_.txt3.06 KB

The attached view for Views 3 is what results from the steps in comment #13.

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Status: Reviewed & tested by the community » Needs work

This is a lovely report with lots of details. I can replicate the problem but the patch does not fix it. And I'm not sure I agree with the idea of what *should* happen anyway.

If a field is required and empty I think the query should return nothing until the filter is populated. It makes no sense to me to force a required filter to be as generous as possible (i.e. show everything) until it is populated. It should show nothing.

The default behavior of 2010-01-01 is totally wrong of course, I'm still digging around to figure out where that is getting set.

Bevan’s picture

Bevan CreditAttribution: Bevan commented

If a field is required and empty I think the query should return nothing until the filter is populated. It makes no sense to me to force a required filter to be as generous as possible (i.e. show everything) until it is populated. It should show nothing.

I assume you mean "filter" instead of "field"?

The filter is not required. It is optional. As per "Expected behaviour" in comment #13, the default for Views filters (at least in Views 3) is for "Optional" to be checked.

What do you mean by "the patch does not fix it"? If you unchecked "Optional", then the patch might not make a difference to the actual behaviour (needs testing). Of course your expected behaviour will probably be different to comment #13! (:

The default behavior of 2010-01-01 is totally wrong of course, I'm still digging around to figure out where that is getting set.

Comment #2 on #717682 (Closed - Duplicate) has an explanation that maybe useful;

The fix works by stopping the Date API from forcing empty values for date parts (year, month, day, etc) entered via select fields to default values (eg forcing an empty or zero value for a month or day to be 1) in certain cases. If the granularity is year,month,day and a value is entered for year and month but not day then the granularity of the field is effectively reduced to year,month. However if a value is entered for the day but not the month then the month value will still be forced to 1; so this isn't a solution to the "birthday" filtering problem. Which is one reason why this is probably more of a hack than a proper solution.

TommyK’s picture

TommyK CreditAttribution: TommyK commented

Would the same underlying problem here be the same reason that I cannot get Date Arguments to work when I have an optional To field?

I can create a date field that has either a To field Never or Required and the View works with Year granularity as an argument, but if the field has an optional To field the View returns nothing. This is when I am using From date as the source for the argument, so it doesn't quite make sense that the To field would matter.

I can create a new issue with steps to reproduce if it would not be a duplicate.

Bevan’s picture

Bevan CreditAttribution: Bevan commented

TommyK; That is probably not the same problem and sounds like a different bug. Please look for another issue with the same symptoms as yours, or create a new issue node with the most steps possible on how to reproduce the bug.

gagarine’s picture

gagarine CreditAttribution: gagarine commented
Status: Needs work » Reviewed & tested by the community

I think comment in #16 is a misunderstood of the problem see #17.

brunorios1’s picture

brunorios1 CreditAttribution: brunorios1 commented

I agree with KarenS in #16...

If a field is required and empty I think the query should return nothing until the filter is populated. It makes no sense to me to force a required filter to be as generous as possible (i.e. show everything) until it is populated. It should show nothing.

I'm having the same problem.

I have a Map with events, and i need to "force" the users to choose a Date (day granularity)...
But even unchecking "optional", the view don't require a date and if i leave empty, it shows all the events of the site in the map...

Agileware’s picture

Agileware CreditAttribution: Agileware commented

Subscribing

Patch in #8 works here for both required and optional cases

arlinsandbulte’s picture

arlinsandbulte CreditAttribution: arlinsandbulte commented
Assigned: Unassigned » arlinsandbulte

Putting on my list to review and commit...

arlinsandbulte’s picture

arlinsandbulte CreditAttribution: arlinsandbulte commented
Assigned: arlinsandbulte » Unassigned
Priority: Major » Normal
Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

In my testing, this patch is not needed.

Without the patch:
Creating an exposed filter with select list format & all default values blank, all nodes are displayed by default (nothing is filtered out).
Selecting a date in the exposed filter does properly apply that filter.

With the patch (had to re-roll it as it did not apply an more):
The above behavior was unchanged.

NOTE:
If the exposed filter values are only partially filled out, for instance leaving one or more of the date elements empty, all values are returned. This may not be the desired behavior.
If anything here needs work it is that.

jbylsma’s picture

jbylsma CreditAttribution: jbylsma commented
FileSize
681450-25-views.php_.txt8.96 KB

I tested the following against Views 6.x-2.16 and Date 6.x-2.x-dev (two commits after 6.x-2.9).

I extended Drupal's provided "Page" content type with a Date CCK field and generated 50 "Page" nodes using devel generate. The generated dates range from 2009 to 2015.

I configured four Views with the following:

  • Pager: off
  • Fields: "Content: Date" and "Node: Title"
  • Sort: "Content: Date" Ascending
  • Filters: "Content: Date"
    • Date form type: varying (see chart below)
    • Granularity: Year
    • Date year range: -3:+3
    • Date field(s): Content: Date
    • Method: OR
    • Operator: Is Equal To
    • Absolute value: (empty)
    • Date form type: varying (see chart below)
    • Optional: varying (see chart below)
    • Date default: (empty)
    • To date default: (empty)
Filter Type Optional / Required Expected exposed filter setting Actual exposed filter setting Expected View results Actual View results Additional Information
Select Optional Set to ALL value (-Year) Set to generated default value (2012) All values returned Generated default (2012) values returned
Select Required Set to generated default value (2012) Set to ALL value (-Year) Generated default (2012) values returned All values returned Allows exposed filter to be ALL (-Year), even though the exposed filter is required.
Text Optional Set to (empty) Set to generated default value (2012) All values returned Generated default (2012) values returned
Text Required Set to generated default value (2012) Set to (empty) Generated default (2012) values returned Generated default (2012) values returned Allows exposed filter to be (empty), even though the exposed filter is required. An (empty) exposed filter returns all values.

(Ahem, no thanks to Google Docs Spreadsheet "Download As" HTML. That outputted an HTML nightmare and required a near-complete reformat)

I expected the following behavior for the Views Date filters' fields "Date default" and "To date default" values

  • Required filters: defaults should be automatically generated
  • Optional filters: defaults should not be automatically generated

Looking at the data, it appears that all expected exposed filter settings are incorrect and only the Text/Required view is displaying the correct initial values. In addition, the two required fields are both allowing exposed filters to be bypassed.

I rerolled the patch I posted in #681450-8: Views optional exposed date filter does not work without value but it appears that it breaks current functionality and doesn't fix any current issues. When I had originally posted the patch, I was looking to create an optional Date exposed filter textbox that showed all values by default but allowed users to enter a specific year to narrow results. I believe my original issue what that, even though my exposed filter was optional, the result set was automatically filtered to the generated default value. That was quite a while ago and I can't easily test if that's the case anymore.

I've attached the Views I created to generate all of the data. Hopefully this will at least illuminate the issues at hand.

jbylsma’s picture

jbylsma CreditAttribution: jbylsma commented
Status: Postponed (maintainer needs more info) » Active

One day I will remember to update the issue settings before I post...

Bevan’s picture

Bevan CreditAttribution: Bevan commented
Status: Active » Needs work

Thank you for the fantastically detailed testing and report. It looks like this patch needs more work then?

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna at Mediacurrent commented
Status: Needs work » Closed (won't fix)

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.