Skip to main content

Laravel CMS Layout Builder

LayoutBuilder detail

Page building with developer guardrails.

Editors compose approved rows, columns, widgets, and reusable sections while developers keep the rendering contract.

Page composition

What editors can change, and what stays protected.

LayoutBuilder shows how reusable sections, guarded widgets, preview states, field contracts, and package-owned blocks work without leaking admin concerns into public output.

Example: a reusable campaign CTA can expose title, copy, media, destination, tone, and spacing density while the Blade view still owns markup, accessibility, responsive behaviour, and brand rules. That is the difference between useful visual editing and a page builder that quietly breaks design integrity.

Canvas

Approved layout regions

Rows, columns, and containers are explicit records, not loose page markup.

Containers
Hero / Main / Workflow
Rules
Typed
Output
Project view
Variants

Block variants without template edits

A feature block can switch between grid, split-media, bento, or detail layouts from CMS metadata.

Grid Bento Split media
Fields

Field contracts stay visible

Editors see labels and help text; developers keep validation, defaults, and rendering boundaries in code.

  • Title and summary
  • CTA route or URL
  • Screenshot key
  • Optional detail copy
Preview

Check mobile, desktop, and dark mode before publish

A useful builder has preview states, not just a saved form.

Desktop Mobile Dark
Schema

Sections map to stable records

Page, section, element, asset, and translation records keep the layout inspectable. 

page -> layout -> container -> element -> section
Renderer

Frontend output remains in the project

LayoutBuilder supplies structured data while Blade, Livewire, cached HTML, or a custom renderer controls the public surface.

How it works

This is where Capell avoids becoming a visual site builder. It gives editors composition within approved boundaries and leaves the frontend implementation in Laravel.

Reusable

Sections can repeat safely.

A proof block, package card, CTA, media row, or comparison panel can be reused without copying template code.

Example : Sections can repeat safely.

The same section can appear on several pages while still keeping its content in structured fields. That makes repeated proof points, package highlights, customer quotes, and campaign CTAs easier to update without asking developers to hunt through Blade partials.

See collections
Guarded

Blocks can expose settings without exposing markup.

Variant, density, media position, CTA style, and visibility can be controlled as fields.

Why this matters : Blocks can expose settings without exposing markup.

The useful boundary is not no control versus total control. Developers decide which settings are safe for editors, then render those settings through tested views so spacing, accessibility, responsive behaviour, and brand rules stay intact.

Extension points
Inspectable

Every layout decision has a record.

That makes migration, testing, review, and rollback easier than interpreting page HTML.

Operational detail : Every layout decision has a record.

When a section is a record, a maintainer can see who changed it, which page uses it, which package registered it, what fields drive the output, and how to recreate or roll back the public result.

Publishing path
Next

Keep learning through the pieces LayoutBuilder touches.

Open collections Content collections See the reusable records that LayoutBuilder can place on pages. Continue Open workflow Publishing workflow Follow a layout change from edit to preview, approval, and publish. Continue Open packages Package extensions See how packages can add widgets and fields without bloating core. Continue