- Issue created by @jwilson3
I have tried to solve the issue and created the patch please review it and let me know
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.
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.
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
#2731637: Add Label Help support for Paragraphs module fields →
.
None.
None.
None.
Active
2.0
Code
I have tried to solve the issue and created the patch please review it and let me know