Home → Plugins → A custom Bricks Builder element
A plugin can reach Bricks in two ways: as a shortcode dropped into a container, or as its own element that sits in the list next to the built-in ones with a settings panel of its own. The first is quicker to build, the second is easier on whoever assembles the pages afterwards. These are notes from the second — from the element we wrote for our store locator.
It sits in the elements list with its own name, icon and category — found the same way as a button or a slider, with no trip to the documentation.
It has a real settings panel instead of attributes typed from memory. Selects, toggles, sliders — all with hints and validation.
It draws on the canvas straight away. Changing a setting redraws the preview, so the result is visible on every click rather than after a save and a reload.
A typo cannot break it. A closed list of options instead of a text field where one stray dot ruins the shortcode.
The starting point is documented: the Bricks Academy has an article, Create Your Own Elements, with a ready class skeleton, the list of properties and methods, and how to register the element. The rest comes from reading the theme’s code and checking things in a running builder — that is where the documentation stops and the details begin, the ones that decide whether the element survives a redraw.
The skeleton comes together from the Academy article in one evening. The three things below are not described there, and they are what decides whether the element works in practice.
This is where elements like this usually die. For an element whose markup PHP builds, a setting change sends a request to the server and drops fresh HTML onto the canvas — a new node. A Leaflet map bound to the previous one does not travel with it, leaving a dead rectangle behind. Bricks does call the element’s start-up function afterwards, but with a short delay and only once the node is in place. So that function has to sweep the page and re-bind rather than assume one run is enough.
The documentation lists it among the front-end methods, and it loads assets on pages where the element appears. In practice the builder calls it too — when the preview frame opens and on every redraw. So the method has to know where it was called from; otherwise either visitors get things needed only in the editor, or the editor gets nothing at all.
All thirteen controls state explicitly that a change should redraw the element. Honestly: that is not what makes the preview refresh — Bricks does that by default. It is insurance against a control later gaining a CSS property, and against the default changing. One line per control, fewer surprises at the next update.
The suite guards the code and passes in full. It caught none of the three below.
An element that vanishes without a trace. On a page rendered from a Bricks content template it did not appear at all — no HTML, no PHP error, nothing in the console. There is nothing to search for until you open such a page.
Dead controls with a fully passing suite. Four fields in the panel did nothing while every test stayed green. A test checks that a control is declared — not that clicking it makes something happen. That is why a manual check list is part of the release plan rather than a good intention.
The version the site actually runs. Bricks version numbers can differ between the copy you read and the one everything has to work on. Until the element has been opened in that particular builder, every sentence about it is a guess — and we treat it as one.
If your feature ships as a shortcode today and whoever builds the pages has to remember its attributes, this is exactly that case. Tell us what it should do and we will say what it takes.
Tell us what it should do →Or by e-mail: info@asymetria.com.pl