Update to 1.34.1 is breaking views filters with relative dates

[Wylbur]

Description of the bug

A short description of what the problem is.

After installing 1.34.1 over 1.34.0, views blocks with sort filters with relative dates are no longer working.

Steps To Reproduce

To reproduce the behavior:

1. Create a view with content that has a date field, and filter that view with a relative date filter.
2. After the update to 1.34.1, the relative filter does not work.
3. Views will show all values, without applying the date filter.
4. Revert to 1.34.0, and all views filters work as expected.

Actual behavior

This is breaking views with relative filters on at least a couple of my sites. These are not complex sites, I am just showing different pages for past a upcoming events.

This is a critical bug because it is breaking the function of my website.

Additional information

Add any other information that could help, such as:
Backdrop CMS: 1.34.0
Installation profile: standard
PHP version: 8.3.31
Drupal 7 compatibility: on
Database server: 11.4.12-MariaDB
Web server: LiteSpeed
jQuery version: 1.12.4
jQuery UI version: 1.14.1
CKEditor 5 version: 48.0.0 Used in formats: Filtered HTML, Full HTML

[indigoxela]

views blocks with sort filters with relative dates are no longer working.

I'm having trouble to reproduce or even understand. (What is a "sort filter"?)

I tried with a filter with a relative date and that works fine. (see below)

Example: a node listing with a filter " Is greater than or equal to" - "last week" (relative) shows only the nodes with post dates that fit. ... On a page view.

Could we get a little more info about the steps to reproduce @Wylbur ?

[indigoxela]

Never mind, found a way to reproduce it with date fields. However, unlike your report, the view is showing no nodes, not all, as long as I'm using "greater than or equal".

[indigoxela]

OK, here's what happens: for the default (not exposed) filter value the original string is handed over to the database query. Instead of an actual date string we end up with "today" or the like.

That query won't ever work as expected, of course:

WHERE (( .......(DATE_FORMAT(ADDTIME(FROM_UNIXTIME(field_data_field_date.field_date_value), SEC_TO_TIME(7200)), '%Y-%m-%d') >= 'today') ))

^^ At that point it should have been converted to an actual date string, the literal string "today" is pointless there.

This has been introduced by #6976.

I'm curious if we could fix that in function date_default_value(), which did return a proper date string before #6976. Without breaking grouped filters or anything else.

Otherwise I'd suggest to revert the code. What do you think @juanolalla?

Anyway, here's a PR to fix the immediate problem: backdrop/backdrop#5282 EDIT, nope, let's revert the filter change as a whole.

Obviously we don't have proper functional tests for that, so it needs a lot of manual testing of different situations.

[indigoxela]

Having a closer look at the grouped filter functionality: it's broken - even if it didn't break default filters, I recommend to revert that change as a whole.
Example: date input as array or string ends up with wrong date values - the filter appears to work, but doesn't. For sure not with fixed date input (other than today's date).

But as it does break existing functionality, we should revert it immediately.

[argiepiano]

Given this serious regression, I think reverting the whole commit might be best. Perhaps @juanolalla (who authored the PR) can take a look at the problems reported here, and continue working on the fix?