Exposed grouped filter for date not working

Any updates? We are running a pet adoption website and we would love to have an age filter ...

i don't see the input box for entering value either when using grouped exposed filter.

I am also patiently waiting a fix for this,. I am not provided with a box to enter relative dates.

My date filter (I made it as described on http://drupal.org/node/1764902#comment-6732320)

  $handler->display->display_options['filters']['field_recall_date_value']['id'] = 'field_recall_date_value';
  $handler->display->display_options['filters']['field_recall_date_value']['table'] = 'field_data_field_recall_date';
  $handler->display->display_options['filters']['field_recall_date_value']['field'] = 'field_recall_date_value';
  $handler->display->display_options['filters']['field_recall_date_value']['operator'] = '<=';
  $handler->display->display_options['filters']['field_recall_date_value']['exposed'] = TRUE;
  $handler->display->display_options['filters']['field_recall_date_value']['expose']['operator_id'] = 'field_recall_date_value_op';
  $handler->display->display_options['filters']['field_recall_date_value']['expose']['label'] = 'Recall date';
  $handler->display->display_options['filters']['field_recall_date_value']['expose']['operator'] = 'field_recall_date_value_op';
  $handler->display->display_options['filters']['field_recall_date_value']['expose']['identifier'] = 'field_recall_date_value';
  $handler->display->display_options['filters']['field_recall_date_value']['is_grouped'] = TRUE;
  $handler->display->display_options['filters']['field_recall_date_value']['group_info']['label'] = 'Recall date';
  $handler->display->display_options['filters']['field_recall_date_value']['group_info']['identifier'] = 'field_recall_date_value';
  $handler->display->display_options['filters']['field_recall_date_value']['group_info']['group_items'] = array(
    1 => array(
      'title' => 'Current',
      'operator' => '<=',
      'value' => array(
        'value' => array(
          'value_choose_input_type' => 'relative',
          'value' => NULL,
          'default_date' => 'now',
        ),
        'min' => array(
          'min_choose_input_type' => 'relative',
          'min' => NULL,
          'default_date' => 'now',
        ),
        'max' => array(
          'max_choose_input_type' => 'relative',
          'max' => NULL,
          'default_to_date' => 'now',
        ),
      ),
    ),
    2 => array(
      'title' => 'Future',
      'operator' => '>',
      'value' => array(
        'value_group' => array(
          'value_choose_input_type' => 'relative',
          'value' => NULL,
          'default_date' => 'now',
        ),
        'min_group' => array(
          'min_choose_input_type' => 'relative',
          'min' => NULL,
          'default_date' => 'now',
        ),
        'max_group' => array(
          'max_choose_input_type' => 'relative',
          'max' => NULL,
          'default_to_date' => 'now',
        ),
      ),
    ),
  );
  $handler->display->display_options['filters']['field_recall_date_value']['default_date'] = 'now';

Filter works in view preview only.

Group filter values from exposed filter aren't processed correctly. Attached patch fix it (it isn't very good decision, but I think maintainer will understand where bug is).

sinn, can you explain a bit what you did and what bug you fixed ? because after i applied your patch, i still don't see the input box appear. Thanks a ton.

with my patch exposed filter works not only in preview.
i didn't fix UI of settings page.

if the UI wasn't fixed how were you able to enter anything in the fields ?

http://drupal.org/node/1764902#comment-6732320 -> export views -> change settings -> import views.

I was able to use (more or less) the same group filter as in #4, but when I needed to use this view not in preview *and* using ajax, I had to make the following modifications to the patch in #7 for it work appropriately. This patch includes the changes in #7.

Check line 104 - you have changed meaning of "if" condition.

