Nova Page Manager Laravel Package

Technical Evaluation

Architecture fit. This package is not a CMS; it is a pre-built Nova admin surface over two Eloquent concerns — slug-addressable pages and reusable, named regions — plus optional migrations and a default Blade view. That narrow scope is the point: it is an accelerator for teams already running Laravel Nova as their back office, and it substitutes for the hand-rolled page/region CRUD that would otherwise consume a sprint. Critically, it does not sit in the public request path unless we deliberately enable its catch-all /{slug} route. That keeps the blast radius of a wrong bet small and makes this a low-cost pilot rather than a platform commitment.

Integration feasibility. High, and cheap to prove. composer require, a vendor publish (per-tag if we expect to customize views), php artisan migrate, and resource registration in NovaServiceProvider is a sub-day developer spike. The package is thin enough to read end-to-end in roughly twenty minutes, which means "does it support X" questions get answered by source review rather than by vendor correspondence. The one non-trivial decision — whether the package or the application owns public routing — is a gate we should set explicitly before build, not discover later.

Technical risk. Manageable but concentrated in four areas:

• Vendor concentration. 179 stars, zero known dependents, single-vendor maintenance. There is no implied support SLA and no community backstop.
• Nova major coupling. Compatibility is bound to Nova releases, which ship roughly annually. The changelog entry in 6.0.3 ("Fixed saving with MergeValue inputs") is illustrative: it is exactly the class of bug that surfaces only when an editor hits Save on a Flexible Content field.
• Missing editorial primitives. No draft/publish workflow, no revisions, no preview, no redirect-on-slug-change, no HTML sanitization, no permission model beyond Nova's. Every one of these is ours to build, and the first (a published flag) is required before handing the tool to a non-technical team.
• Silent failure modes. Missing region views render as blank gaps; slug changes break live URLs with no warning; config caching makes model bindings appear inert.

Key questions to resolve before approval.

1. Is there a release compatible with our exact Nova major, and does our pinned version include the 6.0.3 fix? (The recorded last-release date of 2026-06-15 is worth verifying against Packagist directly — release metadata hygiene is itself a maintenance signal.)
2. Do we bind our own Page/Region models at the config layer, or accept the packaged models as-is?
3. Does region content need structured, queryable JSON, or is an opaque column sufficient? This determines whether we extend or eventually fork.
4. Who owns the annual Nova upgrade, and what is the pre-agreed fork trigger?
5. What is the measured editorial volume — page count, region types, localization scope — that would trigger a real CMS/DXP conversation?

Integration Approach

Stack fit. Hard requirement: Laravel + Laravel Nova. There is no path to reuse this outside a Nova back office, and that constraint should be stated in the decision record. Where the constraint holds, the fit is excellent — regions are first-class and shared, so a footer-cta or sidebar edited once and attached to many pages behaves like a curated block library rather than a bespoke page builder. That reuse is the real day-to-day editor win and the clearest justification over custom CRUD.

Migration path. Two distinct plays:

• Greenfield. Enable the package catch-all route first to get a fast "create a page, see it in the browser" feedback loop and validate the data model, then take routing back once middleware, layouts, caching, or auth-gated content appear. Most teams end up owning routing; plan for it rather than resist it.
• Brownfield. If pages/content_blocks tables already exist, write a one-off mapping migration (slug/title/body → page + region rows), keep the legacy table read-only for one release as a rollback path, and cut over only when the renderer matches. Content is cheap to move early and expensive to move after editors have invested in the old tool.

Compatibility. Pin the exact version and record the constraint matrix — Laravel, PHP, and Nova versions in the README — and add a CI job that installs against our pinned Nova version so a breaking Nova major fails in CI rather than in the editor's admin panel. Prefer the config-layer extension point (page_model / region_model bindings, keeping our models extending the package's) before considering a fork. Keep schema extensions additive in our own migrations; do not rewrite packaged migrations, which will collide on a future package update.

Sequencing.

1. Time-boxed spike on a branch: install, publish, migrate, register resources, render one page end-to-end.
2. Decide route ownership and disable the package catch-all if we are taking it.
3. Additive migration for published (and published_at if scheduling is in scope) plus a Nova toggle and resolver filter.
4. Central region-type → view config map with a guard so a missing view degrades to nothing rather than a fatal error.
5. Cache the read path with an observer busting on save — including the old slug on rename — and redirect generation on slug change.
6. Signed preview URL, HTML purification at render time, seed data for fresh clones.
7. Editor training and written publish process, then handover.

Steps 1–3 are the pilot; 4–6 are the cost of making it production-safe; 7 is what prevents the tool's simplicity from becoming the thing that bites us.

Operational Impact

Maintenance. Low steady-state, with one predictable spike: the annual Nova major. Decide the fork trigger now rather than under pressure — if package compatibility trails a Nova release by more than one cycle, vendor it into packages/ and own it. MIT licensing makes that cheap in principle; deciding reactively makes it expensive in practice. Assign a named owning engineer; a single-vendor package with this adoption level has no implicit maintainer.

Support. No vendor SLA. Support is entirely internal: one engineer accountable for upgrades, a short runbook covering install, model bindings, region-type mapping, and the config-cache gotcha, and explicit documentation of who publishes and how. Because there are no drafts or revisions, process documentation substitutes for tooling safeguards — it matters more here than on a mature CMS.

Scaling. The database is not the constraint; hundreds to low thousands of pages is comfortable. The plausible bottleneck is the Nova editor form with many regions per page — test with a realistic 20+ region page before committing, and if it is slow, split long pages across templates rather than adding fields per region. On the read path, eager-load pageRegions.region every time; N+1 queries here stay invisible until a page has twenty regions, then become the most common performance defect.

Failure modes to instrument.

• Region whose view is missing → silent blank section. Add an @includeIf guard and a visible non-production placeholder naming the missing view.
• Slug change → 301 to the new URL, and bust cache for the old slug.
• Unreviewed copy going live on save → the published flag is a prerequisite, not a nice-to-have.
• Catch-all route shadowing /login or being shadowed by it → resolved by owning routing explicitly.
• Stale config cache masking model bindings → first troubleshooting step, documented.
• Fresh clone with no seeded content → every developer sees 404s and assumes the install is broken.

Ramp-up. Asymmetric. A Laravel developer is productive in hours; editors need only brief Nova training. The real onboarding cost is process, not tooling — write down the publishing workflow before launch.

Success metrics for the pilot. Deploys avoided, content tickets closed without a developer, count of pages and distinct region types in use, frequency of draft/preview requests, and editorial complaints. Those numbers — not a feature matrix — are the inputs to the eventual headless CMS or DXP decision, and they justify deferring that procurement until content complexity actually demands it.