The problem:
When you create a website for a client, they usually have zero clue how to work with the editor. They will probably break something on their site while trying to edit some content. Back in the early days, we prevented this by hardcoding templates and letting the user edit only parts we wanted. Some CMSs are even designed this way now. But with full-page visual editors, it’s a problem that components can fix.
Current situation:
I tried components, and for now, you can use them in 2 ways:
Replace some repetitive parts. This is what you designed components for, I assume.
Replace every section in the structure with a component. When the client tries to edit a page, this approach will open “easy mode” for him at first. And this is what I want to achieve for my clients. But there’s a restriction now – you can’t use 1 and 2 together.
The solution:
Allow components to be placed inside other components. For example, I have a section with heading, description, and bunch of speakers. Speakers are repetitive parts that I want to place inside a component. But I also want to move the entire section inside a component to create that “easy mode” for a client, where he can edit only the header and description.
After that step 1, I want client to be able to move, duplicate, and edit speakers inside the “section component”. For now, he can do this only by editing the “section component”, but that means he have to leave that flat “easy mode”. So this approach needs another mechanism. Let’s say you can set a new property in a component – “container for components”. You can add bunch of these in root component and set for each of them what kind of components can be placed inside. And then user can’t move, edit, delete, or duplicate the container itself, he can only move, edit, delete or dublicate components inside. I assume this is how it could look in the structure: https://i.imgur.com/bk4QG21.png
Finnaly, step 2 leads us to this. Add a permission setting to restrict some users from editing components. For example, we have a “content manager” in a team who has a “writer” role on a site and zero skills with page builders. I want him to use Bricks only in “easy mode” – edit only the properties of components, move components inside root components, duplicate them, and edit their properties as well.
New setting - “local” or “global” components. Some components shoud be reusable on other pages and some not. Same goes for classes and variables. I think we need an option to chose - do we need this element on other pages or not. And possibility to change this option in the future.
Maybe there’s easier way to achieve everything I just described, but this is how I see “easy mode” possible with components.
@sinanisler I did. It’s not how I imagine “easy mode” would work. If you set “edit content” to Editor role, he can only edit, that’s fine. But he can’t move speakers, he can’t dublicate them to add another one. I could probably fix this with ACF, but then we’re backing off from “full page editing” into “try to find out how to edit this part of a page” approach again. I don’t like where this is going. For example, we have “program” page with 4 types of different blocks. Editor should be able to copy-paste them to add new block in program. So I’ll have to use ACF to let editor choose from 4 types of block and set 4 types of fields to fill. That’s a mess imo.
Also, Editor can see full structure of the page inside Bricks. It’s overloaded and there’s a lot of things he doesn’t need to see. But if I could place whole sections into components, then editor would see only important stuff that he should edit / move / dublicate. It’s more like a Concrete5 approach. But with Concrete5 you have to hardcode your theme to set “parts where editor can add widgets”. WIth Bricks you don’t have to hardcode anything.
P.S. For everyone who just heard about Concrete5 and started google it - I do not recommend you to use this CMS. It’s very capricious, especially when updating. It broke on me several times with no obvious reasons. You have to be proper developer to actually maintain it.
thank you for your suggestion! I think your use case is really interesting and it makes sense! But to sum it up, so that I don’t miss anything, all we would need is:
Allow to have nested components
Add additional permissions, so that we can restrict users from editing a component in certain ways.
That would be it, right? Just so that I can property record it
Thanks!
In my example Editor should be abble to dublicate, move and edit speakers somehow (components inside component): https://i.imgur.com/bk4QG21.png
I described how to make this editable “the easy way” in first post → the solution → step 2. I think my solution will be hard to implement, so maybe you’ll have better idea.
Here’s another example that we often use on our sites - program: https://i.imgur.com/kqv8wvd.png
I can break this down to components, but “editor guy” cooks the program. He should be able to dublicate, move and edit those components to add more content to the program.
I’m also fully in support of this idea - components already have huge potential but being able to nest them and expose only what we need to clients would be a total game changer.
