Core Laravel Package

Product Decisions This Supports

• Build vs. buy for content management. Concrete CMS is a mature, MIT-licensed PHP CMS with in-context editing, page types, block-based composition, granular permissions, workflows, multi-site, and a marketplace of add-ons. This package is the Composer-installable slice of its core, so it is the artifact you evaluate when the question is "do we license/build a CMS or adopt one?"
• Platform selection for a site-builder or editor experience. If a roadmap item is "let non-engineers edit marketing pages / tenant sites without a deploy," Concrete's in-page editing model and permission matrix are a credible benchmark to compare against Statamic, Craft, Strapi, or a bespoke admin. 9.5.7 continues to show upstream investment in editorial correctness rather than new surface area — page-version custom styles are now kept apart, global-area custom styles are fixed, and a page-type bug that blocked adding a second block is resolved. That is the class of work we would otherwise absorb ourselves.
• Dependency and maintenance posture assessment. The repo is a read-only subtree split of the concrete/ directory from the root Concrete CMS monorepo. A PM should read it as a build artifact, not a product: 20 stars and 0 dependents measure the split, not the CMS. The real adoption signal lives in concretecms/concretecms and the install base.
• Security-patch obligation as a line item. 9.5.5 shipped a fix for CVE-2026-106551 (CVSS 8.6); 9.5.7 is the follow-through. Any decision to run Concrete carries an explicit, recurring patch-SLA cost — you are now the operator of an internet-facing PHP application with a high-severity advisory history. Model this as ongoing engineering hours, not a one-time integration. 9.5.7 also shows the operational shape of that obligation improving: upstream now requires a rationale for each ignored security advisory and runs advisory checks in a dedicated CI workflow. That is a governance pattern worth copying into our own repos regardless of whether we adopt Concrete.
• Upgrade-path risk, not just version risk. 9.5.7 fixes an upgrade failure where moving to 9.5.5 broke on MySQL 8 during a PageContainerInstances.containerID migration. This is the decision-relevant lesson: "pin an exact patch version" protects you from change but can also strand you on a broken migration path. Any Concrete adoption needs a tested upgrade runbook across patch versions, not just a pin.
• Fork-and-patch strategy. Because this is the exact core tree published to Packagist, it is the viable surface for pinning, patching, or vendoring core if your team needs to carry a fix ahead of upstream.
• Integration risk framing for a PHP product. Useful input to a decision on whether a legacy or non-Laravel PHP codebase can host a modern editorial layer without a rewrite.

When to Consider This Package

• You are already on Concrete CMS and need Composer-level control over core — patching, version pinning, or CI against core internals. 9.5.5 → 9.5.7 confirms the shape of release you should expect to consume on a regular cadence: bug fixes, security hygiene, dependency bumps, no migration or deprecation signal.
• You need a batteries-included, self-hosted PHP CMS with strong editorial UX, permissions, and multi-site, and you are willing to operate the full stack rather than assemble one.
• You require an MIT license with no per-seat or per-site commercial strings, and self-hosting is a hard requirement (data residency, regulated content).
• You are evaluating Concrete as a replacement or complement to an existing CMS and want to inspect the core tree directly.

Look elsewhere when:

• You are a Laravel or Symfony-first team expecting a drop-in package. This is not a Laravel package — it is a full application framework plus CMS. Adopting it means adopting its request lifecycle, routing, ORM, and templating alongside or instead of your existing stack. Budget real integration cost; do not treat it as a Composer dependency you sprinkle in. Note that 9.5.7 again had to fix "Concrete CMS being unable to be installed by Composer (except by ignoring audits)" — the same audit-blocking install problem flagged in 9.5.5 recurred. Treat composer audit + a clean install test as a permanent CI gate, not a one-time check.
• You need a headless, API-first CMS. Concrete can serve JSON, but its center of gravity is server-rendered pages. 9.5.7's API-adjacent work is hardening, not product expansion — sanitizing inline designs read from a CIF and suppressing the browser credential prompt in the API documentation console. The API remains a companion surface, not the design center.
• You need a large, active Composer ecosystem or third-party dependents. Zero dependents here means you will not find an ecosystem of packages built on this split.
• You need predictable release cadence with conventional semver. 9.5.5 → 9.5.7 confirms a rolling 9.5.x patch stream, including upgrade-path defects between consecutive patches. That is healthy for a CMS and hostile to naive ^9.5 pinning if you need change review — verify tag semantics and support windows against the main monorepo, and pin exact versions with a rehearsed upgrade step.
• You cannot staff a monthly patch window. A high-severity CVE in a patch release, plus upgrade-path bugs like the MySQL 8 migration failure, means unpatched or half-upgraded instances are a standing liability we would own end-to-end.
• You need a vendor-supported SLA. MIT community licensing only.

How to Pitch It (Stakeholders)

For executives: Concrete CMS is a long-established, MIT-licensed PHP CMS. It gives us production-grade content editing, page composition, permissions, and multi-site out of the box — capabilities that would otherwise be a multi-quarter build. The commercial risk is low (no license fees, no seat caps). The real costs are integration and operations: this is a full platform, not a library. Release 9.5.5 carried a high-severity security fix (CVSS 8.6), and 9.5.7 is a maintenance release that fixes bugs, tidies upgrade paths, and tightens the project's own security-advisory process — no new features, no breaking changes, no deprecations. The takeaway for the business case is unchanged: the question is not "is Concrete capable," it is whether we want to own a recurring patch-and-verify cycle, including rehearsing upgrades between patch versions, for as long as we run it.

For engineering: concrete5/core is a read-only subtree split of the concrete/ directory from the Concrete CMS monorepo, published for Composer. Treat it as a build artifact: not a standalone library, no dependents, stars are not a health signal. Any adoption decision must be made against the root repo's release and support policy. 9.5.7 is a maintenance release with no migration or deprecation signal that changes our evaluation. Three items are operationally relevant:

1. The Composer-audit install block is back (or was never fully gone). 9.5.5 was reported as fixing installs blocked when security auditing is enabled; 9.5.7 lists "Fixed Concrete CMS being unable to be installed by Composer (except by ignoring audits)" again. Keep composer audit in CI and add an explicit clean-install smoke test; do not rely on a single upstream fix to stay fixed.
2. Upgrade paths break between patches. 9.5.7 fixes an upgrade to 9.5.5 failing on MySQL 8 mid-migration. Pin exact tags and test the upgrade hop in a staging clone before touching production.
3. Upstream's own security hygiene is improving and is a pattern to copy. Advisories now require a stated reason when ignored, advisory checks run in a dedicated workflow, and inline designs read from a CIF are sanitized. Also worth noting: upstream added guidance for AI-assisted contributions (short code comments, no automatic commits) — relevant to our own policy if we ever contribute patches back.

None of this changes the underlying recommendation. Practically, this is only worth pulling in if we are building on or patching Concrete — it is not something we add to a Laravel or Symfony service. If we proceed, we pin an exact tag, mirror it, carry patches locally, and subscribe to security advisories.

Recommendation: Unchanged in direction, updated in detail. Keep this as a reference and patching surface while we evaluate CMS options; do not adopt the split as a dependency until we have decided the platform direction. 9.5.7 is a maintenance release — it does not alter the build-vs-buy calculus — but it does reinforce two operating requirements: (a) if we choose Concrete, consume it via the canonical distribution pinned to 9.5.7 or later (never 9.5.5, which has a known MySQL 8 upgrade failure), and (b) budget a non-trivial integration and operations track that explicitly includes security patching, clean-install verification with auditing enabled, and a rehearsed upgrade runbook between patch versions.