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.
@Matej This is pretty similar to one of my requests made on the idea board. I think the mechanism by which this can be achieved would be analogous to Gutenbergās InnerBlock. Have an element that becomes an insertion point. At the point of insertion you select which components are allowed for selection. You can then move this insert point element anywhere within the component, have multiple of them, and have them nested. For the editor the insertion point would present a plus button which provides the list of allowed components for insertion.
Did you ever think about using a Custom Post Type and splitting data from the design? Speaker could be a Custom Post type, the client can add and remove speakers without the chance of breaking the UI. You donāt need to secure every page from the client and lock it down.
All this is available right now and works like a charm.
For the event details the client can use Gutenberg to create the content and add text and a nested list there. I provide exactly the same functionality as you describe without the client even knowing which builder I use and they wouldnāt even notice, when I switch builders. And never need to learn using my favourite builder.
My company arranges meetings once a year. So thereās +1 page every year that has different speakers and different program. But itās not even the main reason why ACF is not an option for me. You can set āyearā field in ACF and get away with it. The main problem that program is always different and thereās speakers all over the place. I canāt just query them in one place. There could be a āsubjectā and a speaker or 2 speakers. Or it could be discussion section with several speakers. Content manager should be able to drag them all over the place and create all kind of nonsense from blocks that I provided for him originally (he uses copy-paste a lot). I would love to make this easier for him and lock most of things that he donāt need, but I canāt for now.
I consider myself one of the lucky ones - I work with content manager who understands builder basics. But when youāre freelancing itās a big pain. You done the project, you pass it to a client, then you have to explain to a client how to edit it, what he can touch and what he shouldnāt touch. And then he will break things anyway. Especially in Bricks because we have ānested widgetsā where you drag something wrong and it breaks.
Addition to the main subject. Turns out thereās a module in Advanced Themer called Strict Editor View. But I donāt want to use it because I donāt want Advanced Themer. Iām into KISS principle and Advanced Themer is oposite of that. Also itās +1 plugin. Also itās a Bricks plugin that can break some things in Bricks. I got Fancy Animations plugin for Bricks. I tried it once and it broke Bricks for me. I get some console errors often and Bricks stops to update preview. So, Iām very cautious about third-party plugins for Bricks and I would love to have some kind of āeasy modeā out of the box.
