Frontend Widgets
Frontend widgets are registered public components that Capell can render in normal content, lazy interaction targets, and package-owned experiences. A widget definition answers four questions:
| Question | Defined by |
|---|---|
| Which widget key can editors choose? | LayoutWidgetDefinitionData::$key |
| Which Blade/Livewire component renders it? | LayoutWidgetDefinitionData::$component and target |
| Which frontend assets does it need? | resourceGroups |
| How should it present, load, and expose interactions by default? | defaultPresentationSettings and defaultInteractionTriggers |
Content Sections and Layout Builder use this same surface for editor-managed content. The registry lives in the core/frontend boundary so packages can ship reusable widget targets without inventing their own modal systems, asset loaders, or public routes.
In This Section
Section titled “In This Section”| Task | Read |
|---|---|
| Register a widget and load its CSS/JS | Widget registration |
| Set instance, presentation, and loading state | Widget state |
| Open a widget or fragment from an interaction | Widget and fragment targets |
| Register Inertia widgets | Inertia widgets |
Widget HTML and interaction placeholders must never expose admin controls, model IDs, field paths, block keys, component names, package namespaces, signed URLs, or raw target widget data. Widget and fragment targets lists the full rule.
When a widget defers below-the-fold HTML, prepare a DeferredFragmentPlaceholderData value in PHP and render only that value in Blade. Build references with PublicFragmentReferenceCodec and route them through the registered PublicFragmentUrlResolver owner; route names and owner-specific authorization remain with the application or package that serves the fragment.