[Panel] Field groups are missing

[olach]

Describe the bug I just started converting a Kirby 2 site to Kirby 3. One roadblock I encountered is that field groups doesn't seem to be implemented yet in K3. When using this functionality I get this error in the Panel: Invalid field type ("group").

Field groups are described in the Kirby 2 docs about Global Field Definitions.

As a long time Kirby 2 user, I would expect this functionality to be present in Kirby 3 to ease the process of upgrading a site to Kirby 3.

To Reproduce A small example that doesn't work in Kirby 3, but does work in Kirby 2:

# /site/blueprints/fields/layout.yml
type: group

fields:
  headline_layout:
    type: headline
    label: Layout
    numbered: false
  margin_top:
    type: text
    label: Margin top
    width: 1/4
  margin_bottom:
    type: text
    label: Margin bottom
    width: 1/4
  padding_top:
    type: text
    label: Padding top
    width: 1/4
  padding_bottom:
    type: text
    label: Padding bottom
    width: 1/4

# /site/blueprints/pages/default.yml
fields:
  layout: fields/layout

Expected behavior The fields defined in /site/blueprints/fields/layout.yml should be visible in the Panel on pages with the default template.

Kirby Version 3.0.0-beta-6.24

Console output None

Desktop (please complete the following information):

• OS: macOS 10.14.1
• Browser: Safari 12.0.1

[lukasbestle]

The feature does exist, but it works differently: https://nnnnext.getkirby.com/docs/guide/blueprints/sections#extending-sections I'm pretty sure that should work for all types of blueprint snippets (tabs, columns, sections, fields), but it's not documented so far.

[texnixe]

I don't think it works like @ola expects it to work. While you can extend a fields section, you wouldn't be able to put another fields section inside a fields section, to combine them. Unless I've missed something. https://getkirby.slack.com/archives/CBN859614/p1543849383116600

[lukasbestle]

Ah, I see there was already a discussion in Slack about this and the issue is that there is currently no way to globally define a group of fields specifically (vs. a fields section, which is possible).

Is there a reason why you can't define the set of fields in a fields section instead?

[olach]

You can't insert a new section into a current fields section.

For example, I'm using the Builder plugin to create pages using reusable modules.

Within the modules, I have some fields that all modules have, like layout settings (margin, padding etc). Instead of repeatadly defining these fields in all modules, I can have one field group where I specify these common fields once. Then, in each module, I extend this field group.

This is just one example. I'm using field groups in other areas in the Panel too. It's really convenient. So it was really sad to see it didn't worked in K3.

[lukasbestle]

That makes sense. Especially the Builder field is an example where importing a whole section at once doesn't work.

[bastianallgeier]

✅

[olach]

Thanks for a quick turnaround for this. I tested this, and need to reopen this because the implementation has some issues.

1. When a field group is inserted on a page, the fields is always inserted at the end of the page. Not at the specified location in the blueprint.

2. Also, field groups doesn't work in the builder plugin. But I guess that the plugin author needs to support field groups?

[bastianallgeier]

@olach sorry for the placement bug. I just fixed that. I'd prefer to create a separate ticket for the issue with the build plugin in the builder plugin repo.

[TimOetting]

Hey @olach and @bastianallgeier,

I was wondering why the extend feature inside the kirby panel is so limited so some areas inside the panel. For the builder field I already extended this syntax in such a way that I could use it everywhere inside the blueprint. Here is an example from for the builder:

The extends can be uses anywhere inside the field's blueprint:

# /site/blueprints/myblueprint.yml
...
fields:
...
  builderfield:
    label: My Kirby Builder
    type: builder
    fieldsets:
      quote:
        extends: blocks/quote
      bodytext:
        extends: blocks/bodytext
      events:
        extends: blocks/events
...

They are simply replaced by the content from within the specified yaml file

# /site/blueprints/blocks/quote.yml

label: Quote
preview:
  snippet: blocks/quote
  css: /assets/css/blocks/quote.css
fields:
  text:
    label: Quote Text
    type: textarea
  citation:
    extends: nested/basetext # even nested!

And even nested extends are possible

# /site/blueprints/nested/basetext.yml

label: Tester Texty
type: text
default: This is an extended default text

Are there any reasons that I missed for not allowing this by default?

[olach]

@TimOetting To clarify. Yes, I can extend and nest extends in your builder field. It's only when I try to extend a field group that your plugin emits an error: The field type "group" does not exist.

[TimOetting]

@olach I just wonder if field groups are necessary if the extend feature would work globally. Wouldn't it be the best (and most consistent) way if your example would work like this:

# /site/blueprints/fields/layout.yml
headline_layout:
  type: headline
  label: Layout
  numbered: false
margin_top:
  type: text
  label: Margin top
  width: 1/4
margin_bottom:
  type: text
  label: Margin bottom
  width: 1/4
padding_top:
  type: text
  label: Padding top
  width: 1/4
padding_bottom:
  type: text
  label: Padding bottom
  width: 1/4

# /site/blueprints/pages/default.yml
fields: 
  extends: fields/layout

Anyway, if the field groups will find their way to the RC it is a feature that should also be working in the builder plugin. But I would like to hear @bastianallgeier 's opinion on this first :)

[olach]

@TimOetting Field groups are now implemented in core as of a few days ago. Test the latest nightly build. It's only in your plugin that it doesn't work. :(

[TimOetting]

@olach Yeah, sure. I guess I am a little bit too late for the discussion about wether or not the field groups make sense in kirby 3 :) . As I said, I will make them work for the builder field. Unless somebody removes them from the core... which will not happen, I guess :)