Cms Laravel Package

Product Decisions This Supports

• Content-managed marketing/CMS surface area without a separate platform: numberninecms/cms is a Laravel-native CMS, so the decision it informs is "do we stand up a headless/external CMS (Contentful, Strapi, WordPress) or keep content inside the app we already run?" Owning content models in Eloquent keeps a single deploy, single auth model, and single observability stack — a real cost saving for small teams.
• Build vs. buy for admin/authoring: a package like this replaces the "build a CRUD admin for pages/posts" backlog item. The PM trade-off is customizability vs. lock-in to the package's content model and routing conventions.
• Feature sequencing: this release (0.4.5) is a patch fix to how the package reads the request array — all() instead of get() (#69). Practically, that means query/form payloads with nested or non-scalar values (JSON bodies, array-style form fields, filter sets) now survive into the CMS layer instead of being silently dropped. That unblocks features depending on rich filter/search/settings payloads — a small but real enabler for admin filtering and query-string-driven content views.
• Roadmap signal: a 0.4.x line with a small, targeted bugfix and an issue-numbered changelog indicates an actively maintained but still pre-1.0 package. Plan for API churn; do not anchor a multi-year content strategy on it without a version-pinning policy.
• Use cases it fits: brochure/marketing sites, internal tools needing editable page copy, blogs and documentation sections, and MVPs where shipping a bespoke admin would delay validation.
• Use cases to route elsewhere: multi-tenant editorial workflows with granular roles, heavy localization/translation pipelines (unless verified in-package), high-traffic public content needing CDN-first delivery, or organizations requiring a commercially supported CMS with an SLA.

When to Consider This Package

Consider adoption when:

• Your application is already Laravel and you want content authoring in the same codebase, deploy pipeline, and database — no second system to operate or sync.
• Your content model is modest and stable: pages, posts, basic taxonomies, media. You are not modeling complex editorial state machines.
• You can pin to a specific version and absorb occasional pre-1.0 changes; your team is comfortable reading package source and patching it if needed.
• You need request-driven content filtering/settings — 0.4.5's all() fix specifically improves handling of non-scalar request payloads, which matters if your admin or public views pass arrays (filters, facets, nested query params).
• Timeline pressure favors configuration over construction, and a custom admin would be weeks of work for undifferentiated value.

Look elsewhere when:

• You need guaranteed backwards compatibility and a support contract. A 0.4.x version number is an explicit "not yet stable" signal; there is no commercial backing evident in the changelog.
• Editorial needs are the product differentiator — multi-step review, scheduling, per-locale workflows, audit trails. Purpose-built or hosted CMSs will outrun a general-purpose package here.
• You require ecosystem-scale plugin/marketplace depth (e.g., dozens of prebuilt field types and integrations).
• The upgrade cadence is a concern: even patch releases touch request handling, which is core plumbing. If your team cannot test upgrades, prefer a system with an LTS commitment.
• SEO/CDN-first delivery at scale is central — plan for how content is cached and invalidated regardless of the CMS chosen.

Adoption recommendation for this release: low-risk patch, safe to take. all() vs get() only widens what is read; it does not change signatures or storage. Test any code paths that depend on absent query parameters returning null — all() returns an empty array where get() may have returned a default, so guard your checks. Treat it as a routine bump, not a migration event.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can avoid licensing and operating a separate content platform by using a Laravel-native CMS package that lives inside our existing application. That means one deployment, one database, one security model, and no content-sync integration to build or maintain — a meaningful reduction in run-cost and vendor surface for sites whose content needs are straightforward (pages, posts, media, basic structure). The trade-off is maturity: the package is pre-1.0, so we pin versions, and we accept that we may occasionally patch or work around rough edges. The latest release is a small, low-risk bugfix that improves how content queries and filters are read from requests — nothing breaking, no rework required.

For engineering (one paragraph): 0.4.5 changes the request accessor from get() to all() (#69), so array and nested payloads (JSON bodies, bracketed form fields, filter sets) reach the CMS layer intact. No API changes, no schema changes, no deprecations — a patch bump. Action: upgrade, then audit any controller or view that relied on get() defaulting behavior, since all() returns [] rather than a supplied default. Recommend pinning to 0.4.*, adding a smoke test around admin filtering and any query-string-driven content views, and keeping a fork-and-patch option open given the pre-1.0 version line.

For product/design: admin filtering, saved views, and richer query-string-driven content lists become more reliable with this fix — expect fewer "my filter didn't apply" defects. Editorial workflow depth (roles, scheduling, localization) is not delivered by this release and should be scoped and validated separately before we promise it.