Block 6 gave the module a complete, accessible frontend - but exclusively on its own pages, controlled by the router from chapter 46. But what if a marketing colleague wants to put the points balance, or a promotional message about the program, on an ordinary CMS page, without asking a developer for a new layout XML file? That's exactly what widgets are for - and, starting chapter 58, Page Builder. Both are block 7's subject.

What is a widget?

A widget is admin-configurable output that can be inserted into any WYSIWYG content: CMS pages, CMS blocks, product and category descriptions - anywhere Magento offers a WYSIWYG editor with an "Insert Widget" button. Two independent insertion paths lead to the same result:

• Inline directive: {{widget type="..." param="value"}} ends up as literal text in the WYSIWYG field, inserted via the "Insert Widget" button. No separate record - the widget lives only as text inside that one piece of content.
• Widget instance: created under Content > Elements > Widgets in the admin, permanently binds a widget to specific layout handles, containers, and store views - it never shows up as text in the WYSIWYG field, but generates its own layout XML update internally.

Both paths end up instantiating the same PHP class with the same admin-entered parameters - the difference is only WHERE the widget ends up and how it gets there.

A widget is not an alternative to a view model

Chapter 47 treated block vs. view model as a question of template data supply for developer-controlled pages. A widget answers a different question: "how does someone WITHOUT developer access - an editor, a marketing colleague - get controlled access to my code without writing a single line of layout XML?" Both questions are orthogonal, not competing.

A widget's three parts

1. etc/widget.xml - registration: ID, block class, label, description, and the admin-editable parameters (chapter 57).
2. A block class implementing \Magento\Widget\Block\BlockInterface - the actual rendering (chapter 56 builds this module's first one).
3. A .phtml template - technically identical to any other block template in this series.

<?xml version="1.0"?>
<widgets xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Widget:etc/widget.xsd">
    <widget id="vendor_module_widget_id"
            class="Vendor\Module\Block\Widget\SomeWidget"
            is_email_compatible="false">
        <label translate="true">Widget Label</label>
        <description translate="true">Widget Description</description>
        <parameters>
            <!-- see chapter 57 for real parameter declarations -->
        </parameters>
    </widget>
</widgets>

Where widgets technically hook in

Magento\Widget\Model\Template\Filter recognizes the {{widget}} directive and instantiates the configured class whenever WYSIWYG content passes through Magento's filter chain - the same chain that also resolves {{trans}} and {{config path=""}} directives, and applies equally to CMS pages, CMS blocks, and product/category descriptions.