Laravel Filament Page Manager Laravel Package

Product Decisions This Supports

• Build vs. buy for "editable marketing pages." This package replaces the custom Page model + Filament resource + slug-resolution + front-end catch-all route that teams otherwise rebuild on every Filament project. Choose it to remove ~1–3 weeks of undifferentiated CRUD work, not to gain new capability.
• Roadmap scoping: CMS-lite vs. real CMS. It answers the question "do we need Statamic/Contentful, or just a handful of editable pages?" If content needs stop at titled, slugged, templated pages with SEO metadata and localization, this keeps the CMS decision off the roadmap entirely.
• Admin panel topology. v1.0.13 fixes a real edge case — the catch-all page route now excludes only the configured admin path prefix, so pages no longer shadow (or get shadowed by) the Filament panel routes. This directly affects the decision of where to mount the panel (e.g. /admin, /cms, /backoffice) and makes non-default admin paths safe to use. Pin ≥1.0.13 if your panel path is anything other than the default.
• Localization and SEO ownership. Supports the product decision of letting marketing own translated slugs and meta fields in-admin instead of filing engineering tickets.
• Make vs. maintain. Adopting a 1.x, single-maintainer package is a standing commitment: budget for the possibility of forking. 1.0.13 shows healthy-but-small maintenance (one contributor PR, one Dependabot bump) — fine for a page manager, thin for anything load-bearing.
• Not a page builder. If the roadmap includes block-based composition, reusable content sections, or landing-page A/B variants, this decision is not covered here.

When to Consider This Package

Consider it when:

• The stack is already Laravel + Filament and you want pages managed in the same admin your team already logs into — no second UI, no second auth model.
• The content model is genuinely flat: pages, slugs, titles, per-page Blade templates, localized variants, basic SEO fields.
• You want Laravel-native artifacts (migrations, routes, config, views) you can publish and own, rather than a hosted CMS dependency.
• A small content team (1–5 editors) publishes on a weekly-not-hourly cadence, without editorial workflows.
• You need a front-end catch-all route that resolves /{slug} to a page while leaving the admin panel untouched — the exact scenario 1.0.13 hardens.

Look elsewhere when:

• You need structured content: custom post types, taxonomies, relationships, repeaters, media libraries with transformations, draft/publish workflows, scheduled publishing, or revision history. Reach for Statamic, a fuller Filament CMS plugin, or a headless CMS.
• Editorial volume is high or governance-heavy (approvals, roles beyond Filament's basics, audit trails).
• Multi-tenant or multi-site with per-site page trees — verify before committing; this is a page manager, not a site-tree manager.
• You cannot tolerate single-maintainer risk, slow CVE response, or a fork you'd have to carry. Check the license terms and the maintainer's release cadence against your own support obligations.
• You need first-class versioning of the package's API; 1.x patch releases are still shifting route and config behavior, as 1.0.13 demonstrates.
• The requirement is really a page builder (drag-and-drop blocks) rather than a page registry.

On this release: 1.0.13 is a low-risk patch — one routing bug fix (admin prefix exclusion) plus a CI-only dependency bump (setup-php), no API changes, no deprecations, no migrations. Treat as a routine upgrade; prioritize it only for installs with a custom admin path.

How to Pitch It (Stakeholders)

To executives: It lets marketing publish and edit site pages — copy, slugs, translations, SEO fields — from the admin we're already building, without buying or integrating a separate CMS license. That removes a recurring vendor cost and a second system to train on, and it shortens the path to launch for marketing pages. Cost is engineering time only; the trade-off is that we're depending on a small open-source component, so we should scope it to straightforward pages and keep a fork option in our back pocket.

To engineering: A Laravel-native, Filament-integrated page manager — a Page model, resource, slug-based routing, and publishable migrations/config/views. Small surface area, no exotic dependencies, and it lives inside the Filament panel you're already provisioning. 1.0.13 fixes admin-path exclusion in the page route (upgrade if the panel isn't at the default path) and bumps a CI action; no breaking changes, no schema changes. Adoption is a Composer require plus publishing config and migrations. Risks to flag: single-maintainer 1.x, so pin the version, and be prepared to own a fork if we outgrow flat pages.

To the content/marketing lead: You'll edit pages in the same admin as everything else — title, URL slug, template, translations, and meta fields — with changes going live without a developer. What it won't do today is drag-and-drop page building or approval workflows; if those become requirements, we revisit.