Issue: Content type actions generate half-functioning block fields.

[theinfinit]

Describe the bug

I have used the Content type action "Add missing fields" to generate missing fields based on the frontmatter.

It generated structure that is using block type with fields instead of fieldGroup as described in the documentation. And it is almost working.

1. Records can be correctly removed and swapped,
2. but editing and adding new records doesn't seem to work.

The generated structure is actually great, and what I would expect. Defining working structures like this without fieldGroup property will be really handy, as it is often unnecessary for creation of working frontmatter schema.

To Reproduce

Steps to reproduce the behavior:

1. Add missing field to the frontmatter:

---
hero:
  title: |
    Welcome to Starlight
  tagline: Congrats on setting up a new Starlight project!
  image:
    file: ~/assets/houston.webp
  actions:
    - text: Example Guide
      link: /guides/example/
      icon: right-arrow
      variant: primary
    - text: Read the Starlight docs
      link: https://starlight.astro.build
      icon: external
---

2. Click on 'Add missing fields'
3. See generated fields.

Expected behavior

It's expected for "Content type actions" to generate valid, working fields. Additionally, editing and adding new records while using fields with block will be valuable addition.

Screenshots

As you can see, each object is properly recognized and swapped, so it seems like any kind of discriminator (like fieldGroup) is not necessary for Front Matter CMS to recognize and handle the objects correctly. But addition is for sure more complex :)

front-matter-block-with-fields.mp4

---

Desktop (please complete the following information):

• OS: Win11
• Version: Beta v10.2.9129636

Additional context: Generated part of the config

  {
    "title": "hero",
    "name": "hero",
    "type": "fields",
    "fields": [
      {
        "title": "title",
        "name": "title",
        "type": "string"
      },
      {
        "title": "tagline",
        "name": "tagline",
        "type": "string"
      },
      {
        "title": "image",
        "name": "image",
        "type": "fields",
        "fields": [
          {
            "title": "file",
            "name": "file",
            "type": "string"
          }
        ]
      },
      {
        "title": "actions",
        "name": "actions",
        "type": "block",
        "fields": [
          // Note: It actually generated two objects, for each entry present in the frontmatter
          {
            "title": "0",
            "name": "0",
            "type": "fields",
            "fields": [
              {
                "title": "text",
                "name": "text",
                "type": "string"
              },
              {
                "title": "link",
                "name": "link",
                "type": "string"
              },
              {
                "title": "icon",
                "name": "icon",
                "type": "string"
              },
              {
                "title": "variant",
                "name": "variant",
                "type": "string"
              }
            ]
          },
        ]
      }
    ]
  },

[estruyf]

Thanks for opening an issue for this. Some enhancements are required to support more "complicated" structures.

[estruyf]

@theinfinit I have added support for your sample in the latest beta.

The above example should now generate a new field group:

{
  "frontMatter.taxonomy.fieldGroups": [
    {
      "id": "actions_group",
      "fields": [
        {
          "title": "text",
          "name": "text",
          "type": "string"
        },
        {
          "title": "link",
          "name": "link",
          "type": "string"
        },
        {
          "title": "icon",
          "name": "icon",
          "type": "string"
        },
        {
          "title": "variant",
          "name": "variant",
          "type": "string"
        }
      ]
    }
  ]
}

And map this group in for the block field:

{
  "title": "actions",
  "name": "actions",
  "type": "block",
  "fieldGroup": [
    "actions_group"
  ]
}

This allows you to change the values from the UI:

[theinfinit]

Thank you Elio for the fast response! I appreciate your dedication.

I tested your example with beta v10.2.9211615. I can edit the fields now. Output of the Content type action improved a lot too.

The only thing that is bothering me, is the added fieldGroup field. For simple cases like this, where we have an array of objects (each with the same schema). And considering the editing capabilities of the current solution — I would advocate for the ability to disable the addition of the fieldGroup.

Why?
Sometimes the frontmatter schema is configured in a strict way and doesn't allow the unknown fields. In such cases, you'll have to extend the schema with dummy fieldGroup field to make things work again.

---

Also, for more complex cases, and easier integration with existing websites, the ability to rename the fieldGroup discriminator, would help with the adoption of the Front Matter CMS.

What do you think?

[estruyf]

The fieldGroup property was introduced because there are situations where multiple types of field groups were added. The fieldGroup property links it with the correct group.

We can look into removing this property when only one group is defined. For that we best create a new issue to track its progress.

[theinfinit]

That will be great. It is pretty common case, that discriminator is not used for arrays of objects of the same type.