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.
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
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
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.
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:
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
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ā¦
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.
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ā¦
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).
