Refactor Label Help to use hook_field_widget_WIDGET_TYPE_form_alter

Created on 23 December 2024, 5 months ago

Problem/Motivation

Currently we're using a Form API #process callback with a long, confusing function and Array-of-doom logic to match certain edge cases dealing with different Drupal field types. This makes the module hard to read, hard to contribute, and hard to review and test.

Proposed resolution

Rearchitect and refactor the module to utilize a series of hook_field_widget_WIDGET_TYPE_form_alter() functions, one for each field widget type (i.e. field formatter) we intend to support. Widget types—not field types—are the things that have the most intimate knowledge of each field's internal render array oddities and structure.

This would break the one single long function into separate smaller functions. Within each widget type, there might still be a need for some case logic, but the vast majority of the current if/else control structures would be simply obviated by implementing adequate [WIDGET_TYPE] functions.

Remaining tasks

Work on a quick and dirty proof of concept, based around a few widget types.
Once the approach is shown to work, prove out the rest of the core widget types.
Revisit contrib module integrations, such as Paragraphs Add Label Help support for Paragraphs module fields Active .

User interface changes

None.

API changes

None.

Data model changes

None.

📌 Task
Status

Active

Version

2.0

Component

Code

Created by

🇪🇨Ecuador jwilson3

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

Merge Requests

Comments & Activities

  • Issue created by @jwilson3
  • I have tried to solve the issue and created the patch please review it and let me know

  • 🇪🇨Ecuador jwilson3

    A proper refactoring would remove the hook_form_alter() and the process callback, and move the logic therein into hook_field_widget_WIDGET_TYPE_form_alter() hooks.

    I'm not entirely certain what problem you're trying to solve with the patch in #3, so it would be helpful if you could explain the problem and the solution.

    Also, we need to be using Merge Requests, not patches.

  • 🇪🇨Ecuador jwilson3

    Note: hook_field_widget_WIDGET_TYPE_form_alter was deprecated in Drupal 9.3, we should use hook_field_widget_single_element_WIDGET_TYPE_form_alter instead.

    I'm self-assigning this to start proof of concept explorations...

  • Assigned to jwilson3
  • Status changed to Needs work 3 months ago
  • 🇪🇨Ecuador jwilson3

    Current status:

    • I've created several TEST submodules for testing Core Fields, Custom Fields, Paragraphs (cherrypicked from Add Label Help support for Paragraphs module fields Active ) and a few random contrib modules that implement their own field widgets (Theme Field, Address Field, Telephone Advanced).
    • Happy to report that Paragraphs integration now works! 🎉
    • Special case code was added to support the three Address field widgets.
    • All core field types and widgets work with the exception of:
      • Radio buttons. Eg, A "List" field configured with 2 or more options, "Allowed number of values" is set to 1, and the "Check boxes / radio buttons" (options_buttons) is selected as the field formatter. In this setup, the radios do not display AND the Label Help does not display
    • Presumably other contrib modules will need custom field widget logic specifically added. This may be a deal breaker and cause regressions on existing installs, but it is hard to know what people are using out in the wild. Ultimately (sadly) this will likely require smarter fallback logic, similar to the original codebase.
Production build 0.71.5 2024