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.
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.
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…