Nova Page Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for the page/CMS layer — the core decision. This package collapses "how do we build a page editor?" into a composer require: a Nova-native Page resource with slug and parent handling, draft/published states with scheduling, configurable page templates, reusable regions, flexible content blocks, per-locale fields, and basic SEO metadata. The real question it answers is not "build or buy a CMS" but "what, if anything, is genuinely proprietary about how we manage marketing content?" For brochure and campaign pages, the honest answer is usually nothing.
• Roadmap sequencing: unblock marketing pages without committing a quarter. If the roadmap contains landing pages, campaign microsites, product pages, or a recurring request that "editors need to change copy without a deploy," this ships in days and defers the heavier CMS evaluation to a quarter where you have real editorial demand data to justify it. Treat it as a way to buy information about whether editors actually need more than templates, blocks, and regions.
• Content-modeling strategy: guardrails vs. free-form. Templates, block types, and regions are declared in PHP/config — editors assemble pages from an approved kit and cannot invent new structures. That is a deliberate product constraint: every content shape is code-reviewed, versioned, and deployed through the normal pipeline. Choose this explicitly when you want editorial freedom within limits, not a free-form page builder. It also means "add a new block type" is a sprint item, not an afternoon of an editor's time — price that into the operating model.
• Localization cost estimate. Per-locale page content comes largely for free, which materially changes the business case for "launch in a second market" and lets you scope i18n as an incremental content effort rather than a platform project. Be honest about the caveat: fallback behavior must be decided deliberately, or you ship pages that look published and render empty.
• Scope boundary: content management, not experience delivery. The package deliberately does not route or render. That means routing, layouts, block partials, cache invalidation, preview, and 404 behavior are our product scope. Budget for it explicitly — this is a dependency that removes the admin UI, not the feature work.
• Operating-model decisions. Single maintainer, 179 stars, near-zero dependents, and tight coupling to Nova's major version. That doesn't disqualify it, but it makes "pin the version, keep a content export command current, and keep block partials free of package-specific calls" a standing commitment rather than a nice-to-have. The exit ramp is real only if we maintain it.
• Reference spec for an in-house build or paid CMS evaluation, even if we don't adopt it. Templates, blocks, regions, drafts/preview, slugs and parents, SEO meta is a credible minimum-viable feature checklist for scoping a build or comparing vendors.

When to Consider This Package

Consider it when most of these are true:

• You are already on Laravel and licensed for Laravel Nova. Effectively a hard gate — this is a Nova tool, not a standalone CMS, and the Nova license is a real per-project cost. Teams without Nova should not adopt it to get this package.
• Content surface is small-to-mid. Tens to low hundreds of pages, a handful of editors, a few locales. Marketing sites, product and campaign pages — not a publishing operation with complex workflows, editorial roles, or high-volume authoring.
• Your team will own PHP. Page templates and block types are code, one Blade partial per block. If nobody wants to maintain a component per block type, this will feel like a worse WordPress.
• You want self-hosted, MIT-licensed, no per-seat fees. Strong fit for agencies and cost-sensitive teams running many small sites where per-editor CMS pricing would dominate TCO.
• You accept the maintenance risk with eyes open. Pin Nova and the package together on one shared upgrade ticket, test config:cache in staging, and validate the installed package identity (outl1ne/nova-page-manager / Outl1ne\PageManager) before anyone debugs a namespace ghost from an old blog post.
• A short spike can settle it. One to two days: one template, two block types, one region, one published page rendered through our own controller and Blade partials. If that loop works, the integration risk is largely retired.

Look elsewhere when:

• You need a real CMS. Editorial workflows with review stages, roles/permissions beyond Nova's, scheduled campaigns coordinated across channels, content analytics, or a media library out of the box. There is no media library here — pair it with outl1ne/nova-file-manager or spatie/laravel-medialibrary, and store relative paths in block fields.
• Editors must build layouts freely. Anything resembling an open page builder (drag-anything, arbitrary nesting, editor-defined structures) is out of scope by design.
• You're not on Nova, or you're planning a Nova major upgrade in the next two quarters. Upgrade coupling is the structural risk: a Nova major can break resources, fields, and this package simultaneously.
• The content is not the product. If content architecture is your differentiator — a content platform, a marketplace with structured listings, multi-tenant publishing — the guardrail model and the single-block-type-per-file approach will fight you.

How to Pitch It (Stakeholders)

For executives — the one-liner: This is a small, MIT-licensed dependency that gives our Nova admin a real page editor — templates, reusable content blocks, drafts, scheduling, and multi-language — in days rather than a quarter, and it stores content in our own database so we are never locked in.

The business case, in three points.

1. Time-to-market. Marketing and campaign pages stop being engineering tickets. Editors publish within an approved set of page templates; we stop redeploying the site to change a headline.
2. Cost and lock-in. Self-hosted, MIT, no per-seat licensing. Content lives in our MySQL as structured JSON and renders through our own Blade components, so outgrowing it is a contained migration project, not a re-platforming. We will maintain a pages:export command from day one as both backup and exit plan.
3. Localization optionality. Per-locale page content comes largely for free, which turns "launch in a second market" from a platform project into an incremental content effort.

The honest risks, stated up front. Small single-maintainer package with modest adoption; a direct dependency on Nova's major version; and it deliberately does not route, render, or manage media — that work is ours.

What we're asking for. A two-day engineering spike, not a commitment: one page template, two block types, one reusable region, one published page rendered end to end, plus a check that config:cache survives our pinned versions. If the spike passes, we adopt with the version pinned, a pages:export command in place, and Nova and this package on a shared upgrade ticket. If it fails, we've spent two days and gained a validated feature spec for either an in-house build or a paid CMS evaluation.

For engineering — the framing they need: Treat templates and blocks as a code-reviewed component library, not a page builder. One block key maps 1:1 to one Blade partial; adding a block type is a single pull request touching config, partial, and test. Put a thin repository layer between our controllers and the package model, resolve the locale once, invalidate cache on save rather than deploy, and add an authenticated preview route — that preview is the single highest-value twenty lines we'll write, because editors will not trust a draft toggle they cannot see through.