Fieldset field handles causing errors in Bard

[stuartcusackie]

Bug description

I have a Button field set with the fields:

• type
• url
• document
• entry
• form

If I add this fieldset to a Bard field then I get the following errors after hitting the Add Set button:

vue.common.prod.js:6 TypeError: Cannot read properties of undefined (reading 'display')
vue.common.prod.js:6 TypeError: f.hasAttribute is not a function

I can solve this by prefixing each field width btn_, so they become:

• btn_type
• btn_url
• btn_document
• btn_entry
• btn_form

This is fine but I don't understand the problem. Should fieldset fields always be prefixed or am I using a reserved name for a field?

I've seen some comments stating that custom validation rules for fields that are nested in fieldsets should be defined like so: button.entry or button.btn_entry So I'm finding the naming of fields a little confusing.

How to reproduce

Set up a fieldset with this YAML then link it as a set in a Bard field.

title: Button
fields:
  -
    handle: type
    field:
      options:
        document: Document
        entry: Entry
        url: Url
      multiple: false
      clearable: false
      searchable: true
      taggable: false
      push_tags: false
      cast_booleans: false
      default: url
      display: 'Button Type'
      type: select
      icon: select
      width: 50
      listable: hidden
      instructions_position: above
      validate:
        - required
  -
    handle: entry
    field:
      max_items: 1
      mode: default
      create: true
      collections:
        - articles
        - pages
        - posts
      display: Entry
      type: entries
      icon: entries
      width: 50
      listable: hidden
      instructions_position: above
      validate:
        - 'required_if:button.type,entry'
      if:
        type: 'equals entry'
  -
    handle: document
    field:
      mode: list
      restrict: false
      allow_uploads: true
      show_filename: true
      max_files: 1
      display: Document
      type: assets
      icon: assets
      width: 50
      listable: hidden
      instructions_position: above
      container: documents
      validate:
        - 'required_if:button.type,document'
      if:
        type: 'equals document'
  -
    handle: url
    field:
      input_type: url
      antlers: false
      display: URL
      type: text
      icon: text
      width: 50
      listable: hidden
      instructions_position: above
      validate:
        - 'required_if:button.type,url'
      if:
        type: 'equals url'
  -
    handle: label
    field:
      input_type: text
      antlers: false
      display: Label
      type: text
      icon: text
      width: 50
      listable: hidden
      instructions_position: above
      validate:
        - required

Logs

No response

Versions

Statamic 3.2.29 Pro Laravel 8.78.0 PHP 8.1.1 edalzell/blade-directives 3.5.1

Installation

Fresh statamic/statamic site via CLI

Additional details

No response

[arthurperton]

It's just the handle type that is causing the trouble. Maybe it collides with the set's type somewhere... The other fields are okay.

For now, you'll be fine when you rename the type field only.

[stuartcusackie]

Good to know. Thank you. Perhaps Statamic should display an error for reserved field names like this?

[arthurperton]

You're welcome! And yes Statamic already does that for reserved words. It's just that 'type' is not in the list currently. It probably should be, from the looks of this issue.

[arthurperton]

It's also not related to fieldsets. When you add a field with handle 'type' to the Bard set itself directly, the same error occurs.

And within a replicator set there's also a collision, but it plays out differently: the value of the 'type' field defaults to the set handle.

I am going to add 'type' to the list of reserved words.

[stuartcusackie]

I like how this is progressing!

[jasonvarga]

At the moment we don't have a way to differentiate between globally reserved field names and replicator set specific reserved field names. I've reverted type being globally reserved. It's way too common.

Until we have a way to scope the reserved words to replicator sets, you'll just have to remember to not use type in a set.