Nova Page Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for CMS-lite. When the back office already runs Laravel Nova, this package substitutes for a hand-rolled page/region CRUD. Frame the decision as “accelerator for simple admin-managed content” versus “custom build” versus “full CMS/DXP procurement” — with the honest caveat that it delivers content storage plus an admin UI only. Routing, Blade rendering, caching, previews, redirects, permissions, and editorial process remain ours. Because it is MIT-licensed and free, the buy-side cost is near zero; the real cost is the engineering surface we still own.
• Roadmap sequencing. Lets us ship self-serve content editing (marketing pages, landing pages, regional blocks) earlier and defer a headless CMS or DXP decision until content complexity actually demands it. Treat localization at scale, drafts/revisions, multi-site scoping, and structured block authoring as phase-2 triggers, not day-one scope.
• Content operations strategy. Moves routine copy and SEO-metadata changes off the engineering backlog and into a small marketing/ops team working inside Nova. The metric to watch is deploys avoided and content tickets closed without a developer. Reusable regions — a footer-cta or sidebar edited once and attached to many pages — are the clearest day-to-day editor win versus bespoke CRUD.
• Scope control and use-case fit. Best for brochure sites, campaign and landing pages, terms/about/privacy pages, regional content sections, and internal admin tools where Nova is already the back office. Regions are shared and first-class, so it reads as a lightweight block library, not a page builder.
• Risk posture. The package owns roughly two tables and an admin surface and does not sit in the public request path unless we put it there, so the blast radius of a wrong bet is small. That is itself an argument for a time-boxed pilot over an extended procurement cycle.
• Buy-in on a fork trigger now, not later. Adoption is small (179 stars, no known dependents) and it is a single-vendor package. The decision that belongs in the roadmap review is not “will we fork” but “at what point do we fork” — pre-agree that if Nova compatibility trails by more than one release cycle, we vendor it into packages/ and own it. MIT licensing makes that cheap; deciding under pressure makes it expensive.
• Defer the CMS conversation with evidence. A pilot produces real inputs for the eventual platform decision: volume of pages, number of region types, localization needs, editorial complaints, and how often drafts/previews are requested. Those are better procurement criteria than a feature matrix written in advance.

When to Consider This Package

Consider it when:

• The product is already on Laravel + Laravel Nova. Adoption is a composer require, a vendor publish (per-tag if we want to avoid overwriting customized views), migrations, config, and resource registration in NovaServiceProvider — a sub-day developer spike, not a project.
• The content model is genuinely simple: slug-addressable pages, named regions/blocks, SEO metadata, admin-managed copy. If a content editor could describe the page as “a hero, a few text blocks, and a footer CTA,” this fits.
• We need to unblock marketing/ops quickly on static pages, campaign landing pages, legal pages, or regional content sections without waiting for a full CMS procurement.
• Nova is already the internal tool for operations or admin work. Adding Page and Region resources keeps editors in a UI they already know, avoiding a second back office.
• We want a low-cost pilot to gather evidence on page volume, region types, localization needs, and editorial workflow requests before committing to a larger platform.
• We can own the surrounding engineering: app-owned routing, Blade rendering, caching, HTML sanitization, slug redirects, a published/draft flag, and preview URLs. The package does not provide these out of the box.

Look elsewhere when:

• The stack is not Laravel/Nova, or the team has no Nova license or appetite to run Nova as the editorial surface.
• The editorial team needs drafts, revisions, publish workflows, or approvals on day one. This package has no draft state; saves can go live immediately unless we add a published flag and process ourselves.
• Requirements include multi-site scoping, complex localization workflows, granular permissions, scheduling, or structured block authoring beyond simple reusable regions.
• The public site needs a mature page builder experience with layout composition, per-block previews, and drag-and-drop front-end editing. Regions are a block library, not a visual builder.
• The team cannot absorb Nova upgrade maintenance or is unwilling to pre-agree a fork/vendor trigger. Nova majors ship roughly annually and package compatibility can lag; without a maintenance owner, this becomes a hidden liability.
• High-traffic rendering is expected without engineering capacity to add caching and app-owned routing. The package’s default catch-all route and per-request queries are a starting point, not a production performance strategy.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed accelerator that lets marketing and ops edit simple pages inside Laravel Nova without developer involvement. It is not a full CMS — we still own routing, rendering, caching, previews, redirects, and editorial process — but it lets us ship self-serve content editing earlier and defer a headless CMS or DXP procurement until we have real evidence. The blast radius is small: roughly two tables and an admin surface, not the public request path unless we choose to put it there. The recommendation is a time-boxed pilot with clear success metrics: content tickets closed without engineering, deploys avoided, and a documented list of phase-2 needs such as drafts, localization, or multi-site support.

For engineering: Treat this as a thin, readable package — a page/region data model plus Nova resources. The integration is a sub-day spike: composer require, vendor publish per tag, migrate, configure config/nova-page-manager.php, and register resources in NovaServiceProvider. Plan to own the production surface: disable the package catch-all route and resolve pages in app routing, eager-load pageRegions.region, map region types to Blade views in one config file, add a published flag and signed preview URLs, sanitize rich HTML at render time, cache reads and bust on save (including old slugs), and redirect on slug changes. Pin the exact version, record the Laravel/PHP/Nova constraint matrix, and add CI against the pinned Nova version. Pre-agree the fork trigger: if Nova compatibility trails by more than one release cycle, vendor the package into packages/ and own it. MIT licensing makes that cheap; deciding under pressure makes it expensive.

For the pilot team: Start with package routing for fast feedback, then take routing back once middleware, layouts, or caching are needed. Create regions in the Region resource first, then attach them to pages. Seed a minimal page set for local development so new developers do not see 404s. Write down the publishing process — who publishes, how review works, and what “done” means — because the package’s simplicity shifts process risk onto the team. Measure what the pilot teaches us: page volume, region types, localization requests, preview/draft demand, and editor complaints. Those findings become the procurement criteria for the next platform decision.