Widget vs. Page Builder Content Type: When to Use Which
Widget vs. Page Builder Content Type: When to Use Which
~6 Min. Lesezeit Zuletzt aktualisiert am August 9, 2026
Block 7 built two genuinely editor-usable building blocks: a widget with live, up-to-date customer data (chapters 55-57) and a Page Builder content type with frozen, editorial content (chapters 58-60). This chapter makes the trade-off explicit.
Side by side
- Data freshness: widget - live, fresh on every request (chapter 56). Content type - frozen at save time (chapter 58).
- Admin audience: widget - a developer-defined parameter form, inserted via the "Insert Widget" button or a widget instance (chapter 57). Content type - full drag-and-drop with instant WYSIWYG live preview (chapter 60).
- Code investment: widget - one block class, one widget.xml, one template (chapters 56/57). Content type - one block class, one content_type.xml, an admin form, a knockout preview component, two templates (chapters 59/60) - noticeably more.
- Caching: widget - caution with full page cache on public, cacheable pages (chapter 56). Content type - generally uncritical, since the HTML was already frozen at save time, before full page cache even gets involved.
- Where it can go: widget - anywhere with a WYSIWYG editor, including transactional emails when
is_email_compatible="true"(chapter 55). Content type - exclusively inside a Page Builder stage (CMS pages/blocks with Page Builder enabled).
The third option: embedding a widget inside Page Builder
Chapter 58 already mentioned that core content types like the embedded CMS block or the product tile resolve exactly this tension themselves by making their master format nothing but a {{widget}} placeholder directive. Nothing stops an editor from using the same trick manually: Page Builder's own built-in "Widget" content type lets PointsBalanceWidget from chapter 56 be dragged directly onto a Page Builder page - drag-and-drop placement AND live customer data at the same time, with not a single new line of code. The custom "Points Banner" content type from chapter 59 deliberately did NOT use this trick (see its warning) - keeping both building blocks conceptually clean and each honest about its own limits.
Recommendation for this module
- "My Points" (personal account balance) → the widget from chapter 56, either on the already non-cacheable account page (chapter 52, uncritical) or - keeping chapter 56's full page cache caveat in mind - via Page Builder's built-in widget content type on an otherwise public landing page.
- Promotional messaging about the program itself ("Earn points on every order!") → the custom Points Banner content type from chapter 59, freely placeable by editors on any landing page, cheap to cache, with no session-state concerns whatsoever.
Tipp: That wraps up block 7: a widget with full logic reuse from block 6 (chapters 55-57), a custom, honestly static Page Builder content type (chapters 58-60), and this explicit decision guide. Block 8 turns to custom payment and shipping methods next - and runs into the same pattern from chapters 47/56/59 there too: a base class dictated by the respective checkout core module, which is no excuse for duplicated business logic there either.