Not Works with "DateTime Timestamp with schedular widget", provided by module https://www.drupal.org/project/scheduler, also not works with some other widget also.

Or we could rather provide a widget types exclusion list to disable the module for those incompatible widgets?

I like the way the module tries to apply to all descendants of DateTimeWidgetBase so I think we should keep this behavior.

But I can understand that seeing the module's settings in those incompatible widgets is a bit annoying.

Can't think of any miracle solution though...

Not tested, but ChatGPT seems to say that we can rather easily identify all the widgets inheriting from a specific base class:

namespace Drupal\my_module;

use Drupal\Core\Field\WidgetPluginManagerInterface;
use ReflectionClass;

class WidgetListingService {
  protected $widgetManager;

  public function __construct(WidgetPluginManagerInterface $widgetManager) {
    $this->widgetManager = $widgetManager;
  }

  public function getWidgetsByBaseClass(string $base_class): array {
    $widgets = [];

    // Get all widget definitions.
    $definitions = $this->widgetManager->getDefinitions();

    // Iterate through each widget and check if it inherits from the base class.
    foreach ($definitions as $id => $definition) {
      $class = $definition['class'];
      if (is_subclass_of($class, $base_class)) {
        $widgets[$id] = $definition;
      }
    }

    return $widgets;
  }
}

May be we could use this code to build a settings form allowing to chose on which widgets we want to activate our module...

Settings form could look like this:

If you ask me, we got these options:
- 1) magically recognizing compatible widgets
- 2) adding UI or developer settings
- 3) adding a whitelist of allowed widgets
- 4) adding a blacklist of disallowed widgets

Noone knows if 1 is possible or worth the effort. 2 is useless complexity. So it's 3 or 4.

Checking fieldType seems like the wrong thing though, a check on widgetType is needed.

So i'm proposing: Factor out sth like

function _datetimehideseconds_widget_applies(WidgetInterface $widget): bool {
  return $widget instanceof DateTimeWidgetBase && !(
    // Blacklist of widget classes not playing well with this module.
    $widget instanceof FooWidget
    || $widget instanceof BarWidget
  );
}

And every time s.o complains, add another class to the exclusion list.

I have pushed the code for option 2 just in case.

Seems to be working fine though.

@mably: >200 lines of code where 5 are enough. Plus added complexity. A good developer does not burden himself and others with that...

@geek-merlin created a new MR without the settings form and the service. What do you think?

There's a particular Field Widget that is not intsanceof DateTimeWidgetBase and shoudl also benefit from this extension: TimestampDatetimeWidget, especially used for the "Authored on" (created) base field.

/**
 * Plugin implementation of the 'datetime timestamp' widget.
 */
#[FieldWidget(
  id: 'datetime_timestamp',
  label: new TranslatableMarkup('Datetime Timestamp'),
  field_types: [
    'timestamp',
    'created',
  ],
)]
class TimestampDatetimeWidget extends WidgetBase {

I have tried to add this to the whitelist and it works perfectly out of the box, as the widget renders almost equally as other Date widgets. I propose to update the MR with this addition.