FieldItemBase category cannot be translatable

I think this actually requires a .yml change like the error indicates rather as a change to the FieldType.

Been digging a bit in how core does this and I see no difference in the definition.

Here is a similar issue for a different contrib module: https://www.drupal.org/project/geolocation/issues/3449270 🐛 AssertionError: "Spatial fields" must be defined in MODULE_NAME.field_type_categories.yml Fixed

Please change it is very urgent on drupal 11
change annotation Plugin/Field/FieldType/TimeRangeType.php

 * @FieldType(
 *   category= @Translation("General"),
 *   id = "time_range",
 *   label = @Translation("Time Range"),
 *   description = @Translation("Time range field"),
 *   default_widget = "time_range_widget",
 *   default_formatter = "time_range_formatter"
 * )

to php attributes

#[FieldType(
  id: "time_range",
  label: new TranslatableMarkup("Time Range"),
  description: [
    new TranslatableMarkup("Time range field"),
  ],
  category: "date_time",
  default_widget: "time_range_widget",
  default_formatter: "time_range_formatter",
)]

and Plugin/Field/FieldType/TimeType.php

@FieldType(
 *   category= @Translation("General"),
 *   id = "time",
 *   label = @Translation("Time"),
 *   description = @Translation("Time field"),
 *   default_widget = "time_widget",
 *   default_formatter = "time_formatter",
 *   list_class = "\Drupal\time_field\Plugin\Field\FieldType\TimeFieldItemList"
 * )

to php attributes

#[FieldType(
  id: "time",
  label: new TranslatableMarkup("Time"),
  description: [
    new TranslatableMarkup("Time field"),
  ],
  category: "date_time",
  default_widget: "time_widget",
  default_formatter: "time_formatter",
  list_class: TimeFieldItemList::class,
)]

Thank you!

The patch in #6 solved the error.

It is indeed critical as it breaks the add field UI in Drupal 11.

Needs an issue fork.

Is this backwards compatible? As the current release supports 8.8 9 10 and 11

I think only 10.2+ since it uses php attributes.
https://www.drupal.org/docs/drupal-apis/plugin-api/attribute-based-plugins →

I guess it's ok to drop 8.8 and 9 support as they are both EOL. Plus a bump to 10.2 is also ok I guess.

The patch in #6 adds `list_class: TimeFieldItemList::class,` which doesn't exists in the current codebase. While it fixes the initial issue it introduces a new bug.

I'm attaching the patch from the merge request that only updates the existing annotations.

Just wanted to mention the change records → for the cause of this issue. It explains a way to add backward compatibility in "BC layer" section, but switching to attributes will break it anyway.

I applied the MR19 on time_field 2.1.3 on Drupal 11.1.4 and the error is fixed.

Patch #12 confirmed working on stable version 2.1.3 / Drupal 11.1.5

Tested environment:
- Drupal 11.1.5 (Composer-based install)
- PHP 8.3 (via DDEV)
- MariaDB 10.11
- cweagans/composer-patches ^1.7.3

This was tested on a virgin, new install of Drupal without any other modules. I initially tried patch #6, which updates the plugin definitions to use PHP 8 attributes (e.g., #[FieldType(...)]). That patch introduces a reference to a TimeFieldItemList class:

list_class: TimeFieldItemList::class

However, that class is missing from the module, which caused a fatal error when attempting to add a Time field:

Error: Class "Drupal\time_field\Plugin\Field\FieldType\TimeFieldItemList" not found

I then applied patch #12, which only changes the category value in the annotation from:

@FieldType(
  category = @Translation("General"),

to:

@FieldType(
  category = "general",

This patch applied cleanly and resolved the following error when adding a Time field:

AssertionError: "General" must be defined in MODULE_NAME.field_type_categories.yml

After applying patch #12, I was able to:
- Add a Time field to the default Article and Basic Page content types
- Create and save nodes using the field
- Rebuild caches with no errors

Note: This issue affects the current stable release, 2.1.3, which is listed as Drupal 11-compatible on the project page. That version fails on Drupal 11 unless patch #12 is applied. Recommending the patch be committed and/or the compatibility info updated.

Thanks to everyone involved — this patch works well.