The "sections" concept is confusing

Sections are very confusing: “Sections help you to organize content in the Panel OR provide additional information OR functionality.” :thinking:

I feel like sections try to do too many things. “Fields section” are basically “field group” while “pages section” seem to be something completely different similar to a “content dashboard”.

The typical use case of the section would be the creation of contents that are not tied to a given page. Typically blog posts or events. In my understanding do not want to use fields in that case, it doesn’t make a lot of sense to add the ID of every blog post in a sub-page. But then why they cannot be filtered using a query?

Perhaps it will make sense at one point. But at the moment I think it’s very weak and confusing and contrast with the rest of the CMS that is pretty dead simple (except also the usage of “page” instead of “content”, but that was easy to understand).

The distinction is that sections do not store anything, but fields do. Sections are for organisation and display, or a way to get to child pages or files. If you want to store something, use fields. You do not have to use a section for fields.

As an example, the pages section will display pages that are children of the current page (unless you configure it to do otherwise). It will also allow you to add new pages. A pages field however, allows you to select pages and store them, perhaps for use in a site menu.

You can make custom methods/filters for the query language if you need more than the built in options.

The easiest way to to think of it is to consider your sites landing pages. These are the top level section pages such as “products” or “blog”. Its on these pages that your are most likely to use sections rather than fields, since you need a way to get to the content under that section.

1 Like

I stumble multiple time on the “sections do not store anything”. This is a bit confusing too. First, “fields section” do store things. Second, a form do not store stuff, it only sends information to the server. In that sens fields do not store anything either.

Perhaps I do not understand what do you mean by “storing”. Storing in the current page? “Saving”?

But really why using section for fields section and pages section. I think I miss a part there.

The section doesnt store anything at all. It’s mearly a container in which to put fields or display files or pages. Its the fields in that container that do the storing of data.

By storing, i mean something that would cause data to be written to a text file in the file system. Sections do not do this, only fields.

You can create a blueprint that does not use sections at all, just fields.

1 Like

The reason why there is a section for fields is basically only blueprint organization. Since when you have a section and want to include fields after the section, you cannot simply add a field, but then have to use a section to be able to include fields. It’s not ideal, but…

Technically, that’s true, but the result of sending data to the server from a field results in the field content gettings stored in the content file (or file meta data file). Whereas a pages section creates or deletes pages, a files section uploads, replaces or deletes files and an info section simply displays information.

Maybe we will remove the separation between fields and section one day, but for the time being, we have to live with it.

Ok, I get it. “Containers” is the right word :). I will mentally swap the word.