Cms Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the "boring core" of a back-office. The decision this package forces is whether we hand-roll content primitives — pages, posts, slugs, publish states, settings, repository seams — or inherit someone else's. Benchmark it against the three real alternatives: building on Filament, licensing Statamic/Craft, or writing our own schema. Frame the answer as "how many PM-sprints does this remove from the roadmap," not as "is this a good package."

• Roadmap de-risking for internal tooling. If the next two quarters include an admin panel, editorial workflow, or a lightweight marketing/blog backend, this can compress weeks of scaffolding into days — provided the stack matches its assumptions: Laravel, modular monolith, single-tenant, no headless API requirement. It does not belong on a customer-facing, multi-year roadmap.

• Scope discipline: what is "core" vs. what is our product. Evaluating this is a forcing function. If two-thirds of what it offers we'd rewrite for our domain anyway, our differentiation lives above the CMS layer and we should borrow or buy this layer rather than own it. If it covers exactly the primitives we'd otherwise rebuild, that's a cheap win.

• Architecture-as-a-decision ("reference, don't depend"). With 19 stars, zero dependents, and a single-maintainer lineage, the highest-value outcome may be studying how an experienced Laravel author decomposes a CMS into contracts, models, repositories, and traits — then porting the patterns, not the code. That is a one-engineer-day decision with an architecture write-up as the deliverable, and it is a legitimate one.

• Feature-level call on bounded content types only. The realistic use case is one or two well-understood content types (Article, Page, Menu) behind an internal admin. This is not a decision that unlocks customer-facing content infrastructure, merchandising, or anything requiring a proven upgrade path.

• Risk posture, made explicit. Scoring this at ~0.48 with an opportunity signal of ~0.57 is PM language for "interesting, unproven, cheap to trial, expensive to depend on." The decision to fund a spike is separate from — and much easier than — the decision to adopt.

When to Consider This Package

Consider it when:

• The stack is already Laravel and the architecture is a modular monolith; the package assumes both.
• The need is internal, back-office tooling — editorial workflows, page/menu management, settings — not customer-facing content delivery.
• We need the core layer only: contracts, repositories, base models, and reusable traits. The actual CMS behavior (admin views, menus, media) lives in sibling packages (cms-page, cms-menu, cms-media), so adopting core alone renders nothing useful.
• We have an engineer who will read the source. There is no meaningful external documentation; the source is the docs. Budget for that explicitly or don't start.
• We accept the schema commitment that comes with publishing migrations, and the overlap with our own design exceeds roughly 70%.
• We are prepared to pin the version exactly (no caret), mirror the fork privately, and run our own integration tests against it in CI.
• We have a written exit plan before the first commit: application code depends on our interfaces, with a thin adapter to cms-core behind it, so replacement is confined to one directory.

Look elsewhere when:

• The requirement is headless/API-first, multi-tenant, or heavily localized content — the assumptions don't hold.
• The roadmap needs a supported vendor with SLAs, a published upgrade path, or a security response process. Zero dependents and 19 stars means a Laravel compatibility break can stay broken upstream indefinitely.
• The team has no appetite for maintaining a fork. With a single-maintainer lineage, forking is not a contingency — it is the maintenance model.
• We need the CMS to be a product surface rather than internal plumbing. Licensing Statamic or Craft, or building on Filament, buys support and a hiring pool this does not.
• The overlap between its schema and ours is low. Below that threshold, take the traits and contracts as reference implementation and write our own tables.
• Nobody on the team will own the reverse-engineered documentation. Every convention not written down leaves with the engineer who found it.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), open-source scaffolding library for the unglamorous core of an internal admin tool — page and post management, publishing states, settings. It compresses the first weeks of a back-office build into days. The strategic value is not the code; it is that adopting it forces a clean one-page answer to "do we build or buy our content layer," and it lets us spend our differentiation budget on the product rather than on CRUD plumbing. It is also a low-commitment trial: one engineer, roughly a week, ending in a go/no-go written recommendation. The risk is maintenance lineage — one maintainer, minimal adoption — which is why adoption requires version pinning, a private fork, and an exit plan scoped to a single directory. We are not betting the roadmap on it; we are buying an option.

To engineering: Treat this as a reference architecture first and a dependency second. Read src/Contracts (the seams), the config file (the swap points), and the published migrations (the schema debt) before writing anything. Bind contracts in one provider driven by one config key — that file is our deletion list. Never consume package models directly in controllers; extend them in App\Cms and restate traits explicitly. Use the traits (slug, publish state, meta) on our own models wherever possible — highest value, lowest risk, no migration ownership. Watch for global scopes leaking into unrelated queries, N+1s in default repository listings, slug collisions across soft-deleted rows, and the fact that published migrations cannot be safely un-published. Verify auto-discovery is declared in composer.json before debugging anything else, and add config:clear to the deploy script. Pin the version exactly, mirror the fork, and keep a short docs/cms-core-notes.md — contract map, model map, scope list, migration list, exit plan. That file is worth more than the package.