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 component's fully-resolved effective settings (defaults merged with your overrides) and snapshots them into a new revision. A later change to a component's own constructor default can never silently alter an already-published revision, because the snapshot is self-contained.
Revisions and restore
Every publish creates a new, immutable revision. The editor's version history lists them; restoring one replaces the page's live draft sections with that revision's snapshot and immediately publishes a new revision from it (labeled Restored from revision #N) - restoring is itself a publish, not a draft-only operation. See The editor for the UI workflow.
Public routes
Inlay registers no public-facing routes of its own. Where and how a page's content appears on your site - /{slug}, /blog/{slug}, a controller, whatever your application already does - is entirely up to you. Composition is the package's job; your application owns its own URL structure and presentation.
Rendering a page
Render a page's latest published revision from your own route or controller with the <x-inlay::render> Blade component:
// A route or controller your application already owns
Route::get('/{page:slug}', 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" />
</x-app-layout>
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> outputs exactly what your own component views render, in whatever styling system your application already uses. The admin's own design (loaded only under Inlay::routes()'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 components applies identically here: it's just Blade, so a component 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.