Date Exposed filter with offset not working as expected

In my opinion a flexible solution is to add another checkbox in order to allow the administrator to decide what to show: the computed dates or the offsets.

#2 I'm agree with you but in which case do we want a relative text string ?

I think, we must have a datepicker in filter date field (cf screenshot).

What do you think?

I also agree we should fix the date format. Right now the user has the screen showing words like "today" and "tomorrow" in my case instead of the expected dates.

John Cook, jQuery UI's datepicker works correctly even in this case though. Other datepickers (ex. Pikaday - if I recognize correctly from your screenshot) may fail though.

Here's a patch that changes behaviour of the date filter however by converting relative date values to dates on init.
I think it simplifies the date filter a lot and makes it usable with datepickers being the standard everywhere.

Also fixed coding standards issues in the file and added support for an empty min or max value for between filter.

I expect some core tests to fail unfortunately as this is a functional change. Here goes.

One more try..

After making sure FilterDateTest passes locally..

Overriding the query() method was not an option as datetime and datetime_range filters extend this class.

Nice. Including a patch for 8.9.x as well.

Tested patch #19 on 9.1.x and applied cleanly. Working correct for date filter with offset in views. Attaching screenshots below for reference.

I've spent some time poking this patch locally on a dummy Drupal 8.9 (i.e. patch #20) and wow, Marcin, that's pretty cool stuff :) I could do dates like $field BETWEEN '-10 days' AND '2021-01-01'.

I've tried a set of different operators, values, exposed/not-exposed. Everything has been a smooth flight except the grouped exposed filter. For some reason (I did not attempt to explore it on the code level), it would not accept any value - no matter if it's a YYYY-MM-DD or a relative string. (Attaching a screenshot where I captured the issue).

In general, I personally consider it a step forward for this filter :) It seems the code has become slightly simpler because we no longer maintain such explicit distinction between 'relative' vs 'absolute' date, which I deem a good sign :)

(based on the issue with the grouped filter, I am bumping the status into "needs work").

Thanks for your review Alex, there is a small thing with input validation ("between" and "not between" could accept one or 2 values), still not sure though how validation failed in your case where you provided exactly the amount.. What I'm getting for your set of grouped filters is: (attached screenshot).. If I'll fill the last label, validation passes.

Can you provide your view config?

I've tried #20 with a single date filter with the operator "is greater than or equal to". When using offset values like "+1 day" it appears in the form as the same offset value, not formatted into the corresponding date.

I've debugged this and I saw that it's using an array $component with the values ['min', 'max', 'value'], but with this filter there is no such thing as $form['value']['value']['#default_value'], but $form['value']['#default_value'] instead.

I tried adjusting the code to format $form['value']['#default_value'], but despite the default value was correctly formatted, it doesn't appear in the form. Setting $form['value']['#value'] = $form['value']['#default_value'] would do that. I'm not sure that would be the right thing to do though.

The patch no longer applies (even to 9.1.x) and needs a re-roll for 9.2.x.

IMO we should just fix the problem and leave the code style fixes for another patch. I'm all for fixing code style issues in core (I wrote the original coder module), but this is more likely to get committed if we just keep the changes to the fixes, and leave the code style comments for another issue.

A few problems / questions:

1. The preg_match() regex won't catch day offsets like +1 day, we need something better here. I couldn't find a PHP function that matches all of the valid relative date format. So we might just try strpbrk($form['value'][$component]['#default_value'], '/.,') !== FALSE
2. Can we assume Y-m-d? Won't we need to get the sites (or fields) date format?
3. We don't need to do isset() checks with empty(), as empty() covers this.
4. Why is defineOptions() removed?

Here's a straight re-roll for 9.1.x and 9.2.x.

And this has the problems that @juanolalla mentions above. It's altering the wrong elements (at least on 9.x).

Re-rolled for 9.2.x

Trying to apply the patch from #31 on D9.2.6 failed in the portion adjusting the tests. For some reason the order of parameters passed in the assertion swapped. Here is an adjusted version.

Updated the patch to last Drupal 9.4.x

Building on #34 to add a day to the max date if it does not specify an hour. See https://www.drupal.org/project/drupal/issues/2842409 for another approach that is incompatible with the approach taken by #34.