elseif (isset($this->options['expose']['identifier']) && !isset($_REQUEST[$this->options['expose']['identifier']])) {

i'm pretty shocked when I see this bug is still not fixed or committed by the author. And the last updated developer version was from last year.

ok, maybe this has been fixed by date_views ? actually it's working without the above patch. see attached picture.

@windmaomao

Two questions:

What version of date are u using ?
Did u test this with a custom date field that has a start and end date ?

My use case is for filtering events

Confirm this issue with Views 3.7 and Date 2.6. Patch from #13 isn't solve the problem.
When I change manually group item type from 'offset' to 'relative' (export > change in text editor > import) - it saved correctly, but not work normally, dates are generated like date, not relative.

#18 confirmed. Not fixed yet in views 3.7 and date 2.6. :-(

UI still broken, and once you get it set up like you want to, the grouped filter still only work in the view preview and not on the actual page.

#13 fixed the filter on the actual page for me

I'm confused by this issue.

The patch in #13 is already a part of Date 7.x-2.6, but it's not working either.

@Kim Kahns: Are you applying patch #13 as a reverse patch to remove the code that it says it wants to add because that's what it tries to do any time I apply it to 7.x-2.6.

This is a partial patch. It only fixes the handler, not the Views UI. The UI bit was fixed by exporting the view using Features and set the filters in code.

array(
  1 => array(
    'title' => 'Past events',
    'operator' => '<',
    'value' => array(
      'value' => array(
        'value_choose_input_type' => 'relative',
        'value' => NULL,
        'default_date' => 'now',
      ),
      'min' => array(
      'min_choose_input_type' => 'relative',
      'min' => NULL,
      'default_date' => 'now',
    ),
    'max' => array(
    'max_choose_input_type' => 'relative',
    'max' => NULL,
    'default_to_date' => 'now',
  ),
  2 => array(
    'title' => 'Future events',
    'operator' => '>=',
    'value' => array(
      'value' => array(
        'value_choose_input_type' => 'relative',
        'value' => NULL,
        'default_date' => 'now',
      ),
      'min' => array(
      'min_choose_input_type' => 'relative',
      'min' => NULL,
      'default_date' => 'now',
    ),
    'max' => array(
    'max_choose_input_type' => 'relative',
    'max' => NULL,
    'default_to_date' => 'now',
  ),
)

I also don't see the input box for entering value either when using grouped exposed filter with a date field. There are workarounds listed here: https://drupal.org/node/1764902, but they dont apply to date module fields.

I haven't figured out a solution for the UI issue, but I do know it's caused by the #states setting on the textfields, set on lines 375 and 386 of date/date_views/includes/date_views_filter_handler_simple.inc The selector fails to handle the situation where there might be multiple selects with the same class name, which is the situation you have with grouped filters.

Actually even after temporarily modifying the module to make the fields appear, the default values are lost (or at least not loaded) when you go to edit the settings again.

I couldn't get the patches above to work for me. The attached patch fixes the handler. However, it doesn't fix the UI - I think that will have to be a combination of patches to both date and views (or a complete overhaul of the date filter UI). I configured my view by doing what I could through the UI and then exporting my view to code and manually fixing the configuration by hand.

Revised patch to handle the situation where you're using a content pane and have exposed the view configuration to the panel pane config, rather than displaying the exposed form on the page to the end user. In this situation $_GET and $_REQUEST both aren't set.

I can't speak to the issue in #27 since I have yet to use this functionality inside a panel, so this patch builds on #26. In particular this incorporates that code as well as adds a static variable which helps to target the javascript visibility of various elements. (As others have noted, you can manually toggle the visibility with a tool like Firebug or edit the views export and re-import, but many site builders aren't that sophisticated.)

I tried briefly to find another module that would maybe face this same problem but couldn't; I'm far from a views expert but it seems since views is handling the generation of the form so we don't exactly know the broader context inside this individual form construction function.

This isn't perfect as the UI breaks when you add another grouping value by Ajax, but you can just come back in and everything will be visible.

I found somehow the bug: It seems like that in
views_handler_filter_date.inc function value_form(...)
does not take care about grouped filters. It only takes the correct value[type] for a filter with no groups. I have a fix, but is quiet ugly. The reason is, that I don't know from where the function value_form() may get the information, for which group it has to take the value. So I created a new variable in $this to handover the current group id. The group id is set in the file views_handler_filter.inc in function function build_group_form(..).

I don't know how to upload the fix, the upload always hangs because of the spammer protection.

@bringevent - your approach sounds good... curious about your difficulties uploading, though. Are you able to upload patches on other tickets, not just this one? If you think there's a bug on d.o. I'm sure the site maintainers would like to hear about it.

@bradjones1
I'm still not able to upload the whole code because of the new spammer protection of the drupal side...
I sent you an e-mail. Hope you are able to upload this and let the core team know about it, and of course also the community. Thanks

next try...

in views_handler_filter.inc in function function build_group_form(..) after the foreach statement and before the call to
$this->value_form...

      $row = array();
      $groups[$item_id] = '';
      $this->operator_form($row, $form_state);
      // Force the operator form to be a select box. Some handlers uses
      // radios and they occupy a lot of space in a table row.

// FIX: we need to tell in the call below ( $this->value_form($row, $form_state) ), 
//      which $item_id we currently process. How about $this (?)
      $this->options['group_info']['group_current_item_id'] = $item_id;
// END FIX      
      $row['operator']['#type'] = 'select';
      $row['operator']['#title'] = '';
      $this->value_form($row, $form_state);

and in views_handler_filter_date.inc function value_form(...) after about line 23:

  /**
   * Add a type selector to the value form
   */
  function value_form(&$form, &$form_state) {
    if (empty($form_state['exposed'])) {
// FIX START
      $item_id = isset($this->options['group_info']['group_current_item_id']) ? $this->options['group_info']['group_current_item_id'] : -1;

      // reset variable in $this to ensure no wron use if there is not a grouped filter
     $this->options['group_info']['group_current_item_id'] = -1;
       
      if ( $item_id > 0)  {
        $default_value = $this->options['group_info']['group_items'][$item_id]['value']['type'];
      } else {
        $default_value = !empty($this->value['type']) ? $this->value['type'] : 'date';
      }
// FIX END
      
      $form['value']['type'] = array(
        '#type' => 'radios',
        '#title' => t('Value type'),
        '#options' => array(
          'date' => t('A date in any machine readable format. CCYY-MM-DD HH:MM:SS is preferred.'),
          'offset' => t('An offset from the current time such as "!example1" or "!example2"', array('!example1' => '+1 day', '!example2' => '-2 hours -30 minutes')),
        ),
// FIX START
      '#default_value' => $default_value,
// FIX END
      );
    }
    parent::value_form($form, $form_state);
  }

I have no idea how to report this bugfix idea to the core team: Please let them know about this bugfix. I'm sure, they have a better way to fix this for the next release.

@bringevent - Can you provide this as a patch?

As for the patch to views_handler_filter_date.inc, for Drupal 7 that's still contrib code. Not sure if they are handling those now similar to what they do for core patches, which is to provide a patch to the -dev version of Drupal (which would be Views in core D8) and then backport it. But regardless, they should be provided as patches so it's easier for other people to use them.

Let's actually do this, everybody - there are two issues here, related but distinct from a code standpoint. As some have noted, a working set of exposed grouped filters can be created manually and imported as part of a views object, using the patch to the get_filter_value function.

That patch is attached, with a tweak to the line that fetches $options. It's working for me on a group of filters that includes some simple filters (e.g., > and <) as well as some between's.

Let's split the UI piece off on to a different ticket, as it could be the solution there is a combination of implementing module functionality and Views itself. That's at #2177055: Exposed, grouped filter configuration is broken inside Views UI

IMHO, I don't see this is working with system date fields like 'created'. so not very sure, it would be date module. It is possible views.

@bradjones1 Thanks for the patch, unfortunately it's still only a starting point. It does not work when changing the identifier of the exposed, grouped filter (because it's stored in $this->options['group_info']['identifier'] instead of $this->options['expose']['identifier']). Also, default values are not correctly handled.

I don't have time to create a patch right now, but I'll post my adjusted get_filter_value function for now and try to get back to it and help with the issue if possible.

I don't think it handles multiple default values correctly yet, and I haven't tried if it works when the filter is just optional (mine is required).

  function get_filter_value($prefix, $input) {
    // All our date widgets provide datetime values but we use ISO in our SQL
    // for consistency between the way filters and arguments work (arguments
    // cannot contain spaces).
    if (empty($input)) {
      if (empty($this->options['exposed'])) {
        return str_replace(' ', 'T', $this->date_default_value($prefix));
      }
      elseif (empty($this->options['is_grouped'])) {
        // handle default value for exposed filter if it is not set
        if (isset($this->options['expose']['identifier']) && !isset($_REQUEST[$this->options['expose']['identifier']])) {
          return str_replace(' ', 'T', $this->date_default_value($prefix));
        }
      }
      else {
        // handle default value for grouped filter if it is not set
        if (isset($this->options['group_info']['identifier']) && !isset($_REQUEST[$this->options['group_info']['identifier']])) {
          $identifier = $this->options['group_info']['default_group'];
          $options = $this->options['group_info']['group_items'][$identifier]['value'][$prefix . '_group'];
          return str_replace(' ', 'T', $this->date_default_value($prefix, $options));
        }
        elseif ($this->options['is_grouped'] && isset($_REQUEST[$this->options['group_info']['identifier']])) {
          // determine correct filter value from group info
          $identifier = $_REQUEST[$this->options['group_info']['identifier']];
          $options = $this->options['group_info']['group_items'][$identifier]['value'][$prefix . '_group'];
          return str_replace(' ', 'T', $this->date_default_value($prefix, $options));
        }

      }
    }

    return str_replace(' ', 'T', $input);
  }

Patch in 34 combined with the workaround in 16 got me on my feet.

I have two options
1. end date > today
2. Not null (show all values)

Didn't work on the page or embedded in a quick tab until I applied the patch in 34 and then performed the steps in https://drupal.org/comment/6732320#comment-6732320.

Would you be able to provide any details as to this status change, bradjones1?

The feedback in #36 suggests my patch above doesn't work in all use cases.

I'm using the latest dev version and I added the patch in #34.

I have to turn off javascript in the browser in order to set the dates in the exposed/grouped filter. Here's a pic to show what I get if javascript is turned on.

After setting the grouped filter values, I get the following errors......

Notice: Undefined index: operator in date_views_filter_handler_simple->value_validate() (line 455 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: operator in date_views_filter_handler_simple->value_validate() (line 455 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: operator in date_views_filter_handler_simple->value_validate() (line 485 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: value in date_views_filter_handler_simple->value_validate() (line 503 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: min_group in date_views_filter_handler_simple->value_validate() (line 503 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: max_group in date_views_filter_handler_simple->value_validate() (line 503 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).

When using the filter, the default value is not respected. However, once I change the value and hit apply, it works as it is supposed to. When changing values in a Page view, I get the following errors....

Notice: Undefined index: value in date_views_filter_handler_simple->date_default_value() (line 84 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: value in date_views_filter_handler_simple->date_default_value() (line 84 of ..../sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).

The patch in #34 is working for me. My process was as follows:

1) create the first views exposed filter option via the UI, not grouped.
2) click the grouping option, add a name, and save immediately.
3) export the view.
4) manually edit the export to account for the other options (in my case, different date ranges)
5) apply the patch.
6) revert the view.

I have a straightforward use case where I'm not trying to change the identifier, or I think anything else mentioned in #36, but would be willing to reroll this patch with some changes if some could be specified.

patch works but im getting a "Notice: Undefined index: value in date_views_filter_handler_simple->date_default_value() (line 84 of xxx/date/date_views/includes/date_views_filter_handler_simple.inc)." warning

thank you

Tried #34 and #36 both, working but with warning below when "Use AJAX" is set to no.

warning with #34:
Warning: Illegal offset type in date_views_filter_handler_simple->get_filter_value() (line 109 of xxx\xxx\sites\all\modules\date\date_views\includes\date_views_filter_handler_simple.inc).

warning with #36:
Warning: Illegal offset type in date_views_filter_handler_simple->get_filter_value() (line 120 of xxx\xxx\sites\all\modules\date\date_views\includes\date_views_filter_handler_simple.inc).

Actually, i am using ajax in the view and when in the views page itself and using the filter, it works fine without warning, but the filter form is exposed in other pages also and the problem comes when i try to filter from other pages which is redirected to the views page with the filter parameters in the address bar like: mysite.com/myviewpage?field_something=All&field_datetosearch_value[1]=1

hope it makes sense..

any suggestions/help appreciated.

Thanks!

Re the previous comment. Was getting the exact same behaviour. Am running views in panels as a panel pane. Change Use "Panel path: to YES, and Use Ajax to YES and it all works fine now. Hope this helps.

Dears, I have tried all methods mentioned above for my drupal7, views 3 and date module, but nothing works so far... Are there any fresh ideas or custom modules to solve the issue? I just need to filter content by grouped filter options this week, this month, this year, so simple that is just stupid to stuck with it... I would really appreciate any help!!!

This patch fix the notice show when the default value is empty, but needs work yet

The patch works for me in a way that I can save some grouped filter values. How I did is by hackery. I used code inspector to show the relative value fields that are hidden and then I entered values. Problem with this is that they dissappear when you try to edit them and you have to renter everything. This is really heavily screwed part of date views :)

I guess views has to pass along the used ID so that date can built up its #states/#depedency properly.
Something like form_state['item_id'] of $form['#item_id'] could for example work. Any oppinion?

I modified the patch in #34 so that exposed grouped filter work on a date field if there are multiple options in the filter (e.g. Last 30 days, Last 6 months, Last 5 years & etc.) It also includes the fix for warnings in #47. I followed instructions in #42, and with my patch, I was able to make grouped exposed filter work with multiple option and '>=' condition.

Here's what my exported view (filter) looks like:

  /* Filter criterion: Field collection item: Date (field_date) */
  $handler->display->display_options['filters']['field_date_value']['id'] = 'field_date_value';
  $handler->display->display_options['filters']['field_date_value']['table'] = 'field_data_field_date';
  $handler->display->display_options['filters']['field_date_value']['field'] = 'field_date_value';
  $handler->display->display_options['filters']['field_date_value']['operator'] = '>=';
  $handler->display->display_options['filters']['field_date_value']['group'] = 1;
  $handler->display->display_options['filters']['field_date_value']['exposed'] = TRUE;
  $handler->display->display_options['filters']['field_date_value']['expose']['operator_id'] = 'field_date_value_op';
  $handler->display->display_options['filters']['field_date_value']['expose']['label'] = 'Date (field_date)';
  $handler->display->display_options['filters']['field_date_value']['expose']['operator'] = 'field_date_value_op';
  $handler->display->display_options['filters']['field_date_value']['expose']['identifier'] = 'field_date_value';
  $handler->display->display_options['filters']['field_date_value']['expose']['remember_roles'] = array(
    2 => '2',
    1 => 0,
    3 => 0,
    4 => 0,
    6 => 0,
    5 => 0,
  );
  $handler->display->display_options['filters']['field_date_value']['is_grouped'] = TRUE;
  $handler->display->display_options['filters']['field_date_value']['group_info']['label'] = 'Select a time period';
  $handler->display->display_options['filters']['field_date_value']['group_info']['identifier'] = 'groupdate';
  $handler->display->display_options['filters']['field_date_value']['group_info']['group_items'] = array(
    1 => array(
      'title' => 'Last 30 days',
      'operator' => '>=',
      'value' => array(
        'value_group' => array(
          'value_choose_input_type' => 'relative',
          'value' => 'now -30 days',
          'default_date' => 'now -30 days',
        ),
        'min_group' => array(
          'min_choose_input_type' => 'relative',
          'min' => NULL,
          'default_date' => 'now -30 days',
        ),
        'max_group' => array(
          'max_choose_input_type' => 'relative',
          'max' => NULL,
          'default_to_date' => 'now',
        ),
      ),
    ),
    2 => array(
      'title' => 'Last 6 months',
      'operator' => '>=',
      'value' => array(
        'value_group' => array(
          'value_choose_input_type' => 'relative',
          'value' => 'now -6 months',
          'default_date' => 'now -6 months',
        ),
        'min_group' => array(
          'min_choose_input_type' => 'relative',
          'min' => NULL,
          'default_date' => 'now -6 months',
        ),
        'max_group' => array(
          'max_choose_input_type' => 'relative',
          'max' => NULL,
          'default_to_date' => 'now',
        ),
      ),
    ),
    3 => array(
      'title' => 'Last year',
      'operator' => '>=',
      'value' => array(
        'value_group' => array(
          'value_choose_input_type' => 'relative',
          'value' => 'now -1 year',
          'default_date' => 'now -1 year',
        ),
        'min_group' => array(
          'min_choose_input_type' => 'relative',
          'min' => NULL,
          'default_date' => 'now -1 year',
        ),
        'max_group' => array(
          'max_choose_input_type' => 'relative',
          'max' => NULL,
          'default_to_date' => 'now',
        ),
      ),
    ),
  );
  $handler->display->display_options['filters']['field_date_value']['form_type'] = 'date_popup';
  $handler->display->display_options['filters']['field_date_value']['default_date'] = 'now -30 days';
  $handler->display->display_options['filters']['field_date_value']['year_range'] = '-10:+0';

The patch from #50 works for me, together with the method described in #42
So it is not clear, if this is an issue of Views or of Date?
Even with the patch, one can not call it really working, as one has to enter the dates manually into a feature file or export / re-import the view.

@vijaycs85 do you have an idea how to solve the problem?

The patch from #50 works for me too, except optional checkbox
http://screencast.com/t/rrXKeGEwKRrp
In my case when page loads one of exp filter options should work, but this does not happen because i think we don't have $_REQUEST param. And then when i switch to another option it works fine

The patch from #50 works for me :)

Hi,

First of all I wanted to say thank you to all contributors to both date module and views grouped filters feature. Great work.

Here's a patch that solved my problem. My use case is: grouped filter for dates using between operator and concrete dates (not relative). Date widgets are now shown, even if there are multiple groups. Values are correctly saved and filter is working as expected in preview mode.

Patch wasn't tested with single filter (not grouped). Same with relative date, but here, even without testing, I'm pretty sure it won't work so further development is required.

Hope it's a step in right direction. Cheers.

PS. Sorry for no interdiff.

The patch from #54works, thank

@blazey I did not see that this was not written for grouped filters and relative dates.

Just trying the patch in #54, and it does not resolve what I think is the issue. The description is unclear to me. But here are the steps I am taking:

1. I have a date field attached to a node.
2. I create a view, add a filter to the view for the date field, expose the filter, set the filter to be grouped.

The UI that is inserted in the date filter options modal contains a template multi-value list of label/operator/value options. I am able to enter information for the label, change the operator, and change value type (Select a date/Relative date), however, I do not get a field to enter a date for the actual value. Although I do get value fields when I use the "In between" operator, none of the others get a value field.

Correction, patch in #54 seems to work, but not for pre-existing filter groups. Only for new ones.

OK, so new items get the value fields, but I run into a number of other issues.

Submitting the field, generates a validation error, where it recreates any removed fields with warnings. "In Between" operations seem to have broken. Also, setting a default selection appears to do nothing.

I just tried the patch in #54. It mostly works for me, but when I define a default group it doesn't take it into account. I have made a small change and it's working for me

Are you using -dev to create the patch?
Some notes while applying #61

Hunk #5 FAILED at 349.
1 out of 9 hunks FAILED -- saving rejects to file date_views/includes/date_views_filter_handler_simple.inc.rej

You are right, this patch was made using the stable release. Sorry about that.

These are the interdiff and the patch using the 7.x-2.x branch.

Sorry for the double update, changing status.

I have tested #67 but the the field to enter the relative date are/is missing.
I could display them by playing with the "inspect element" feature of my browser and unset "display:none" for those missing field... (See the attached screencapture if I am not clear)

Anyway, after doing this, the filter are working as expected!

Thanks for the patch

+1 for previous. I think where is one line misplaced in code. Here are fixed patch and interdiff between#64 this one.

Thank you Skylord, patch#69 solves the visibility problem as explained in #68.
Unfortunately, If I have 2 filters in a group (see attached screencapt), and if I want to set "is less then" "today + 10 day" for the first filter and "less then" "today" for the second filter, I got the following problem:
After clicking "save", I got the same value "today + 10 day" for both filters...

I see... It's not because my patch. Options form default values wasn't set correctly. Try this one - works OK for me.

So good Skylord, your patch #71 solved everything.
I didn't meant that #69 was causing the problem in #70; sorry for the confusion.

@skylord the patch exposed_grouped_filter-1876168-71.patch is failing to apply

vagrant@prj:/var/www/web/sites/all/modules/date$ git apply -v /var/www/web/exposed_grouped_filter-1876168-71.patch
Checking patch sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc...
Hunk #1 succeeded at 59 (offset -2 lines).
Hunk #2 succeeded at 86 (offset -2 lines).
Hunk #3 succeeded at 110 (offset -2 lines).
Hunk #4 succeeded at 310 (offset -2 lines).
error: while searching for:
   * @return
   *   The form date part element for this instance.
   */
  function date_parts_form(&$form_state, $prefix, $source, $which, $operator_values, $identifier, $relative_id) {
    module_load_include('inc', 'date_api', 'date_api_elements');
    switch ($prefix) {
      case 'min':

error: patch failed: sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc:334
error: sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc: patch does not apply

Also, there is a strange line at the end of the patch: "Only in /usr/home/db.tinfocom.ru/public_html/sites/all/modules/contrib/date/date_views/includes: date_views_filter_handler_simple.inc.orig". Was that intended?

Thanks.

Patch exposed_grouped_filter-1876168-71.patch successfully applied after updating date module to Version: 7.x-2.9. My bad :D
Thank you very much @skylord!

The patch is not applying properly. We are using date 7.x-2.9

We placed the patch file into the date module folder

patch -p1 < /Users/XXX/Desktop/date/exposed_grouped_filter-1876168-71.patch

The error message is:
can't find file to patch at input line 4

Please provide directions. Thanks.

@NextGame Patches are made just for dev branches. Apply it to 7.x-2.x-dev.

Hello RCodina,

Thanks for your prompt response. We also applied the patch to the 7.x-2.x-dev version and received the same error message. Your help is greatly appreciated.

Thank You.

@NextGame Are you running the `patch` command from within in the date module's directory? It doesn't matter if the patch is in the date module folder or not, but if your command line is not in that directory, you'll need to `cd /Users/xxx/Desktop/date/` first.

@NextGame As it's said on comment #73, the patch is broken (sorry, I didn't remember that). So it needs to be rerolled. In the meantime, you could try to apply it manually.

@rcodina Poster of comment #73 rescinded theirself in comment #75. I currently have the patch in #71 applying successfully against Date 2.9 (via drush make). Based on @NextGame's error message it looks like a problem in running the patch command not a problem with the patch itself.

(edit: I also just tested this patch against 2.x-dev via drush make and it applied, so no reroll should be necessary at this time)

@marleythedog Ok, so lets change status.

Applied #71 against Date 2.9 and works

Three good reviews of #71 so far (by @DuneBL, @radone and @tobiberlin). We may change the issue to RTBTC status so it gets commit sooner than later.

#71 against latest dev did the trick for me. Thanks!

Thank you. It worked. Appreciated.

@NextGame If it works and many good reviews then RTBTC!!!

@NextGame Read this.

#71 seems to mostly fix my issues, but I am encountering the following buggy behavior:
- Stored relative dates are hidden in the Views interface when a new filter is added (see image). This carries through after the new one is stored but the view has not yet been saved. Once the view is saved or canceled, all relative dates appear normally.
- Filters are shown but cannot be applied in the Views preview but work outside of it.

Patch #71 works with Date 2.9

Thanks

#71 fixes the issue but still has a problem

Problem: Disappearing relative date field when removing item in combined filter

When adding a combined filter you're having 3 items standard, I only had need for 2 (upcoming/passed) and removed the third with the delete item link. This resulted in having the relative value field disappear from the 2nd item (see http://cl.ly/image/060m0J3h1y30 )

After saving the view and editing the filter the field is shown again

I ran into an issue with the patch in #71, when making an exposed grouped filter that is optional and defaults to "- Any -". When trying to save the filter settings, I got a series of PHP notices and an error:

Notice: Undefined index: All in date_default_value() (line 65 of sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: operator in value_validate() (line 486 of sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc). 
Notice: Undefined index: operator in value_validate() (line 516 of sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc). 
Notice: Undefined index: value in value_validate() (line 534 of sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: min_group in value_validate() (line 534 of sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Notice: Undefined index: max_group in value_validate() (line 534 of sites/all/modules/date/date_views/includes/date_views_filter_handler_simple.inc).
Fatal error: [] operator not supported for strings in includes/form.inc on line 3411 

The problem appears to be that the filter is trying to figure out the default value and operator for the "Any" value, when it should just be ignored. The attached patch returns nothing when an "Any" is passed; there may be more elegant solutions out there.

This patch also fixes the filter not working in the admin preview, as mentioned in #89.

I have not looked at the hidden field issue reported in #89 and #91.

The admin preview fix in #92 is not quite right. Corrected version of #92 attached.

Only thanks for the efforts ...

#93 fixed the Views preview issue for me. Thanks!

Unfortunately, #93 has turned out to be spotty. It's working in preview, but now the front end the filters are not working. Reverting back to #71 for now.

Reverting #68 IS removal, a bad IS is better than no IS.

I started off applying the patch from #71 this patch fixes the issue with the front end but it then breaks the preview (issue reversal) and as another user pointed out in #92 I got the same warnings about 'All'. Looking further into it the patch from #93 does not work as that one was tried too which results in view page still not working with grouped date filters.

The problem appears to lie within the following code that is breaking the view front end in patch from #92 and #93

   elseif ($this->options['is_grouped'] && isset($this->view->exposed_raw_input[$this->options['group_info']['identifier']]['value'])) {
   $identifier = $this->view->exposed_raw_input[$this->options['group_info']['identifier']];

So currently my best bet was to ignore that the view preview will be broken but apply patch #71 and cherry pick parts of #93 interdiff to remove the 'All' warnings. So that is the current state of this ticket, remains 'needs work.'

Cherry picked the following:

@@ -62,6 +62,9 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
     $default_date = '';
     if (empty($options)) {
       if ($this->options['is_grouped']) {
+        if ($this->options['group_info']['default_group'] = 'All') {
+          return '';
+        }

And

@@ -483,6 +486,10 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
 
     $options = &$form_state['values']['options'];
 
+    if (!isset($options['operator'])) {
+      return;
+    }

Looks like there are more issues here than previously mentioned. I was changing my view again today and found the following issue:

If you change a date grouped filter using radios optional single select TO
date grouped filter using a select drop down multi select optional it causes a WSOD

In short change your radio buttons to check boxes and this will cause the bug.

Error was:
Warning: Illegal offset type in date_views_filter_handler_simple->get_filter_value() (line 120 of /sites/all/modules/contrib/date/date_views/includes/date_views_filter_handler_simple.inc).

WSOD Fatal:
2015/11/11 14:18:19 [error] 15173#0: *180808 FastCGI sent in stderr: "PHP message: PHP Fatal error: Cannot create references to/from string offsets nor overloaded objects in /includes/common.inc on line 6726" while reading response header from upstream, client: 10., request: "GET /franchise-listing?field_kurs_value=&field_brand_value=&field_latest_year_value=1 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "10.", referrer: "/admin/structure/views/view/franchise/edit/page%3Ffield_kurs_value%3D%26field_brand_value%3D%26field_latest_year_value%3D1"

Further debugging information for those that are coding:

Problem that I was mentioning appears to be an issue with multi select and the following code:
$identifier = $_GET[$this->options['group_info']['identifier']];

When the identifier for this field is mapped back to the grouped options for changing the date filter this is where the problem is. The $identifier variable appears to be returned as an array in this case (multi select). So when the code that grabs the $options triggers it tries to look for an array index inside of $this->options['group_info']['group_items']

So the issue appears to be that grouped date filters also do not properly support multiple selections (checkbox in views with this title 'Allow multiple selections') with the new patches supplied in this ticket. This could very well be split into it's own ticket however it involves the code being changed in this ticket to make grouped date filters work.

I've just updated to lastest 7.x-2.10-beta1, then 7.x-2.x-dev today and Views 7.x-3.13.

Issue:
1. Relative Date input field not showing. (Could this be a jQuery update version issue?)
2. Input values not saving.

1. I still have the issue of the display:none being set on the Relative Date input field.
"form-item form-type-textfield form-item-options-group-info-group-items-1-value-value-group-default-date"

2. Even if I remove the display none, enter the values and save, the values don't change to the new values and the issue persists. The values that was there by default remains.

I have not applied a patch yet, as I hoped it may have been applied in dev branch.

I'm running #93 on on the latest dev with Views 7.x-3.13 and it's working.

There are still a few issues which I was able to overcome using Chrome's inspector to remove the "display:none;" from the date entry fields.

This isn't apparent on the initial load of the page, but appears when a new filter row is added. All of the "select a date" fields are hidden by jQuery. The fields are still there, and the values remain, but they are hidden.

For review

Enviroment

Views 7.x-3.13
Date 7.x-2.10-beta1 (current dev)

Fixes

1. Display:none fix
   Problem was in static counter, cause form rebuilds couple times per request and because of this States API work incorrectly
2. Default value for select box "Select a date" / "Enter a relative date"
3. Small fixes in date_default_value() and get_filter_value()

1. +++ b/date_views/includes/date_views_filter_handler_simple.inc
   @@ -83,7 +92,11 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
   +        $default_date = (empty($options[$prefix])) ? '' : $options[$prefix];
   

   Why you are wrapped empty() by ()?

2. +++ b/date_views/includes/date_views_filter_handler_simple.inc
   @@ -389,24 +407,39 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
   +      $relative_value_key = ($prefix == 'max' ? 'default_to_date' : 'default_date');
   

   Just 'max' === $prefix ? 'default_to_date' : 'default_date'.

3. +++ b/date_views/includes/date_views_filter_handler_simple.inc
   @@ -389,24 +407,39 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
   +      } else {
   

   Put else on a new line

The patch from #105 worked for me!

Update: Fixed the default value issue, but potentially caused other issues with filters.

1. +++ b/date_views/includes/date_views_filter_handler_simple.inc
   @@ -62,7 +63,7 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
   +        if ($this->options['group_info']['default_group'] == 'All') {
   

   Swap operands and you'll never have an issue like fixed one.

2. +++ b/date_views/includes/date_views_filter_handler_simple.inc
   @@ -79,10 +80,10 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
   +    // This is a relative date that needs to be constructed from options like 'now'.
   

   80 symbols per line for comments according to Drupal CS.

3. +++ b/date_views/includes/date_views_filter_handler_simple.inc
   @@ -315,18 +316,16 @@ class date_views_filter_handler_simple extends views_handler_filter_date {
   +      $form['value'] += $this->date_parts_form($form_state, 'min', $source, $which, $this->operator_values(2), $identifier, 'default_date', $this->element_number);
   

   Maybe smth like this?

   $value2 = $this->operator_values(2);
   
   foreach (array(
     'min' => 'default_date',
     'max' => 'default_to_date',
   ) as $type => $prop) {
     $form['value'] += $this->date_parts_form($form_state, 'max', $source, $which, $value2, $identifier, $prop, $this->element_number);
   }
   

   Save, at least, result of $this->operator_values(2) to variable.

#110 patch is working for me!

#110 patch works over here as well!
Tested with static & relative dates.
Code reviewed by 2 people (1 experienced), Tested by 3 (1 on slightly older version).
Issue > 3 years old on a Major Feature that just hasn't worked before.
Patch solves the problem.
No new bugs appear to be introduced.
No new UI elements added -- simply exposed.
This looks good to go!

#110 do what it should :) Lets commit and finish with this.

I'm curious, what was the purpose of swapping the operands?

Cause its ease find fatal error from (1 = $i) than small typo.

// Fatal error
if (1 = $i) {
 ...
}

I have tried to group all the patches/issues about this problem into one issue: https://www.drupal.org/node/2704699

This patch needs tests

I can also verify that with patch #110 is a really good one:

• UI doesn't brake any more, and relative fields are shown as expected within the grouped exposed filters
• Grouped exposed filters work as expected without any warnings (for instance about missing operator)
• Values are indeed saved

Date version: 7.x-2.9+6-dev

Wanted to say that I just had to apply and use patch #71, and it is working for me.

#110 broke non-grouped relative date filters. The attached patch tries to fix that also...

Patch looks good. I've first installed it a few weeks ago & used it a few times with no problems.
A cursory code review didn't turn up any issues -- although I'm not overly familiar with this module.
I think its a go!
+1

Needs tests

Patch is #120 is working well for me!

#120 is working as expected. (I discovered #110 broke relative dates for me on non-grouped filters as stated in #120.)

#120 working here too. Thank you!

120 worked for me too

#120 works great. I tested across a couple of scenarios and addresses my previous comments -- #89 & #95.

Annnd...unfortunately it has introduced another issue where relative dates do not work in filters that are not exposed. Rolling back.

@jay-dee-ess, please clarify.
Did it break something, or is it just not a complete fix?

A bit of both -- it fixed exposed filters, which worked across all scenarios for me. On the same site, however, I have a date filter which is not exposed. That unexposed filter was broken after I applied the patch.

This patch fixes a conditional that wouldn't allow unexposed relative date filters to save properly.

For me, this addition was necessary to make grouped exposed filters work outside of the Views preview. I really don't know why, if it was already working for everyone else.

#132 works great for me!

#132 is working for me as well.

#132 is working for me as well.

#132 works for me on exposed filters and doesn't break my un-exposed date filters (#130). Thanks!

#132 works for me too, I don't see any issue nor coding standards errors.
However patch still needs tests, but I don't think the date_views submodule has got tests at all.

May be we need maintainers guidelines in here, instead of guessing best approach?

#132 works great for most situations but unfortunately it breaks other displays if they override it i.e.

- create a view with a grouped exposed filter on a date field
- create a block display and change the filter for 'this block (override)' and apply

Result:

- the exposed filter values show the original (all displays) values when you try and change them again

- the SQL ends up with empty filter values i.e. DATE_FORMAT(FROM_UNIXTIME(field_data_field_date.field_date_value), '%Y-%m-%d') < ''

I'm seeing an odd behavior on #132 for un-exposed date filters that use the relative date of "now". It's measuring against the time of 00:00:00 in the query instead of the current time on the server. I tried reverting back to the latest dev version without the page and the relative date of "now" appears to work and adds in the appropriate server time into the query like 16:30.

It's not a huge problem if you don't mind that your events in the views are approximately right (within 24 hours of being right). I'm trying to get them exactly right of course though. ;)

Hi all,

I think I'm seeing the same problem: trying to expose a exposed grouped filter with a date, and the "value" field isn't showing up/sticking.

(this is using date views 7.x-2.10 and views 7.x-3.18).

I was just wondering:
a) what's the latest status? (is it use the patches in #132??)
b) is the fix going to be rolled into a release of views and/or dates (I'm not sure which module the bugs in from reading this)

and

c) ...can someone tell me how to apply those patches? (sorry - I'm new :)

thanks!

a) what's the latest status? (is it use the patches in #132??)

It seems the patch in #132 is still not perfect. It might solve the problem in your case, though, so feel free to try it out and report back.

b) is the fix going to be rolled into a release of views and/or dates (I'm not sure which module the bugs in from reading this)

Once we have a patch that fixes the problem completely (and doesn't cause other problems elsewhere), it will committed to the Date module and then be part of its next release.

c) ...can someone tell me how to apply those patches? (sorry - I'm new :)

See the Applying patches doc page. The patches are made to be applied from within the module directory.

...sweet - thanks for the info!

...I'll try #132 and let everyone know how it goes

thanks

FYI ...patch #132 solved the problems for me,

thanks!

Hi the patch #132 working good for views ui, and working good in general, please this patch is reviewed and working

If anyone is still struggling with this, until a patch is provided a solid work-around for me has been to use views_query_alter() in a custom module. First you would need to create the exposed grouped date filter (with blank dates since those don't work). Of course, this is not a long term solution, but at least it will work until we have a good patch.

You can check for the exposed input and alter the query based on it. Example:

  if ($view->name == 'open_invoices' && $view->current_display == 'page_1') {
    if ($view->exposed_raw_input['field_due_date_value'] == 1) {
      $sql_formatted_date = date("Y-m-d", strtotime('now'));

      $query->where[1]['conditions'][3]['field'] = 'DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') >= :field_data_field_due_date_field_due_date_value';
      $query->where[1]['conditions'][3]['operator'] = 'formula';
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value'] = $sql_formatted_date;
    }
    elseif ($view->exposed_raw_input['field_due_date_value'] == 2) {
      $sql_formatted_date = date("Y-m-d", strtotime('now - 30 days'));
      $sql_formatted_date1 = date("Y-m-d", strtotime('now'));

      $query->where[1]['conditions'][3]['field'] = 'DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') >= :field_data_field_due_date_field_due_date_value AND DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') <= :field_data_field_due_date_field_due_date_value1';
      $query->where[1]['conditions'][3]['operator'] = 'formula';
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value'] = $sql_formatted_date;
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value1'] = $sql_formatted_date1;
    }
    elseif ($view->exposed_raw_input['field_due_date_value'] == 3) {
      $sql_formatted_date = date("Y-m-d", strtotime('now - 60 days'));
      $sql_formatted_date1 = date("Y-m-d", strtotime('now - 31 days'));

      $query->where[1]['conditions'][3]['field'] = 'DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') >= :field_data_field_due_date_field_due_date_value AND DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') <= :field_data_field_due_date_field_due_date_value1';
      $query->where[1]['conditions'][3]['operator'] = 'formula';
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value'] = $sql_formatted_date;
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value1'] = $sql_formatted_date1;
    }
    elseif ($view->exposed_raw_input['field_due_date_value'] == 4) {
      $sql_formatted_date = date("Y-m-d", strtotime('now - 90 days'));
      $sql_formatted_date1 = date("Y-m-d", strtotime('now - 61 days'));

      $query->where[1]['conditions'][3]['field'] = 'DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') >= :field_data_field_due_date_field_due_date_value AND DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') <= :field_data_field_due_date_field_due_date_value1';
      $query->where[1]['conditions'][3]['operator'] = 'formula';
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value'] = $sql_formatted_date;
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value1'] = $sql_formatted_date1;
    }
    elseif ($view->exposed_raw_input['field_due_date_value'] == 5) {
      $sql_formatted_date = date("Y-m-d", strtotime('now - 90 days'));

      $query->where[1]['conditions'][3]['field'] = 'DATE_FORMAT(field_data_field_due_date.field_due_date_value, \'%Y-%m-%d\') < :field_data_field_due_date_field_due_date_value';
      $query->where[1]['conditions'][3]['operator'] = 'formula';
      $query->where[1]['conditions'][3]['value'][':field_data_field_due_date_field_due_date_value'] = $sql_formatted_date;
    }
  }

hope this helps.

Patch didn't applied in my case. So I rerolled (#132) it for 7-x-2.10. My fault, please ignore this patch. #132 is working fine.

patch #132 is working.

Another thumbs up for #132 - although I haven't conducted a full code review.

I'm not sure why this isn't RTBC - setting it as such now.

I'm not sure why this isn't RTBC

It's quite easy to see why if you read #138 and #139, whether or not this deems it not commit worthy is another matter.

#132 worked for me on Date 7.x-2.10. It solved the filtering by date for grouped filters with relative dates. Thanks!

Patch on #132 works for me too! Thanks!

Putting this back to Needs Work per #138, #139. Sorry folks.

I have checked out problems described on #138 on a new clean Drupal installation with latest versions of views and date with the patch on #132.

I found out that it's not a problem of overriding displays, it's just a problem on "block" type displays: once the patch is applied, date filters are just broken (both single and grouped). In this case, the view displays no results.

However, on "page" type displays they work fine (both single and grouped). Page displays override works fine too. Results are shown and filtered as expected.

#132 works for me, with:
Date 7.x-2.10+6-dev
Views 7.x-3.20
Views Exposed Form Fieldset

This patch was ok previously but needs to be rerolled for 7.x-2.x-dev

patching file date_views/includes/date_views_filter_handler_simple.inc
Hunk #1 FAILED at 9.
Hunk #2 succeeded at 78 (offset 17 lines).
Hunk #3 succeeded at 96 (offset 17 lines).
Hunk #4 succeeded at 109 (offset 17 lines).
Hunk #5 succeeded at 134 (offset 17 lines).
Hunk #6 succeeded at 153 (offset 20 lines).
Hunk #7 FAILED at 156.
Hunk #8 FAILED at 328.
Hunk #9 succeeded at 406 (offset 43 lines).
Hunk #10 succeeded at 431 (offset 44 lines).
Hunk #11 succeeded at 465 (offset 48 lines).
Hunk #12 succeeded at 509 (offset 48 lines).
Hunk #13 succeeded at 520 (offset 48 lines).
Hunk #14 succeeded at 544 with fuzz 1 (offset 46 lines).
Hunk #15 succeeded at 590 with fuzz 2 (offset 49 lines).
3 out of 15 hunks FAILED -- saving rejects to file date_views/includes/date_views_filter_handler_simple.inc.rej

#132 works for me with:
Date: 7.x-2.10
Views: 7.x-3.20

#132 patch works for me with:
Date 7.x-2.10+6-dev
Views 7.x-3.20

Still needs the work per #138, but here is the #132 patch re-rolled for the latest dev.

I found patch #161 working with 7.x-2.11-beta1+8-dev. Thank you.

Patch # 132 works:
Date 7.x-2.10
Views 7.x-3.23

Reroll for Date 7.x-2.11-beta3

Has this been resolved since creation of this bug?

My problem was with 3 filters: a group filter with radio-buttons, id filter, and the date-range. I found a work-around by deleting all filters and starting with the "radio-selection" filter because it had an option for "allow multiple selections." I re-created all other filters as normal and now the date-range works as indended.

I reverted the changed by deleting all filters and recreating the filters in the original order (date-range, fitler, group filter with radio-buttons) and it didn't work. So I changed the group filter to allow multiple and it still didn't work.

Perhaps this is coincidence, but order of operation is important here: I need to create a filter with allow multiple selection so that the SQL query doesn't cut the cheese.

Based off of #146 by akolahi, here's the code I used to achieve "Hide Future Events":

/**
 * Implement hook_views_query_alter().
 * 
 * Allow View Date Filter to work
 *   Source: https://www.drupal.org/project/date/issues/1876168#comment-12413395
 */
function MY_MODULE_views_query_alter(&$view, &$query) {
  if ($view->name == 'YOUR_VIEW_NAME') {// EDIT
    // switch ($view->current_display) {
    //   case 'page':

        // Manually Add a Date Filter
        $field = 'field_date'; // EDIT: The date field
        $filterKey = 'future_dates'; // EDIT: This is the Filter identifier
        
        if (isset($view->exposed_raw_input[$filterKey])) {
          if ($view->exposed_raw_input[$filterKey] === '1') {// This is the first option

            $sql_formatted_date = date("Y-m-d", strtotime('now + 7 days')); // Create a date
            $size = count($query->where[1]['conditions']);
  
            $datePlaceholder = ':field_data_'. $field . '_' . $field . '_custom';
            $query->where[1]['conditions'][$size]['field'] = 
              'DATE_FORMAT(field_data_' . $field . '.' . $field . '_value, \'%Y-%m-%d\') <= ' . $datePlaceholder; // Less than date
            $query->where[1]['conditions'][$size]['operator'] = 'formula';
            $query->where[1]['conditions'][$size]['value'][$datePlaceholder] = $sql_formatted_date;
            
  
          }
        }
        
    //   break;
    // }
    
  }

My date views filter:

• Exposed this filter to visitors > Grouped filters
• Optional: No, Remember: No, Allow multiple selections: No
• Widget Type: Select (Won't work with radios)
• Options
  1. Hide: Is empty (NULL)
  2. Show: Is not empty (NOT NULL)
• Administrative title: Custom Future Dates (Altered in MY_MODULE.module)
• Filter identifier: future_dates

I have a question for the patch #165. Why does this line exist?

$default_option = str_replace('now', 'today', $default_option);

With this I cannot filter with the relative date "now". It is only to understand it.

Anyway, it seems strange to me that currently version 7.x-3.11 has the same but without replacing the value:
https://git.drupalcode.org/project/date/-/blob/7.x-2.11/date_views/inclu...

Regards

Reroll for Date 7.x-2.11

Reroll for 2.12

Reroll for 7.x-2.13.