Contrib.social

Logic to decide if a field category is a category ID or not is brittle

Open on Drupal.org →
Created on 3 July 2023, almost 2 years ago
Updated 31 August 2023, over 1 year ago

Problem/Motivation

In ✨ Make field selection less overwhelming by introducing groups Fixed we added field UI category information via a hook.

When looping over field types, to identify which fields have a category that is backed with 'info' and which are just a regular translation, we're using this check in FieldStorageAddForm

$display_as_group = is_string($val['category']) && $val['category'] !== FieldTypePluginManager::DEFAULT_CATEGORY;

This relies on the author of the field type using @Translation for their category. If they don't core will assume the category is the ID of a return from the info hook.

After this point we don't make sure the value exists - eg on this line we assume that category info has a key for this value.

$option_info = $display_as_group ? $category_info[$val['category']] : $val;

And from that point we use $option_info as though it exists

Steps to reproduce

Define a field type with a category in the annotation. Forget to wrap the category in @Translation
This will result in an error/

Proposed resolution

Don't overload the category annotation property on field types.
Add a new property instead, e.g. categoryId or something explicit so modules can't accidentally opt-in to the new groups

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Closed: works as designed

Version

11.0 🔥

Component
Field UI  →

Last updated 9 days ago

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024