Can the client do that themselves?
A drag-and-drop editor moves the developer's decisions out of the page and into the pieces people drag.
Somebody from the Magento community came by the office in April to show us Page Builder.
They opened a blank CMS page and dragged a row onto it. Then they dropped a banner into the row, typed a heading, picked a background image and hit save. They refreshed the storefront and there it was. The whole thing took about two minutes, and most of that was the image uploading.
One of the account managers asked, “So the client can do that themselves?” The answer was yes. You could watch the room do two different kinds of math. The account managers were counting all the small tickets that would never need to be tickets again. The developers were counting something else, and I was one of them.
Some assembly required
Page Builder came out with Magento Commerce 2.3.1 at the end of March. It’s in the paid edition only, so it’s on some of our clients’ stores and nowhere near the rest. It replaces the old editor on CMS pages and blocks with a stage you drag things onto. It comes with 16 kinds of things to drag. Rows, columns and tabs handle layout, and the rest are what you’d expect: text, headings, buttons, images, video, banners, sliders, a map, and a few that pull in blocks and products from elsewhere in the store.
Magento calls each of those a content type, and you can write your own. That’s what I’ve spent most of the last six weeks on.
Seventeen content types in a trench coat
The first client to get it wanted the strip that every store has somewhere near the top of its homepage. Three tiles, each with an icon, a short heading, a line of text and a link. Free shipping over $75, 30-day returns, that kind of thing.
You can build that out of the box. It’s a row of three columns, each holding an image, a heading, a text and a button. That’s 17 content types for one strip of the homepage, counting the column group Page Builder quietly wraps around the columns. Each one has its own settings panel with fields for margins, padding, a border, alignment and CSS classes.
It looked fine when I built it. Then the client’s team had a week with it on staging. One tile’s heading ended up 3px lower than the other two, because somebody had typed 13 into a margin where the others said 10.
Nobody did anything wrong. The field existed, it took a number, and the page did what the number said. I wrote about the same thing in 2016, when a hero image I’d optimized got replaced through a form built for exactly that. Page Builder is that form, for everything on the page.
Two templates, one tile
So I built a content type for the tile instead. It’s a small Magento module. Most of it is one XML file that tells Page Builder what the thing is called, where it goes in the panel, which templates draw it and which form edits it.
<type name="feature_tile"
label="Feature Tile"
menu_section="elements"
component="Magento_PageBuilder/js/content-type"
preview_component="Acme_FeatureTile/js/content-type/feature-tile/preview"
form="pagebuilder_feature_tile_form"
sortOrder="25"
translate="label">
<children default_policy="deny"/>
<parents default_policy="deny">
<parent name="column" policy="allow"/>
</parents>
<appearances>
<appearance name="default"
default="true"
preview_template="Acme_FeatureTile/content-type/feature-tile/default/preview"
master_template="Acme_FeatureTile/content-type/feature-tile/default/master"
reader="Magento_PageBuilder/js/master-format/read/configurable">
<elements>
<element name="main">
<attribute name="name" source="data-content-type"/>
<attribute name="appearance" source="data-appearance"/>
<css name="icon"/>
</element>
<element name="heading">
<html name="heading" converter="Magento_PageBuilder/js/converter/html/tag-escaper"/>
</element>
<element name="text">
<html name="text" converter="Magento_PageBuilder/js/converter/html/tag-escaper"/>
</element>
</elements>
</appearance>
</appearances>
</type>There are two templates, and it took me longer than I’d like to admit to understand why. Both are Knockout, like most of the Magento admin. The preview template is what the admin sees on the stage. The master template is what gets saved. When somebody hits save, Page Builder renders the master template and writes the HTML it produces into the page’s content, with a few data- attributes so it can read the page back in later. The storefront doesn’t run any of that. It prints the saved HTML. Only a few of the built-in types, like the slider and the tabs, get any JavaScript there.
Which means that when I fixed a class name in the master template the following week, nothing on the storefront changed. The tiles that already existed had been written out with the old markup. They’ll keep it until somebody opens that page in the admin, changes something and saves it. I spent most of an afternoon clearing caches before I worked that out, which I think counts as a Magento rite of passage.
Fewer fields
The settings on the built-in content types write inline styles. A margin somebody types in the admin ends up as a style attribute on the element, and nothing in my stylesheet short of !important gets past it.
So the tile’s form has four fields. An icon, picked from a list of the six the designer drew. A heading. A line of text. A link. No margins, no padding, no border and no color picker. The XML has no <style> lines at all, so a margin would have nowhere to be written even if one got in. The only class the tile gets is the icon’s. The spacing lives in the stylesheet, where it’s the same for every tile on every page. The colors come from the theme.
That turns out to be most of the job. The client really can do that themselves now. My part is deciding what “that” is, one form field at a time, and mostly by leaving fields out.
Who asked for fewer options?
I’m not sure where the line goes, for what it’s worth. The built-in banner has all those settings because somebody needed each one of them. Every field I leave out is a thing the client has to ask us for instead. My first version of the tile had no way to hide one on a phone, and a week later that was a ticket.
My guess is that the right fields are the ones the design can survive, and so far the only way I’ve found to learn which ones those are is to leave one out and wait. That’s slower than I’d like. It still beats finding out from a heading that’s 3px low.
Three content types in, I’ve somehow become the person people ask about Page Builder. Nobody decided that either. I built the first one, so the second question came to me, and so did the third. If you’ve built content types for an editor like this, I’d love to know where you ended up drawing the line, because I suspect I’m still drawing it too close to the stylesheet.