Choose from multiple field groups within a Structure Field

I would love to see a slightly more robust implementation of the structure field.

Namely the ability to select different types of field groups within structure and then reorder those groups instead only repeating the same field group.

This would allow you to choose a “Video Module” which might contain a [Title], [Vimeo url field] and [Description].
Choose a slide show module which might contain a [Title] and [Multi Image Select]

After adding these modules (field groups) you would be able to drag and drop reorder in the panel.

The example below is a plugin from a different CMS but I think the basic functionality of it could extend nicely to Kirby’s existing structure field.

Additionally, it would be great to be able to preview images selected in structure.

3 Likes

That doesn’t sound to me like the structure field so much anymore. You are more looking for kind of a page builder, I guess. Tho that would probably a nice idea for a field plugin

1 Like

I agree with @distantnative and it reminds of this topic: Add Explicit Support for Multi-Section Pages

I also think structure has a different, very specific goal.
Still, I like the idea of content “bricks”. This would make it easy to break free from the “content field prison”.
I guess it could be done with data from subpages but it would probably not be practical.

It also reminds me a bit of SirTrevor. Except they store everything in JSON, and the Kirby way would be to store things in Markdown just like structure does.

A extendable blocks field with a blueprint per “block”? I need to sleep on it, but I think I like that :smile:

A first thought what a blueprint could look like:

  builder:
    label: Page Builder
    type: builder
    sets:
      video:
        label: Video
        fields:
          title:
            label: Title
            type: text
          url:
            label: URL
            type: url
      slideshow:
        label: Slideshow
        fields:
          title:
            label: Title
            type: text
          images:
            label: Images
            type: select

(I’m not the biggest fan of calling it builder - but for the moment I didn’t find a better name)

2 Likes

I’m torn here. There are a lot of disadvantages to using actual pages as sections.
It can be confusing for the client.

I’m very familiar with the so called “content field prison” you’re talking about. It’s a common problem which is by no means exclusive to Kirby.

I currently have a structure field that contains a bunch of fields, basically ingredients to build modules.
Then I have radio buttons which connect to if statements to tell the template how to treat those fields and where to echo their information.

It’s a fragile system and not a solution that I’d feel comfortable putting in front of a client.

I like the way @Malvese is referring to it as an extendable “blocks” field. That seems like the right way to describe it.

A blueprint per block would be perfect for what I’m trying to do.

I agree, I don’t like the term builder as it implies that you might use it to make whatever you want. I see it more as a tool for including modules or content blocks within the main content area of a page.

The blueprint looks great.

I totally agree - if anything, this should be a plugin and not the default implementation of the structure field.

2 Likes

Interesting post…
I´m soon to release a plugin later this month… It´s a sort of page builder.
The basic Idea is to merge everything into one place, ( structure fields, pages, files ).
You get total freedom and controll. Through a tag field I can send/receive
pages and files from/to other pages, and they become ‘posts’ of that page. I can reorder, delete, hide, “make sticky”, change style, change content etc. directly… Everything is connected, so if I change the “tag” for a page that are connected to another it automatically update the connected page. This is very nice for big sites with deep linking, for example:

Site.com/football/England/premier-league/Manchester-united/Team/Players/Forwards/Wayne-Rooney

So you change on one place, and it updates the pages that are connected, then if you want to change style, reorder and so on… the appearance of the page on other pages , just visit the pages that are connected or create several appearances within the page and send them individually to other pages, or create an overall style rule for all connected pages(posts) and so on, and on…
For now I am working on the performance, It´s a lot of arrays to loop through… lol :grimacing:

A rough screen shoot:

What you all think ? Good, bad, crazy ?

1 Like

So I don´t have to go to “pages” or “files” to reorder/make visible/invisible/delete/upload.
I do it directly in the “structure field”…

I initially imagined these blocks defined outside of the page blueprint, so we could re-use them in multiple blueprints, but it’s most probably a heavy handed approach (I blame my Drupal background ;)).
I really like @distantnative’s take, it’s easy, close to the structure’s syntax, and if we need the same blocks in another blueprint we can simply copy and paste.

