This piece is stitched together from a handful of videos I made between 2021 and 2023, back when I was deep in Magento day to day. The versions on screen were Magento 2.4.x, and the screens have moved on a bit since, but the ideas have not. If you run a Magento store, Page Builder, CMS blocks and widgets are still three of the most useful tools you have for putting content on a page without redeploying the whole site. Here is how I actually used them, and why all three eventually pushed me toward building my own CMS instead.

Page Builder is the bit clients can actually touch

Page Builder is the drag and drop editor that ships with Magento for CMS pages and blocks. The reason I rated it was simple: it let a non technical client edit a landing page without breaking the theme, and it let me hand work off cleanly. On one build my junior dev at the time, Mitch, would create a block in the admin with Page Builder, export the generated code, and paste it straight into an upgrade data script. When I pulled his branch the finished block dropped into my admin without me logging in or rebuilding anything. For team work that is genuinely handy.

One thing worth saying out loud: Page Builder is an add on for content, not a prerequisite for upgrade scripts. You can put any content into a setup script. Page Builder just made the handoff between people tidy.

CMS blocks: small reusable lumps of content

A CMS block is a named, reusable bit of content you manage in the admin and drop wherever you need it. The classic example I used was a global delivery message, something like free delivery on orders over fifty pounds, that needed to appear in several places. Rather than hard code it, you create one block and reference it.

To place one on the product page you work in layout XML. The layout that controls almost the whole product page is catalog_product_view. I always tell beginners how I know that: look in the core. Go to the Magento catalog module, into view then layout, and you can read the handles Magento itself uses. The key habit is that you reference an existing container rather than creating a new one. For a static block you do not need to wrap it in a fresh container at all. You point a block at Magento\\Cms\\Block\\Block, pass it the block_id as an argument, and drop it into a position like page.top. No extra template needed for the simple case.

There is a second, more long winded way using a template file and a Magento\\Framework\\View\\Element call, and it works, but for a plain static block it is more moving parts than the job needs. Keep it in layout where you can.

Extending Page Builder when the defaults fall short

The honest limitation of Page Builder is that the stock components do not always give you the fields you want. The one that bit me was the image component. It had no field for an explicit width and height, and Lighthouse flags images without those because layout shift hurts your score, on mobile especially where you might want a different size.

Magento gives you a scaffolding command for this. From your app/code directory you run the npx Page Builder generator, pick whether you are adding a brand new component or extending an existing one, and it writes a module skeleton for you. To add width and height to the image component you extend it, then edit the files it generates:

• The XML that declares the component and your new fields.
• The form, which is the UI component shown in the admin where the editor types the values.
• The master template, which is what actually renders on the front end, plus the preview template if you want the field reflected in the admin preview too.

The trick, as ever with Magento, is knowing where to copy from. The core Page Builder module ships the definitions for every default component, so I crib from those rather than fighting the thin official docs. Add the fields for desktop, then repeat for mobile, and your images finally carry explicit dimensions.

Widgets: the underrated one

Widgets are the tool I think most people overlook. Magento ships with a set of default widget types, and if you install the sample data you get even more to experiment with. The standout is the product list widget. You can drop an on sale block onto every page by setting a condition like special price greater than zero, choosing the store view, and picking where it appears, all without writing a line of code. It inherits your product grid styling, so once your theme is styled the widget looks right automatically.

For more control you build a custom widget inside a module, which lets you expose your own parameters that a content editor can set in the admin. A useful real example is a newsletter signup widget combined with a static block, so the copy lives in a block the client can edit while the widget handles placement and parameters. If you build modules regularly, get the Magento Wizard editor extension; it scaffolds the boilerplate so you are not hand typing the same files every time.

Why all of this pushed me toward my own CMS

Here is the opinion the three videos add up to. Page Builder, blocks and widgets are good tools, but look at how much Magento knowledge you need just to put a width on an image or a signup form in the right place. Layout XML, UI components, scaffolding commands, copying from core because the docs are thin. That is a lot of platform tax for content editing, and most of my clients did not need a full commerce engine sitting under it.

That gap is exactly why I moved off Magento and eventually built my own headless CMS, where editing a block is just editing a block. If you want the longer version of that decision, I wrote it up in why I moved from Magento to headless. None of this means Magento's content tools are bad. They are not. It means they are built for a heavier world than a lot of sites actually live in now.