Problem/Motivation

  1. Install Drupal with datetime module disabled or disable it manually.
  2. Go to admin/structure/types/manage/article/fields/add-field, select Timestamp as type of field, name it and click on Save and continue

Result: There was a problem creating field Test: The "datetime_default" plugin does not exist..

  1. Got to admin/structure/types/manage/article/fields and see that field has been created.
  2. Click on Edit.

Result: The website encountered an unexpected error. Please try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "datetime_default" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of /private/var/www/drupal/drupal8/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Proposed resolution

The problem appears since \Drupal\Core\Field\Plugin\Field\FieldType\TimestampItem declares the datetime_default as value for default_widget, but the datetime_default is part of datetime module and become unavailable when module will be disabled.

The same value for default_widget exists in the following classes:

  1. \Drupal\Core\Field\Plugin\Field\FieldType\TimestampItem
  2. \Drupal\Core\Field\Plugin\Field\FieldType\CreatedItem
  3. \Drupal\Core\Field\Plugin\Field\FieldType\ChangedItem

I'm seeing two resolutions here:

  1. Make default widget available within core (preferable).
  2. Forbid to disable the module (strange workaround).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BR0kEN created an issue. See original summary.

boaloysius’s picture

Here is the screenshot.

Ujwala_D’s picture

Assigned: Unassigned » Ujwala_D
boaloysius’s picture

Ujwala_D’s picture

Assigned: Ujwala_D » Unassigned
boaloysius’s picture

BR0kEN’s picture

Issue tags: +DevDaysSeville
BR0kEN’s picture

Assigned: Unassigned » BR0kEN
Wim Leers’s picture

Component: field system » datetime.module

Great find!

I suspect core.entity_view_display.ENTITY_TYPE.BUNDLE.VIEW_MODE>yml is missing a config dependency.

mpdonadio’s picture

Status: Active » Postponed (maintainer needs more info)

Can you confirm what version of Drupal this is happening in? This should have been fixed in #2802663: Exceptions due ChangedItem, CreatedItem, and TimestampItem implicit dependencies on datetime module, which is in 8.3.x and 8.4.x, and I just visually verified the annotations on TimestampItem, ChangedItem, and CreatedItem that they have "datetime_timestamp" as the widget.

/**
 * Defines the 'timestamp' entity field type.
 *
 * @FieldType(
 *   id = "timestamp",
 *   label = @Translation("Timestamp"),
 *   description = @Translation("An entity field containing a UNIX timestamp value."),
 *   default_widget = "datetime_timestamp",
 *   default_formatter = "timestamp",
 *   constraints = {
 *     "ComplexData" = {
 *       "value" = {
 *         "Range" = {
 *           "min" = "-2147483648",
 *           "max" = "2147483648",
 *         }
 *       }
 *     }
 *   }
 * )
 * )
 */

/**
 * Defines the 'changed' entity field type.
 *
 * Based on a field of this type, entity types can easily implement the
 * EntityChangedInterface.
 *
 * @FieldType(
 *   id = "changed",
 *   label = @Translation("Last changed"),
 *   description = @Translation("An entity field containing a UNIX timestamp of when the entity has been last updated."),
 *   no_ui = TRUE,
 *   default_widget = "datetime_timestamp",
 *   default_formatter = "timestamp",
 *   list_class = "\Drupal\Core\Field\ChangedFieldItemList"
 * )
 *
 * @see \Drupal\Core\Entity\EntityChangedInterface
 */

/**
 * Defines the 'created' entity field type.
 *
 * @FieldType(
 *   id = "created",
 *   label = @Translation("Created"),
 *   description = @Translation("An entity field containing a UNIX timestamp of when the entity has been created."),
 *   no_ui = TRUE,
 *   default_widget = "datetime_timestamp",
 *   default_formatter = "timestamp"
 * )
 */
Wim Leers’s picture

BR0kEN’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)
FileSize
808.83 KB

I've reported this at February 19, when the problem still been existent. But now it's not, because @xjm changed this in referenced issue at March 4.