Cms Laravel Package

Technical Evaluation

Framing correction (the headline finding): craftcms/cms is not a Laravel package — it is a self-hosted PHP application built on the Yii2 framework. It is installed as a project (composer create-project craftcms/cms), not required into an existing Laravel vendor/ tree. The Dependents: 0 signal is a metadata artifact of how the repo is consumed, not evidence of low adoption (3.6k stars, active 5.9.x release train). Any evaluation that treats this as "a package to composer require" will produce a plan that fails at the first integration milestone. The realistic model is two applications, not one dependency.

• Architecture fit: Strong if the requirement is "bespoke content modeling + editorial control panel + headless delivery." Craft's clean-slate content model (sections, entry types, fields, Matrix/Content Block fields), auto-generated per-schema GraphQL API, and Twig templating map well to content-heavy products. Weak fit if the team's expectation is that Laravel owns the domain model and Craft is an embeddable content widget — Craft insists on owning its own request lifecycle, database, and users.
• Integration feasibility: Two viable topologies, both proven in the wild. (1) Headless: Craft runs as a content service; Laravel consumes GraphQL (preferred, first-party, schema-scoped by token) or REST via the Element API plugin. (2) Side-by-side/coupled: Craft renders marketing and content routes, Laravel serves the authenticated product, with a shared reverse proxy, shared Redis, shared asset/CDN origin, and a shared identity story (SSO or Laravel as the IdP). Option 2 is cheaper to start and more expensive to evolve; option 1 is the reverse.
• Technical risk: Highest risks are non-technical or cross-cutting. Licensing: the metadata reports NOASSERTION; Craft is source-available under the Craft License, not OSS — free for Solo, paid per project for Pro, and domain/license mismatches visibly block the control panel (the changelog's up command warning about "astray license issues" is evidence this trips people in practice). Procurement must confirm tier before architecture is locked. Security surface: the 5.9.0 changelog carries two notable advisories (moderate SSTI via the Twig create() function, high-severity IDOR in GraphQL @parseRefs/@transform directives) — a TPM should read that as "this app requires a real patch SLA," not as a one-off. Ecosystem split: Yii2 idioms, Yii2 migrations, Yii2 queue — a Laravel-only team inherits a second framework's mental model, its own upgrade cadence, and its own hiring profile.
• Key questions for the team:
  1. Does Craft own the content model and the public site, or only content? (Determines headless vs. coupled.)
  2. Does Laravel ever need to write back to Craft (drafts, entries, users), or is the flow read-only? Write-back is possible but constrained and adds auth/complexity.
  3. Which license tier, and who owns the domain registrations tied to it?
  4. What is the patch SLA for a CMS that has shipped SSTI/IDOR advisories in a minor release?
  5. How many third-party plugins will be in the critical path, and are they commercial?
  6. Is a Craft major upgrade (4→5 class) inside the planning horizon? Content-model migrations across majors are the dominant long-term cost.

Integration Approach

• Stack fit: Craft requires PHP 8.2+, Composer 2, MySQL 8 or PostgreSQL 13+, and — in practice — Redis for cache/sessions and a supervised queue worker (image transforms, resaves, and other jobs silently fail without one). Laravel requires roughly the same PHP floor, so a single base image family works, but vendor trees must stay separate: two composer.json files, two build pipelines, two deployables. Do not attempt a merged monorepo vendor/ — Yii2 and Laravel's service container bootstraps are not designed to coexist in one process.
• Migration path (if replacing an incumbent CMS): content inventory and URL map → model in Craft (sections, entry types, field layouts) → promote config as project config YAML in version control (this is the single highest-leverage operational practice in Craft; it makes environments deterministic and reviewable) → import content via custom console commands or the Feed Me plugin → redirect map at the edge. If the incumbent is Laravel-based, do not migrate Laravel into Craft; carve the content/marketing surface out and leave the application where it is.
• Compatibility considerations: keep the Laravel app and Craft on the same PHP minor so one runtime patching policy covers both; pin Craft to a caret constraint and treat minor bumps as deployable but reviewed (5.9.0 shows UI/CP behavior changes ship in minors); version the GraphQL schema alongside Laravel (commit schema snapshots, assert them in CI); confirm any Laravel-side HTTP client is compatible with Craft's GraphQL auth model (bearer tokens per schema, plus the X-Craft-Preview-Token header pattern for preview).
• Sequencing (recommended):
  1. Spike (1–2 weeks): stand up Craft headless, author a minimal GraphQL schema, and prove Laravel can consume and cache it end-to-end with a preview workflow. This de-risks the whole architecture before spend.
  2. Procurement + security review: license tier, domain inventory, plugin inventory, and a written patch SLA.
  3. Content model + project config workflow: config in VCS, code review on config diffs, environment promotion rehearsed once.
  4. CI/CD and observability for two apps: separate pipelines, shared logging/tracing, queue depth and job failure alerting.
  5. Content migration and redirects, rehearsed twice against a production-sized dump.
  6. Cutover and rollback plan.

Operational Impact

• Maintenance: Two applications means two upgrade streams and two vulnerability surfaces. Craft's own major upgrades are the largest scheduled cost; plugin upgrades are the largest unscheduled cost. Project config discipline keeps environment drift from becoming an incident, but only if config diffs are reviewed like code. Budget ongoing effort for CP-facing regression testing — a large fraction of 5.9.0 is control-panel behavior (Matrix view modes, action menus, breadcrumbs, revision menus), which is exactly the surface editors notice and unit tests miss.
• Support: Commercial license buys vendor support for Pro; the community (Discord, Stack Exchange, CraftQuest) is genuinely active and is the real first-line resource. There is no vendor SLA at the "package" level, so internal ownership must be explicit — name a person who owns Craft, not a team that "also does Laravel."
• Scaling: PHP-FPM scales horizontally; keep the app stateless with Redis for sessions/cache and object storage for assets. Content reads are highly cacheable — front with a CDN and, for coupled deployments, a static-cache layer. The database is the bottleneck, and multi-site setups multiply query complexity; enforce GraphQL query depth/complexity limits per schema to prevent expensive public queries from becoming a DoS vector. Move anything expensive (transforms, resaves, exports) to the queue and size the workers deliberately.
• Failure modes to instrument for:
  • Queue backlog or dead worker → missing image transforms and stale derived content, often discovered by editors rather than monitoring.
  • Project config drift → an environment that looks healthy but behaves differently; detect by diffing config in CI, not at deploy time.
  • License/domain mismatch → control panel lockout after an environment clone or domain change; treat as a launch-checklist item.
  • Cache incoherence between Craft and the Laravel-side cache → stale or partially-updated pages; needs an explicit invalidation contract (Craft element save → purge event → Laravel/CDN purge).
  • Unpatched security advisories → the SSTI and GraphQL IDOR classes seen in 5.9.0 are exploitable by content editors and API consumers respectively; require patching within a defined window.
  • Plugin breakage on a Craft minor → CP JavaScript and field UI are the usual casualties; pin plugins and test upgrades in staging.
• Ramp-up: A Laravel developer should reach productivity on the headless consumption path in roughly one to two weeks; learning Craft's Element/Query API and eager-loading to avoid N+1 queries takes longer, and authoring custom plugins (Yii2 module/event/service patterns) is a three-to-four-week curve for someone who has never touched Yii2. Editors need structured CP training, and that training material decays with each minor release given how much CP behavior changes — plan to refresh it, don't treat it as a one-time asset.