Verified and tested patch#38. Patch applied successfully on 9.5.x-dev.

Test Steps:
1. Goto /admin/structure/views/view/content
2. Click 'Add' for 'Filter criteria' > Select date field
3. Check 'Expose this filter to visitors, to allow them to change it' option
4. Select 'in between' operator and option 'offset' for date
5. Goto Content overview page > verify date/time is not displayed as relative string, should be displayed in date format.

Test Result:
When using a date/time filed as exposed filter using the "offset from the current time" setting, the filter is displayed in date format, and not relative string

Before Patch:

After Patch:

RTBC +1

Thank you, @sonam.chaturvedi !

+++ b/core/modules/views/src/Plugin/views/filter/Date.php
@@ -13,37 +13,52 @@
-    $options['value']['contains']['type']['default'] = 'date';

Removing this means that all view config entities that use this setting need to be updated in a post-update function.

We also don't have a test that asserts the bug.

After I apply this patch I was confused because I lost the date/offset option, and that isn't explained in the proposed resolution so I'm adding the "Needs issue summary update" tag.

Warning: Undefined array key "max" in Drupal\views\Plugin\views\filter\Date->opBetween() (line 198 of /app/web/core/modules/views/src/Plugin/views/filter/Date.php)
I'm getting this warning associated with the patch, which then leads to this database exception and a WSOD:
Drupal\Core\Database\DatabaseExceptionWrapper: Exception

I applied my changes to #38 to fix the warning.

I finally created this https://www.drupal.org/project/date_filter to address this issue and many other.
Looks like issues like this have a very small chance to get enough attention and find their way into core so we have to handle that in contrib :(

Building on #44. Adding similar improvement as #38 but to the datetime filter in core datetime module.

Try fixing CCF.

Was previously tagged for tests and issue summary update which still need to happen plese.

Also please include interdiffs with patches.

Exactly same as #47, just re-rolled for 10.1.x

Hello,

I tried to apply patch on comment #50, but it's thrown an error in datetime module :

Warning: Undefined array key "type" in Drupal\datetime\Plugin\views\filter\Date->getOffset() (line 180 of core/modules/datetime/src/Plugin/views/filter/Date.php).

Without this warning, the patch works perfectly on Drupal 10.2.2!

Starting with #38, the patch always adds +1 day to any max value that does not explicitly contain a time.
While I understand the reason to do this on date values, I don't think it always makes sense on offset values.
For example "now" will become "now +1 day" (so tomorrow at the same time). But if I want my view to return results between some date and now, it will be confusing if it starts returning results from tomorrow.

Just a re-roll of #50 for 10.3.2

Hopefully, we need to address #51 and #52.

conflicts with #2842409: Date filter selecting the same day in between filter returns no results

Added new version of the patch against 10.3.2 where it adds support also for missing max value.

Patch based on 2982968-core-views-improve-date-filter-56.patch.
Just quick fix to make sure there are no warnings, otherwise AJAX reset button won't work, as it is throwing these annoying warning. :)

The OP is confusing to me on several accounts
- the expected outcome is in +/- 3 days, but the actual results are in years
- the printscreen shows that 'An offset [...]' is selected, instead of 'A date [...]'.

I my test, when selecting
- 'An offset [...]', I need to set '-7 days', to '+1 day'
- 'A date [...]', I need to set '20241231' to '20250303'
IMO that is OK. I can imagine a view with changes in the last week (using offset).

Of course the widget is very basic/not acceptable for ordinary users.

So, this issue still 'Needs issue summary update'

Below is the patch, in drupal 11

Hello @niranjan_panem,

You're patch for Drupal 11 is incorrect. There are comments conflict into your patch:

+<<<<<<< Updated upstream
     // This is safe because we are manually scrubbing the values. It is
     // necessary to do it this way because $a and $b are formulas when using an
     // offset.
+=======
+
+    /*
+    This is safe because we are manually scrubbing the values.
+    It is necessary to do it this way because $a and $b are formulas when using an offset.
+     */
+>>>>>>> Stashed changes

Issue comment patches have been phased out, and the work flow now is to create an issue fork, and then add a GitLab MR instead. I created a branch "2982968-date-exposed-filter" for this.