Publishing and rendering

Draft and publish behaviour

Every edit in the editor writes immediately to a page's draft state - there's no separate save step. Draft edits never affect what's publicly rendered until you explicitly publish.

Publishing resolves every block's fully-resolved effective settings (defaults merged with your overrides) and snapshots them into a new revision. A later change to a block's own constructor default can never silently alter an already-published revision, because the snapshot is self-contained. Publishing is blocked while a page violates its Page Definition.

Revisions and restore

Every publish creates a new, immutable revision. The editor's version history lists them.

Restoring one always replaces the page's live draft sections with that revision's snapshot; whether that's also an immediate publish depends on whether the restored content satisfies the page's current Page Definition, which can have changed since that revision was published. If it does, restoring publishes a new revision from it (labeled Restored from revision #N). If it doesn't, the content lands in the draft only, and publishing stays blocked until it's corrected. See The editor for the UI workflow.

Embedded rendering

Render a Page's latest published revision from a route your own application already owns, with Inlay::renderPage() or the <x-inlay::render> Blade component:

// A route or controller your application already owns
Route::get('/{page:path}', function (\WeArePixel\Inlay\Models\Page $page) {
    return view('pages.show', ['page' => $page]);
});

{{-- resources/views/pages/show.blade.php --}}
<x-app-layout>
    <x-inlay::render :page="$page" :context="['collection' => $collection ?? null]" />
</x-app-layout>

Use this style when a Page needs data or context your route already has - the current tenant, a resolved model, an A/B test bucket - that Inlay's own routing has no way to supply.

$context is optional, host-supplied data with no schema Inlay understands - merged underneath each block's own resolved settings, so a block whose own Blade view declares a matching property picks it up the same way it already picks up an ordinary container-resolvable dependency. Inlay never inspects or validates it.

A page with no published revision renders nothing - there's no draft leakage onto a public route.

Frontend styling neutrality

The package owns composition; your application owns presentation, completely. Inlay never loads Tailwind, Bootstrap, or any CSS framework into your public pages - <x-inlay::render> and Inlay::pageRoutes() both output exactly what your own block views render, in whatever styling system your application already uses. The admin's own design (loaded only under Inlay::adminRoutes()'s prefix) is entirely separate, self-hosted, and never touches your public output.

Nested Livewire on a real page

The same rule covered in Registering blocks applies identically here: it's just Blade, so a block containing <livewire:contact-form /> mounts and hydrates with zero special handling whether it's rendered by the admin's preview or by <x-inlay::render> on a real page.