The icon picker is silently ignored on a prop that also declares an enum

Example 1 of 4: what an enum-constrained icon prop looks like today. Reproduced on a stock Drupal CMS install, so this is not distribution-specific.

Environment: Drupal CMS with the Haven site template, Drupal core 11.4.5, PHP 8.4.20, Drupal Canvas 1.10.1, UI Icons 1.1.2, Canvas Icon Picker 1.0.3 unpatched. Icon pack is Haven's own phosphor, 1512 icons.

A component with a curated icon set, declaring both enum and x-canvas-icon:

icon:
  type: string
  title: Icon
  default: info
  enum:
    - info
    - warning
    - check-circle
    - x-circle
  'meta:enum':
    info: Information
    warning: Warning
    check-circle: Success
    x-circle: Error
  x-canvas-icon: ['phosphor']

Canvas derives field_type: list_string with field_widget: canvas_icon_picker. The widget only supports string, so it is dropped and a plain select renders. No error, no warning.

What the editor shows: an Icon select with _none, info, warning, check-circle, x-circle, and zero picker elements in the DOM.

The next three comments show the same site with the merge request applied.

AI-Generated: Yes

Example 2 of 4: a curated set that ships in Drupal CMS today. This one needs no invented component. The Haven site template's own Button already curates its icon prop:

icon:
  type: string
  title: Icon
  enum:
    - arrow-right
    - arrow-left
    - caret-right
    - caret-left
    - download
    - user-plus
  'meta:enum':
    arrow-right: 'Arrow right'
    arrow-left: 'Arrow left'
    caret-right: 'Caret right'
    caret-left: 'Caret left'
    download: Download
    user-plus: 'User plus'

Six icons, with labels, chosen by the theme's designers. Haven does not yet opt into this module, so for the test I added x-canvas-icon: ['phosphor'] to that prop and nothing else.

Unpatched, that combination gives the select from the previous comment. With the merge request applied, the picker renders and the grid holds exactly those six:

The drawer reports 6 icons, and the element requests only those ids:

data-canvas-icon-picker-index-url="/canvas-icon-picker/index?packs=phosphor&ids=arrow-right,arrow-left,caret-right,caret-left,download,user-plus"

So the theme keeps its curated set and the editor still gets a visual picker.

AI-Generated: Yes

Example 3 of 4: a share component, where only social icons make sense. This is the case the Webshare module covers: buttons that share the current page. Webshare itself ships no Single Directory Components, so this is a small component modelled on it.

name: Share button
props:
  type: object
  required:
    - network
  properties:
    network:
      type: string
      title: Network
    icon:
      type: string
      title: Icon
      default: link-simple
      enum:
        - facebook-logo
        - x-logo
        - linkedin-logo
        - instagram-logo
        - whatsapp-logo
        - telegram-logo
        - reddit-logo
        - envelope
        - link-simple
      'meta:enum':
        facebook-logo: Facebook
        x-logo: X
        linkedin-logo: LinkedIn
        instagram-logo: Instagram
        whatsapp-logo: WhatsApp
        telegram-logo: Telegram
        reddit-logo: Reddit
        envelope: Email
        link-simple: 'Copy link'
      x-canvas-icon: ['phosphor']
      examples:
        - facebook-logo

Nine icons out of the pack's 1512. An editor picking a share icon should not be offered 1512 options, and the component should not accept an arbitrary one.

The drawer reports 9 icons, and the grid tiles are exactly the enum values: link-simple, linkedin-logo, telegram-logo, instagram-logo, x-logo, envelope, whatsapp-logo, facebook-logo, reddit-logo.

AI-Generated: Yes

Example 4 of 4: no enum, nothing changes. Haven's own Icon card has an icon prop with no enum, so the whole pack stays available. This is the regression check: the patch must not narrow a prop that was never curated.

icon:
  type: string
  title: Icon
  x-canvas-icon: ['phosphor']

The drawer reports 1512 icons and the request carries no ids parameter:

data-canvas-icon-picker-index-url="/canvas-icon-picker/index?packs=phosphor"

Summary of the four examples

Same site, same pack, canvas_icon_picker 1.0.3 versus 1.0.3 plus the merge request:

component                        enum   1.0.3                      with MR !1
Notice (demo)                    4      list_string, select        string, picker, 4 icons
Haven Button (ships in Haven)    6      list_string, select        string, picker, 6 icons
Share button (Webshare case)     9      list_string, select        string, picker, 9 icons
Haven Icon card (ships)          none   string, picker             string, picker, 1512 icons

All six Haven components with an icon prop were opted in (Button, Badge, Card, Icon card, Feature card, Icon). Front page stayed HTTP 200 throughout, and the patch applies cleanly to the 1.0.3 tarball from ftp.drupal.org.

