Datepicker doesn't register relative dates

I too ran into this issue. Tried various things to get DatePickers.php to show the initial date that was set in the filter, but no luck. What I ended up doing instead was to set the exposed date filter to a static value but actually left it blank - your mention that the picker does work without an offset date gave me this idea. Then I added a form alter to set the initial date and voila! Note it's important to have the view value initially empty so you can test for it on first load.

function recurring_date_formatter_form_views_exposed_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // Set the default value for the date filter to the current date +2 days.
  if ($form['#id'] == 'views-exposed-form-event-promotion-page' ||
      $form['#id'] == 'views-exposed-form-event-promotion-page-1') {
    $default_date = new \DateTime('+2 days');

    // Set the default value only if the exposed filter is empty.
    $user_input = $form_state->getUserInput();
    $filter_value = $form_state->getUserInput()['field_dates_value'];

    if (empty($filter_value)) {
      $user_input['field_dates_value'] = $default_date->format('Y-m-d');
      $form_state->setUserInput($user_input);
    }
  }
}

If/when I get a chance, I think the solution for DatePickers.php might lie in the $user_input = $form_state->getUserInput(); pulling from $form_state.

Hey, @jcl324 - that works. Very clever! Now we just need to figure out what's going on... Thanks!

I suppose it would also work to check for empty() if it is equal == to the default value. The setUserInput() seemed to be the key here.

Any potential solutions would be welcome

Can someone try this?

@smustgrave thanks for posting an MR.

I've tried it out on with BEF 7.0.5 and it's working great on initial load, however after changing the filter it shows the default again after load – changed value is applied though.

E.g. if I set the date to "today" on 10/02/2025, it correctly loads filtered from 10/02/2025 initially, however if I then change the filter to 01/01/2025 in the exposed form, it reloads the view from 01/01/2025 , but 10/02/2025 in the widget.

Applied the MR on a 7.0.2 and a 7.0.5 with a 'now' value and '>' operator on a single date field.

Before patching:
On initial load, widget is empty and the offset condition is not applied on the view's results.
If I change the date and submit the form, it's all good:
the widget displays the date I picked and results are correctly filtered.

After patching:
On initial load, widget diplays the good date (today) but it's not applied on the view's results (I've got results from few days ago).
If I change the date and submit the form, I've got the same behavior than @agileware #9:
view's results are correctly filtered starting by the date I picked (tomorrow) but the widget displays the wrong date (today)

Seems good for me now (only tried with a single field though).
Review needed especially with a min/max exposed filter.

Hi!

I tested the patch on Drupal 10.4 & better_exposed_filters ^7.0

It works on an single exposed filter (equal, less or greater)

It doesn't work on a exposed filter “between” (min - max)

I don't know why and if we have to open a new issue for that or not but when we set the field to use a "between" operator with min/max default values,
$form_state->getUserInput() doesn't have values for this field on initial load (whereas it does after the form submission, and it also does if we set the field to use a '>', '<', '=' operator with single default value)

Seems good with single default value (equal / less / greater) and between min/max default values.

Needs review with and without default values on each those use cases.

Gotta also write tests.

Tests are now fine with equal / less / greater and between operators on initial load.

It might be nice to also add tests checking that everything is ok after a form submission with updated values.