Why native?
Extend the Page Builder you have, rather than replacing it
A proprietary page builder asks you to move your content into its format and keep paying to read it back. A native content type writes the same markup Magento writes, in the same place, and leaves when you do.
The format is Magento’s, not ours
A plain <div data-content-type="wrizu_…"> with its settings in data-* attributes, stored with the page. No proprietary table, no shortcode, nothing to convert later.
One editor, the one your team knows
The same stage, the same preview, the same responsive controls and the same Advanced tab. New elements appear in the panel next to the native ones — there is nothing new to learn beyond the fields themselves.
Leaving costs nothing
Disable the module and the storefront keeps serving those pages: headings, copy, images, links and buttons stay visible, along with the styling you set per element. What goes is what our CSS draws.
Side by side
A proprietary page builder against a set of native content types, on the questions a shop owner ends up asking two years in.
| The question | A proprietary page builder | Wrizu — native content types |
|---|---|---|
| Where the content lives | Its own tables or its own serialised blob, read by its own renderer. | In the page, in the native master format, next to your native content. |
| If you remove it | The pages it built stop rendering, or render as shortcodes and markers. | The pages keep rendering. You lose our CSS — layouts, borders, button variants, icons. |
| The editor your team uses | A second editor beside the native one, with its own rules and its own habits. | The native Page Builder, with more elements in the panel. |
| Styling and the Advanced tab | Its own alignment, spacing and colour controls, parallel to Magento’s. | The native Advanced tab, written into a style block stored with the page. |
| Theme integration | Its own design system, which your theme then has to be talked out of. | Luma’s own button mixins; CSS scoped to [data-content-type^="wrizu_"]. |
| Migrating away | An export, a conversion, and a proofread of every page. | Nothing to migrate — the content is already in Magento’s format. |
The other side
What a proprietary builder does better
A full page builder replaces the layout engine as well as the elements, so it can offer things a set of content types cannot: free-form positioning, its own grid, global design tokens applied across every page, and a library of ready-made section templates.
If that is the shop you are building, buy one of those instead — and go in knowing that the content will be written in its format for as long as you keep it.
One honest warning about ours
With the module switched off, do not open and save a page that contains Wrizu elements — Page Builder flattens any page holding a content type it does not know into a single HTML Code block, and that save cannot be undone.
It behaves that way with every unknown content type, not only with ours, and the storefront is unaffected either way. The rule is to leave those pages alone until the module is back on.