Blueprint: simplify mixing of fields and sections

[medienbaecker]

Currently, mixing fields and sections in a blueprint is very cumbersome and redundant. As an example:

sections:
  my_fields:
    type: fields
    fields:
      my_field:
        type: textarea
  my_section:
    type: files
  my_other_fields:
    type: fields
    fields:
      my_other_field:
        type: textarea
  my_other_section:
    type: files

There needs to be a simpler, more Kirby-like way.

[medienbaecker]

Maybe it should be possible to get rid of the whole fields: type: fields fields: thing by allowing a fields shortcut:

sections:
  fields:
    my_field:
      type: textarea
  my_section:
    type: files
  fields:
    my_other_field:
      type: textarea
  my_other_section:
    type: files

[manuelmoreale]

Why not something like this?

sections:
  fields:
    my_field:
      type: textarea
  files:
    my_section:
  fields:
    my_other_field:
      type: textarea
  files:
    my_other_section:

  # And Also
  pages:
    my_pages_section:

Which follows the same concept that's currently used for tabs and columns

columns:
  left:

columns:
  - width: 1/2

tabs:
  my_tab:

[lukasbestle]

I agree that the current syntax is a bit too verbose and cumbersome.

Unfortunately your suggestions (which I really like conceptually) won't work as you can't have the same array key twice in a YAML array. The sections will be overwritten with the last instance of each type.

[manuelmoreale]

@lukasbestle I suspected that was the reason behind the current implementation. Just thinking out loud here because I'm not familiar with how YAML works: can you use special characters in the keys?

And do something like this

fields.my_field:
    type: textarea

files.my_section:

fields.my_other_field:
    type: textarea
files:
  my_other_section:

# And Also
pages.my_pages_section:

I'm using a dot but could be something else. Maybe even an implementation similar to the current column syntax could work

sections:
  - section : fields

Again, not sure which one is possible to implement, just throwing suggestions out there 🙂

[lukasbestle]

Just thinking out loud here because I'm not familiar with how YAML works: can you use special characters in the keys?

Yes, that should be possible.

[medienbaecker]

This topic comes up with almost every website I build. Also when explaining how blueprints work to Kirby newbies. I feel like this issue has to be solved for Kirby blueprints to be easier to understand.

A simple example

Here's a simple blueprint with text and images:

sections:
  text:
    type: fields
    fields:
      intro_text:
        label: Intro Text
        type: textarea
  images: sections/images

Now I want to add headlines to separate my sections. It might not be needed for this very simplified example. Once you have some more complex blueprints you will need lines, headlines or info fields at some point.

Anyway, look at the amount of lines and nesting I need to add for the images headline:

sections:
  text:
    type: fields
    fields:
      text_headline:
        label: Text
        type: headline
      intro_text:
        label: Intro Text
        type: textarea
  images_headline:
    type: fields
      fields:
        images_headline:
          label: Images
          type: headline
  images: sections/images

A fields section for one single field. 5 tabs nesting.

The solution?

Have a look at the info section. It exists because "(…) the info section can be placed anywhere else, especially in layouts that don't need form fields".

Based on this, we would need a headline section. 100% identical to the headlines field, but a section. Also a line section. 100% identical to the line field, but a section. That's not a solution at all in my opinion. The info section is not a solution either. It makes things worse for Kirby newbies. It also makes it harder to explain the differences between fields and sections. A very hard concept to grasp, when new to Kirby.

Ideas

We had some ideas further up this thread, but I guess none of them are easy to build. I'd really appreciate some more discussion on this topic, though.

For example: is it possible to check if the section variable is already taken (pages, files, …) and make it a fields section if not? Removing the line type: fields would be a step in the right direction in my opinion.

[lukasbestle]

I fully agree!

Radical suggestion: What about getting rid of sections completely and making them fields that just don't store anything in the content files? If every blueprint component was of the same type (except tabs and columns, which would still be a thing), you could mix and match them as you like.

For backwards-compatibility it would probably need to be implemented the other way around (make the individual fields accessible on the section level), but the end result would be the same.

[medienbaecker]

@lukasbestle I didn't dare to suggest this. But that might be the only way to actually improve it.

We discussed getting rid of sections some time ago: https://github.com/getkirby/ideas/issues/122

[distantnative]

Keep in mind that we have both pages section and pages fields (same for Files) that serve very different functionalities. This could get very nasty when avoiding breaking changes.

[distantnative]

I think I would stick with having sections and fields, but maybe the Panel could be as smart that if a type called on the section level doesn’t exist as section but as field, just wrap it with a fields section on the fly

[lukasbestle]

That’s a nice and backwards-compatible solution. It also allows the flexibility to still use fields sections as a conditional section etc.

[medienbaecker]

I greatly appreciate the discussion and really like this solution! No idea how complex the smart blueprint parsing is, of course.

One thing to keep in mind: using a pages or files field will always require a manual fields section. But that's a non-issue in my opinion, it just has to be explained in the docs. Those fields are rarely used in the section layer anyway.