Doesn't work for created / updated base fields

Hi, you did something wrong, it supports timestamp fields as well.

Thanks @Graber for the super fast reply. I can't find what I'm doing wrong, can you see a mistake in these screenshots?
Code looks like it should be plug and play... sorry for my stupid question.

The input is just a regular input.

It looks like the module is not enabled at all, as it adds an additional selector that allows you to chose if you'll have a date only or date and time.

Thanks @Graber. It's definitely enabled, I double-checked that. Your screenshot was very helpful, now I now what it should look like, I'll debug it in code.

Drupal core is 10.1.0

Super strange @Graber, I tried some real date fields and it works as expected, but for Node Created base fields the init() functions are never called at all. It looks like these base fields are simply neither of type date nor of type datetime.

I also ensured the class overrides are applied correctly:

/**
 * Implements hook_views_plugins_filter_alter().
 */
function date_filter_views_plugins_filter_alter(array &$plugins): void {
  dsm($plugins);
  // Use the module filter class for both date and datetime filters.
  if (\array_key_exists('date', $plugins)) {
    $plugins['date']['class'] = DateTimestamp::class;
  }
  if (\array_key_exists('datetime', $plugins)) {
    $plugins['datetime']['class'] = DateTime::class;
  }
  dsm($plugins);
}

The second dsm() clearly shows, they are overwritten as expected!

As it works for regular fields shows, that the module is installed and working. But not for created and updated (in my case). In your screenshot it works...

Perhaps it clashes with another module? But I can't see any candidates that would make sense to me...

Any ideas?

Thank you very much for your help.

Something may overwrite it in another implementation that is invoked after the module hook. You need to debug, it’s project-specific.
I’ll update my D10 to latest next week just in case but don’t expect to reproduce on a clean instance really.

Thanks for your help @Graber - yes that's totally possible. Crazy thing... I'll eventually just use BEF, as it works (but with jquery datepicker ... -.-) but not much time for further debugging left in the project.

Just wanted to find out, if others run into the same issue or if it's even by design.

So if it works for you with Drupal 10, feel free to close this afterwards.
Should I run into this again and have the time, I'll have a deeper look.

Ok, confirmed this works with latest core dev (10.1.x-dev 85c0412 at the time of writing this). Also, automated tests pass so..
Let's see if anyone will have the same issue.

@larowlan had the perfect idea to find the conflict in 📌 Add a static class for Smart Date, other contrib compatibility Fixed :

drush php-eval "var_export(\Drupal::service('plugin.manager.views.filter')->getDefinition('date'))";
which returns

array (
  'plugin_type' => 'filter',
  'id' => 'date',
  'class' => 'Drupal\\smart_date\\Plugin\\views\\filter\\Date',
  'provider' => 'smart_date',
)

See https://www.drupal.org/project/date_popup/issues/3368945#comment-15124153 📌 Add a static class for Smart Date, other contrib compatibility Fixed

So it's a smart_date conflict, but smart_date is quite common, so I think it would be worth to find a solution. Unclear what smart_date does here, as it at least doesn't seem to alter / improve the date output.

How should we proceed?

@Graber: I now created an issue over at smart_date but don't think there's a good technical solution to solve this. Same situation for date_popup: ✨ Integrate with date_popup Fixed

So from my perspective, the best fix would be to integrate the functionality from both modules into smart_date or core so that users don't run into this.

Until this is fixed, I'd suggest putting a warning on the module page, linking this issue and the smart_date issue and informing users about incompatibilities.

Smart date does too many things. I always refrain from installing a module if it does 10 things of which I need just one. The plan is to get this to core.

Probably the simplest solution would be implementing hook_module_implements_alter and make date_filter override last, but what if smart_date does the same? 😉

Thanks for the suggestion. This is working for me so far.

/**
 * Implements hook_module_implements_alter().
 */
function my_module_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'views_plugins_filter_alter') {
    // Check if the 'date_filter' module is implemented and remove it from the list.
    if (isset($implementations['date_filter'])) {
      unset($implementations['date_filter']);
      // Re-add 'date_filter' to the end of the list, making it run last.
      $implementations['date_filter'] = FALSE;
    }
  }
}

Using Drupal 10.2. Also had problems with created/changed date and smart_date module. #15 fixed the issue.

Using Drupal 10.2. Also had problems with a date field in the node and had smart_date module installed. #15 fixed the issue.
Thanks!