To me such “blocks” are basically groups of fields inside a container, that we can insert, remove, reorder at will. Blocks seem more powerful than structure items, more flexible (and practical for editors) than complex Kirbytext tags inserted in a textarea.

@A_Monkey This is what we called “data from subpages” in our posts above. While it’s an approach that works (and works right now, no need for a new field or plugin) it can seem quite abstract for editors.
Also you have to write the different pieces separately, then fetch them in a different page, which I think is not a natural way to write posts. It’s best used when the contents are modular and the bits can be used in isolation.

With the “blocks” idea everything is done on the same screen, and blocks are just a part of the whole “article”. They’re not meant to be displayed by themselves anywhere else, so it’s a different concept.

“and blocks are just a part of the whole “article””.
Well so are the pages linked to the “article”, they are also part of the whole “article” because they are displayed on the page/article on the front end. I´m giving the user the chance to see what the heck is going on… And the tools to take control of the content and flow…

You now see where your content is…
I have some sorting options and icons as well so you can quite easy were the pages belongs.
For instance:
Pages (children)
Post (every page that isn´t a child of the page)
Blocks (structure fields)
Files

"data from subpages"
Yes, the pages that are linked are data from subpages, but the thing is this, it´s “baked” in with the structure field, so if you hit the add button its a structure field displaying, if you hit a page that are a subpage, a structure field, with some different fields displaying. Then I just glue/yaml the whole mass together…

think I will have to do a screen cast… :weary:

I’m still thinking about the best way to do this…

Essentially I have a custom checkbox form field which is being used to separate fields into groups.
The checkbox is accessible to javascript but hidden from the user.

In javascript, I’m grabbing the Label of each custom checkbox and using those labels to build tabbed navigation at the top. Then, I’m dumping the fields in-between the custom check boxes into field groups which can be toggled on and off by the tabs above.

When a tab is selected, the invisible custom checkbox for that field group is given a value of 1, while the other checkboxes are set to 0.

In the template logic you could easily filter out what field group to display based on which tab was open.

I probably wont end up using tabs for this as it allows the user to switch between field groups after they fill in fields. What I want to do is force them to choose a module type after creating a new module and then only present the fields applicable to that module type. If they want a different module type, they can delete it and add a new one.

@A_Monkey how is your plugin coming?

2 Likes

What’s the blueprint for this?

Hi @iancox !
Well havan´t had the time…

Well I´m more of a front end monkey kind of guy, i´m sometimes struggles with the php stuff.
I have basically taken the structure field and modified it to get the files and pages(children) in there as well. I don´t even use the sidebar anymore, I have everything in one place. Make more sense to me, and perhaps to others… And you get more power to order things…

I probably have a complete working version within 2 weeks…

The biggest thing that I don´t like with the structure field is that is a “pop up / modal” or whatever you want to call it… It works for adding a page, link, file and so on, but not for adding rich content, and yeah you could style it so it don´t look like a “structure” field…but hey…

@bastianallgeier should really take a look at the ACF ( Advanced custom field for wordpress ),
thats the way to go for adding rich content…

What I suggest is this:

A ui draggable/reorder interface with accordion. ( Take inspiration from ACF, Advanced custom fields )
The user can then add different “sets” (suggested by @distantnative blueprint).

That´s the way, period !! ; )

The end.


It’s probably not ideal but it’s what I can manage to put together. :slight_smile:

  content:
    label: Modules
    type: structure
    entry: >
      {{postimage}}<br />
      {{imgtitle}}<br />
      <div style="width: 20px; height: 20px; display: inline-block; background-color:{{imgcolor}};"></div>{{imgcolor}}<br />
      {{name}}<br />
      {{email}}<br />
    fields:
      group1:
        label: Project Info
        type: modulegroup
      postimage:
        label: Main Post Image
        type:  selector
        mode:  single
        types:
            - image
      imgtitle:
        label: Image Title
        type: text
        width: 1/2
      imgcolor:
        label: Color
        type: color
        width: 1/2
      group2:
        label: Author
        type: modulegroup
      name:
        label: Name
        type: text
      email:
        label: Email
        type: email

Have a look at the builder plugin I am currently working on. I think it fits quite well to iancox’s original suggestions.

4 Likes