I’ve had a very limited chat with the dev of the oxyextras and zionextras plugin about expanding his offering to bricks.
In short he said he can’t because the API is limited.
So this topic is about what has been done or can be done to ensure the API is more dev friendly?
I do think expand it will be beneficial to bricks i the long term for devs and customers, because you’ll have more devs creating products to support bricks, and in turn you’ll get more sales when customers see a well integrated system.
@ribenawrath That’s actually what we are doing right now with the “Nesting element” feature and the improved HTML structure.
If I remember correctly David Brown (the dev of those two plugins) mentioned the missing element nesting possibility as the main reason why there is no BricksExtras plugin.
Maybe you could ping David and ask if he could share some more details here about the limitations of the Bricks API!?
I just first wanted to clarify the context of saying the API is more limited, which I know has been quoted a lot and has been my stock reply when being asked (I’m asked multiple times a week at this point) but it’s really just my reply to the question of ‘why after building OxyExtras did you go to create ZionExtras and not also create a BricksExtras, when there was clearly a fair amount of users asking me to create both?’
So (before I’m quoted again ) This wasn’t me making any sort of objective statement of the builder, outside of that specific context nor complaining in any way (or trashing the builder ). It’s just specifically about the reason I didn’t go in that direction a few months back and it’s just the most honest answer to that question (that I can give without going into technical detail). In short, I knew what would be mostly requested/expected and it just wasn’t going to happen in Bricks at that point.
But if it helps, I’ll list out what I wrote in my notes when comparing the APIs, where I had concerns or saw limitations compared to ZionBuilder. I understand that Zion Builder / Oxygen may be seen as a direct competitors to an extent, so sorry for the mention/comparison, but if people keep asking then maybe it’s helpful…
No class styling (I’m aware this isn’t the case anymore)
Flat structure to elements, no way to nest elements inside elements (I’m now aware this is being addressed in a future update). Probably the most obvious limitation, but in short there’s no point building a carousel / timeline / offcanvas / readmore etc components if users can’t put anything inside of them.
Didn’t seem to be a way to build Vue components for the builder if needing to allow the user to use dynamic data, everything needed to be PHP from what I saw. (using dynamic data is always requested). The concern being in-builder performance if there’s lots of components, ideally all would be vue.
The style tab with all CSS properties I saw can only be applied to one child selector per element, instead of multiple. The concern is the user will always have a limitation of which parts they can change/style without using custom CSS. This is actually a limitation in Oxygen also, which means I regularly need to give people custom CSS in support when they’re attempting to style anything outside of the common style controls (and there’s often dissatisfaction where the user expects to be able to do everything from the UI, no matter how unique the style request). This was already solved in Zion where the user always has full control of styling for all parts of each element.
The conditions on the element controls only seemed to hide the control, but the setting were still applied. The concern being that it would make it very easy for users to be confused and need support where there may be hidden controls that are still affecting the behaviour of the component or still adding certain CSS (with no visible way to remove it)
Any changes in settings caused the element to need to be re-rendered in the builder to be applied. Compare with this Zion where we have finer control over in-builder performance, by using the Vue lifecycle hooks and have a simple way to control exactly how the builder reacts to specific control changes. Eg if we’re creating a slider where the user could have lots of elements inside, images etc. Changing one setting, we may only want the tiny bit of JS that is needed to apply the new setting to run to see the changes, we wouldn’t want the entire structure and all the elements inside to be rebuilt each time a setting is changed. (I’m aware this may already be addressed when creating the nestable feature, but this is the concern, also creating a Vue version of the component if allowed to use dynamic data may solve).
No way to allow users to add classes or attributes to inner parts of elements, such as the individual divs/icon inside that would make up the structure of the element. Again, this is also a limitation of Oxygen, but Zion had already solved it. (Oxygen users are often frustrated by not being able to use utility classes on inner parts of elements that have built-in structure, for eg trying to add a box-shadow utility class on an icon inside of an alert box, or trying to add better accessibility where they need access to the attributes that are inside of the element for their specific use case).
(this one i may have incorrect as it was a while ago i checked) but I didn’t find a built-in way to add controls that would affect other elements on the page. for eg if we wanted to make element floating effect, it would need to be it’s own element rather than just being allowed to apply to any/all elements. Then we’d hit the same limitations as above reg styling etc.
I may have forgotten something (and perhaps could be incorrect in places, I could have easily missed something or maybe has been changed since, so sorry about that if so)
There are likely developers working daily with Bricks who will have better insight here than me and could provide more valuable feedback. Maybe already using the API. I’m really only commenting here as I’m asked about it so much, but apart from my initial investigation and digging in a couple of times, I haven’t been following it too closely. I was going to take another look if/when the nesting elements is made possible as that was the main sticking point.
edit - just reading this back and I’m aware it sounds very negative , so just adding in that obviously, i’m only mentioning here what I considered the negatives, not the positives, as that’s the topic of the post, to suggest possible changes to the API. Overall I like Bricks and it would be nice to be able to create different types of elements that people would find useful.
Thanks so much for such a detailed reply, David! I’ve been curious for more details on why you explored Zion (beyond just the flat structure) and this was great.
No doubt @thomas will address this in a future update and I’ll be stoked to have BricksExtras, as many other people will
The API way to add default CSS for elements only when they’re used on a page ( using the enqueue_scripts() method )… it outputs all the CSS in the footer instead of in the header at the top of the page, so there’s always going to be FOUC (flash of unstyled content) when the page loads.
We can see it happening also in the built-in ‘image gallery’ element when the masonry option is chosen, all the isotope CSS is in the footer as it uses this same method to add the CSS.
and the improved HTML structure.
) This wasn’t me making any sort of objective statement of the builder, outside of that specific context nor complaining in any way (or trashing the builder 
). It’s just specifically about the reason I didn’t go in that direction a few months back and it’s just the most honest answer to that question (that I can give without going into technical detail). In short, I knew what would be mostly requested/expected and it just wasn’t going to happen in Bricks at that point.