Add form element(s) for Icon API

Currently trying to get feedbacks from contrib module maintainers:

• iconset: #3466621: Compatibility with the Icon API proposal for Core
• icons: #3482281: Compatibility with the Icon API proposal for Core
• ex_icons: #3482291: Compatibility with the Icon API proposal for Core
• iconify_icons: TODO
• micon (icomoon): TODO
• md_fontello: TODO
• iconify_field: TODO

Jean, can you have a look?

Rebased & squashed (the previous HEAD has been tagged previous/3528969-add-form-elements/2026-04-2)

Pipeline is red. David (@gxleano), you can assign to you if you want to check.

I think this is ready now

That's so great. I will have a last look (by testing with 2 modules already using Icon API: UI Icons & Iconify and commit to main and 11.x.)

Tested with the #3589768: Drupal 12 compatibility branch of UI Icons.

I did this temporary change in \Drupal\ui_icons\Element\IconAutocomplete:

 #[FormElement('icon_autocomplete')]
-class IconAutocomplete extends FormElementBase {
+class IconAutocomplete extends \Drupal\Core\Render\Element\IconAutocomplete {

But the Core icon_autocomplete form element (\Drupal\Core\Render\Element\IconAutocomplete) is always loaded instead of the contrib one anyway. At least it doesn't break.

Issue about submitted value

• ui_icons_media: Creating or editing a media entity using the Icon media source plugin: Error message: "This value should not be null."
• ui_icons_menu: Creating or editing a menu item: I can pick an icon, but fatal on submitting or when I display the rendered menu item: Cannot access offset of type string on string in ui_icons_menu_link_alter() (line 159 of ui_icons_menu.module).
• ui_icons_field Creating or editing a content entity with Autocomplete widget: I can pick an icon but the value is not saved at submit
• ui_icons_field Creating or editing a content entity with picker widget: Everything works fine (which is expected, because Core MR is not impacting this)
• ui_icons_ckeditor5: it silently fails, the icon is not injected in the WYSIWYG area

I guess it is because the value is always submitted as 'pack_id:icon_id', but in UI Icons, it is the case only when #return_id is TRUE, but it is FALSE by default. For information, #return_id is:

• TRUE in ui_icons_field (with icon_link_widget), ui_icons_media (in media library), ui_icons_menu (using icon_link_widget), and ui_icons_patterns
• FALSE in ui_icons_ckeditor5, ui_icons_field (with icon_widget) and ui_icons_media (in entity form display)

Missing settings form

The icon settings form is missing from Core form element. In UI Icons, it is displayed in ui_icons_ckeditor5, ui_icons_field (with icon_link_widget if the setting is TRUE), ui_icons_patterns and ui_icons_menu.

I understand this decision, it is to keep Core form element simple and avoid the burden of generating a form from JSON schema (something we are still figuring out for SDC). So, it is the role of contrib module like UI Icons to extend the element, adding settings management.

To review

Overriding the element is fixing both the value type issue and the missing setting form:

function ui_icons_element_plugin_alter(array &$definitions) {
 $definitions['icon_autocomplete']['class'] = '\Drupal\ui_icons\Element\IconAutocomplete';
}

So UI Icons will still work after this MR is merged. That' a relief, but are we at risk of diverging from the broader Icon API ecosystem by having such divergences in our own implementation?

Jean (@mogtofu33), as both the Icon API expert and the UI Icons lead, are you OK about this MR?

Without any news late Thursday May 14th, I will put the ticket back to RTBC.