Cms Core Laravel Package

Product Decisions This Supports

A recorded "do not adopt" decision — this is the deliverable, not a side note. The package is republished under a GrahamDeprecated namespace, its only release line is v0.2.0-alpha, it declares support for Laravel 4.1 exclusively (end-of-life since 2016), and it has zero dependents and no star traction. None of that can underwrite a roadmap item, a delivery estimate, or a customer commitment. The highest-value PM output is a written close-out so the same package doesn't resurface in next quarter's build-vs-buy scan.

A build-vs-buy-vs-borrow call: rule out "buy/borrow," keep "read." Treat the source and docs as free reference material and a requirements checklist rather than a dependency. Its scope maps cleanly onto backlog epics:

• A shared content-model trait so content types behave consistently (shared fields, publishing state, slug handling).
• Navigation / menu building and management.
• Persisted redirects — URL churn handled in the database instead of hardcoded server config.
• A caching layer in front of content delivery.
• Standard service provider + facade wiring.

Two backlog items worth pulling forward regardless of the adoption decision. Navigation and persisted redirects are classic implicit gaps — nobody writes them into v1 scope, and everyone discovers them after content gets reorganized and links break. Persisted redirects in particular is a cheap early win with direct SEO, campaign-link, and support-ticket payoff. Use this package's scope as the prompt: does our roadmap already name them? If not, add them as an owned item now.

Risk triage if it already sits inside something we run. The right framing isn't "upgrade" — there is no upstream to upgrade to — it's a migration ticket: named owner, target state on a supported Laravel version, a date, and a boundary confining the dependency. Zero dependents and an archived maintainer org mean the exit is entirely on us.

Use-case qualification. The one defensible scenario is read-only archaeology inside a legacy Laravel 4.1 system during decommission or rewrite. Never new product work, never a customer-facing surface, never anything carrying an SLA.

When to Consider This Package

Consider it only when all of the following hold:

• You already run a Laravel 4.1 application that depends on it, and the task is to understand or document that dependency during a migration.
• The work is time-boxed, read-only, and non-production — source review to extract domain intent (content trait, menu model, redirect resolution, cache keys), not installation.
• An engineer on the team can read legacy PHP and translate intent rather than port code.
• Stakeholders accept up front that there is no support, no patches, and no security response — for the package or the framework beneath it.

Look elsewhere — or build the equivalent in-house — when any of these is true:

• You're on Laravel 5.x or later, or greenfield. This is a hard incompatibility, not an untested-but-probably-fine note. Auth guards, contracts, provider registration, config namespacing, and routing all diverge; an adapter would cost more and carry more risk than reimplementing the three primitives.
• The package would sit on a customer-facing or revenue-bearing path — menus and redirects are directly user-visible, so defects become customer-visible.
• Test coverage is a release gate. The release notes say "removed broken tests" in the same release that changed authentication and events: coverage was deleted, not restored, precisely where coupling is highest. Our own end-to-end tests become the only safety net.
• You need stable APIs. 0.2.0-alpha plus an archived repo means breaking changes are likely and possibly permanent.
• Security review or dependency due diligence must pass. An EOL framework with no patch path won't clear it, regardless of this package's code quality.
• A maintained CMS package or framework-native capability exists for your supported Laravel version — which, for modern Laravel, it does.

How to Pitch It (Stakeholders)

For executives. cms-core is an early-alpha Laravel package bundling common CMS building blocks — a shared content-model trait, navigation and menu management, persisted redirects, caching, and reworked authentication and events. It is not a candidate for adoption. It's archived under a deprecated namespace, supports only Laravel 4.1 (out of support for years), has zero known dependents, and its latest release removed its broken tests while simultaneously changing authentication and event behavior. The recommendation: record a formal "no" with rationale so the question is settled, and — if anything we run depends on it — open a migration ticket with a named owner and a date. Its genuine value is as a free requirements checklist: the persisted-redirect and content-trait patterns are inexpensive to cover internally, and if the roadmap doesn't already address navigation and redirects, those are silent gaps worth closing now.

For engineering. Treat the repository as documentation, not a dependency. Don't composer require it outside a disposable legacy container; if you must, pin the exact 0.2.0-alpha with no caret and run a Composer dry run first. Mine the service provider, content trait, and redirect model for domain shape — and note that redirects deserve loop detection, status codes, collision ordering, and 404 fallthrough rather than a naive path→path table — then implement only what the roadmap actually needs on a supported Laravel version. The equivalent scope is small and well understood. If we already run it in a legacy system, isolate every touchpoint behind internal interfaces (content repository, menu service, redirect resolver) so replacement is a contained change rather than a rewrite, and write our own regression tests around login/logout, event listener firing, and model persistence — the package's own suite can't be relied on. Watch the classic failure modes: event listeners silently not firing, stale cache serving the wrong menu or redirect after an editorial change, and config:cache freezing package config so edits appear ignored.

Recommendation. Don't attach roadmap features, delivery dates, or customer promises to this package. Close the evaluation with written rationale, add "navigation and persisted redirects" to the backlog as an owned item, isolate it wherever it already exists, and revisit only if a maintained fork appears with supported Laravel versions, restored test coverage, and a stable release.