Get Rid of 'Sections'

[luxlogica]

From a user perspective, the distinction between 'section' and 'field' is often blurry, and somewhat confusing. Here are two screenshots, one is of an Info Section, and the other one is of an Info Field (in a Fields Section) - guess which one is which:

They seem to be visually identical, and functionally the Info Field has an advantage: it can be used in Structure Fields. So, why have an 'Info Section' at all?

Similarly, the Pages Section also has a matching Pages Field, and the Files Section has also a Files Field. The main functional difference between the 'section' and the 'field' version of these is that the user must upload/create via a 'section', and must select via a 'field'. This seems to be unnecessarily cumbersome, splitting functionality that could be condensed in one single interface.

Indeed, after introducing Kirby 3 to a couple of clients, the question came up: why do we have to upload in one place, and select in another - specially when they both look pretty much the same? Why not simply allow the user to upload/create with the field itself? Interface-wise, to turn the 'files field' and 'pages field' into a 'section', all that would be needed would be a couple of interface elements - i.e., an 'Add' button at the top of the field, and a 'Delete' option in the page/file listing.

If we could do that, then the only 'section' type needed would be the Fields Section. And if there is only ever one kind of 'section', then no 'section' specification is needed at all. This would make page, file and user blueprints simpler.

We could still have 'section blueprints' as we have now, but rather than extending 'sections', these could be used to extend COLUMNS and TABS instead:

tabs:
  meta:
    columns:
      - width: 2/3
        extends: metadata
      - width: 1/3
        fields:
          info:
            type: info
            text: the information in this tab is used to help your search engine rankings
  images:
    extends: images

Plugin authors would not have to choose between a 'field' or a 'section' plugin - they would all be 'field' plugins - and for interfaces that require multiple fields the author could include a predefined 'section blueprint' with all the fields laid out.

[nilshoerrmann]

Coming from another content management system when working with Kirby 3 for the first time, I have to say that I'm really fond of the differentiation of fields and sections. I see very different use cases for both types.

Primarily, sections are content representations in my eyes while fields are content editors. Yes, sections allow status changes (page publication or file template selection) but in general sections don't write content to the file system. They are an advanced tool to organise content in the panel and are a UI kit to build the custom interface I need for a project.

Having a file section and a file field offers great flexibility and having both separated helps focussing on the different use case. While the end result might be similar, the workflows are quite different and I see good reasons to use the file field for one project and file sections for another one for instance. This totally depends on the content managed and the habits of the users.

I agree that managing blueprints gets cumbersome but to me this is a result of the syntax change that led to nesting all blueprints settings and not related to the concept of sections vs. fields.

[luxlogica]

@nilshoerrmann We all know that File fields are necessary. We all know that Page fields are, too. But considering that in order to select a file in the field you first need to upload it with the section, I can't really see a use-case where you might have the field without the section. Same thing for the Page field and Page section. So, we can safely say that we cannot have the field without the section - not unless you're thinking of some really obscure edge cases...

If we had a field that did BOTH, we could then have options like selection: false and add: false to selectively turn either of the field's functionality off. This would allow us to still have an interface that could be used just for selection, or just for uploading/creating, if needed. Except that now the interface and UX would be simpler and more intuitive - and so would our blueprints!

[nilshoerrmann]

I very much agree that the pages and file fields need to be improved, that they should allow the direct creation of new entries for example. But I don't agree that these extended fields would render the respective sections superfluous:

• In a project we are currently working on, we have a nested project structure: we use pages sections to show child pages and allow the addition of new subpages. Nothing needs to be stored in the parent's content file. The page structure is reflected by the folder structure.

• In the same project we also have awards pages. Each award can reference a project. Here we use a pages field to select the references which are then stored in the award's content file.

These are two different use cases requiring different interfaces that are very well represented by sections and fields.

[luxlogica]

What I proposed would indeed cover both use-cases in your example. I'm sure there are also many other creative ways of combining the functionalities in a single interface, in a way that would be even more suitable.

Nevertheless, if we do prefer to have 2 separate interfaces - one for 'create/delete', and one for 'select' - why not simply have a create page field, and a select page field? Seems there is still no need to add the separate concept of a 'section'.

[lukasbestle]

The section type was introduced in Kirby 3. In Kirby 2, we had exactly what you are describing: Everything was a field.

In Kirby's definition, fields are Panel elements that store something in the content file, while sections are Panel elements that are used for other purposes (like to display other pages or files, info widgets for help texts or even Matomo stats etc.).

In my opinion it makes sense to keep those two categories (field and section) separate. The Kirby 2 approach has always been a hack – if field plugins weren't configured correctly, they would have stored an empty field value in the content file even though the plugin wasn't even meant to store any content. It was just very confusing.

With the new flexible Panel layout in v3, it made sense to differentiate between fields and sections – especially because we don't have a dashboard anymore as the site blueprint can be configured as freely as any other blueprint.

So now to your two main points:

• The info section was introduced because it often makes sense to display an info box outside of a fields section (e.g. in a side column). Also it fits the semantics (it's not an element that stores content). The reason why we kept the info field is that it may sometimes also make sense to display an info box within a fields section. Also it ensures backwards-compatibility.
• I agree that the pages and files fields are not optimal yet. We will definitely improve those over time. But in my opinion, their issues don't have much to do with them being a field and the sections being sections. We can still make the fields great for their specific use-cases. :)