As developers we have always tried to limit the amount of opportunity our clients have to break things on the sites we build.
When we build with Elementor, we use a plugin we created to add “skins” to any of the elements in the builder. This essentially creates a <select> containing a list of available skins on the element’s inspector panel. On the page, this translates to having a CSS class dynamically added to the element.
We are able to replicate this in Bricks by adding custom controls of course, but the problem lies in the editor – Many (if not all) of the Bricks elements do not respect these custom attributes or settings when inside the editor.
So let’s say you chose the “Hero” skin on the “Container” element: something like ‘skin-hero’ would be added to the class list of the element, both in the builder and in the front end.
Bricks has filters like set_root_attributes which would be perfect for this job, and in fact work perfectly right now – but only on the front end.
Can anyone think of a workaround to achieve what we want to do here?
We realize that we can simply use global class names and lock the classes, but it’s not quite as elegant of a solution as what we would like to implement.