One note on adoption, since it surprised me: opting a theme in by adding x-canvas-icon to its manifests is safe on a site with existing content. Canvas derives a new component version and existing instances keep resolving against the stored one.

AI-Generated: Yes

A second merge request, as an alternative to the first. Same outcome, smaller surface. They are mutually exclusive, so pick whichever fits the module better.

• MR !1 forces the field to string and carries the enum forward in a new allowed_icon_ids field instance setting, which needs a config/schema addition. 7 files.
• MR !2 leaves the field as list_string and reads the constraint where Canvas already keeps it. No new setting, no schema change, and canvasStorablePropShapeAlter() is untouched. 5 files.

The idea behind !2 is that the module does not need to be told about the enum, it can just notice it. A prop declaring enum already becomes a list field whose allowed values are those enum members, so the constraint exists on the field before the picker gets involved. Three small changes are enough:

• the widget declares field_types: ['string', 'list_string'], so Canvas stops discarding it for an enum-constrained prop;
• allowed ids come from that field's own allowed_values_function, which is Canvas's canvas_load_allowed_values_for_component_prop;
• massageFormValues() strips the pack: prefix on a list field, so the stored value stays one of the allowed values.

Verified on the same Drupal CMS and Haven site as the examples above, with Canvas Icon Picker 1.0.3. A prop with a curated enum of four goes from a plain select to the picker reporting 4 icons, requesting /canvas-icon-picker/index?packs=phosphor&ids=info,warning,check-circle,x-circle. A prop with no enum is unaffected, still 1512 icons and no ids parameter.

One part of !2 I am not confident about: it calls allowed_values_function directly, because getSettableOptions() came back empty in the widget context. If there is a better-supported way to reach a list field's allowed values from a widget, that is the line to change.

AI-Generated: Yes

MR !2 on Drupal CMS with the Byte site template. Fresh install, template picked in the installer, then MR !2 applied to Canvas Icon Picker 1.0.3.

Environment: Drupal core 11.4.5, PHP 8.4.20, Drupal Canvas 1.10.1, UI Icons 1.1.2. Icon pack is Byte's own phosphor, 1512 icons. Byte does not opt into the picker yet, so x-canvas-icon: ['phosphor'] was added to its four icon props and nothing else.

Byte's Button ships a curated enum of six, the same set Haven ships:

icon:
  type: string
  title: Icon
  enum:
    - arrow-right
    - arrow-left
    - caret-right
    - caret-left
    - download
    - user-plus

With MR !2 the field stays list_string, the widget is no longer discarded, and the grid holds exactly those six. The drawer reports 6 icons, the request carries ids=arrow-right,arrow-left,caret-right,caret-left,download,user-plus, and no select renders.

Byte's Icon card has no enum, and is unaffected: 1512 icons, no ids parameter.

Config for the four opted-in components, after the patch:

component   enum   field_type    widget
button      6      list_string   canvas_icon_picker
badge       none   string        canvas_icon_picker
card-icon   none   string        canvas_icon_picker
icon        none   string        canvas_icon_picker

Front page stayed HTTP 200 throughout.

AI-Generated: Yes

MR !2 on Drupal CMS with the Mercury Demo site template. A second fresh install, Mercury Demo picked in the installer, then MR !2 applied to Canvas Icon Picker 1.0.3.

Same environment as the Byte comment: Drupal core 11.4.5, PHP 8.4.20, Drupal Canvas 1.10.1, UI Icons 1.1.2, Mercury's own phosphor pack of 1512 icons. Mercury does not opt into the picker yet, so x-canvas-icon: ['phosphor'] was added to its four icon props and nothing else.

Mercury's Button curates the same six icons Haven and Byte curate, which is worth noting on its own: this shape is standard across the Drupal CMS site templates, not a one-off.

Drawer reports 6 icons, request carries ids=arrow-right,arrow-left,caret-right,caret-left,download,user-plus, no select:

Mercury's Icon card has no enum and is unaffected: 1512 icons, no ids parameter.

Coverage so far for MR !2

platform / template          component     enum   result
Drupal CMS + Haven           button        6      picker, 6 icons
Drupal CMS + Byte            button        6      picker, 6 icons
Drupal CMS + Mercury Demo    button        6      picker, 6 icons
Drupal CMS + Byte            card-icon     none   picker, 1512 icons
Drupal CMS + Mercury Demo    card-icon     none   picker, 1512 icons
Varbase 11 + Vartheme BS5    badge         43     picker, 42 icons

The Varbase row is the one that differs: its enum of 43 includes none, which is a valid prop value but not an icon, so the grid shows 42 tiles for 43 requested ids. Worth knowing if you want the count label to match the enum length exactly.

One limitation of MR !2 to record: it keys off the field being list_string. A component instance pinned to a stored version created while MR !1 was applied has field type string, so it renders the picker unrestricted. That only affects a site that ran !1 first.

AI-Generated: Yes