- 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 usehook_field_widget_single_element_WIDGET_TYPE_form_alter
instead.I'm self-assigning this to start proof of concept explorations...
- Merge request !18Issue #3495740 by jwilson3: Use hook_field_widget_complete_form_alter() → (Open) created by jwilson3
- Assigned to jwilson3
- Status changed to Needs work
3 months ago 11:20am 23 February 2025 - 🇪🇨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
- ❌ 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" (
- 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.