Weave Code
Core Laravel Package
concrete5/core
The core of Concrete CMS (formerly concrete5), an open-source PHP content management system. Includes MVC architecture, blocks, themes, permissions, in-context editing, and extensibility for building and managing websites.
concrete5/core is the open-source content management system that powers Concrete CMS—a PHP application built on modern libraries like Doctrine, Symfony components, and Laravel's Illuminate database layer. It ships with a full MVC architecture, a block-based page editor, and a marketplace-ready package system.
- In-context editing with drag-and-drop blocks and inline rich text.
- MVC architecture with routes, controllers, and service providers.
- Package & theme system for extending or distributing add-ons.
- Granular permissions and built-in user/group management.
- CLI tools via the included console for migrations and maintenance.
Frequently asked questions about Core
- Can I install concrete5/core in a Laravel application with Composer?
- No. concrete5/core is the extracted concrete/ directory of Concrete CMS, a full-stack PHP application framework, and it is not a Laravel package in any meaningful sense: there is no service provider and no Laravel integration layer. You cannot composer require it into a Laravel app and use it the way you use a normal package. Install the concretecms/concretecms distribution as its own application instead.
- What is the difference between concrete5/core and concretecms/concretecms?
- concrete5/core contains only the concrete/ tree: bootstrap, routing, its own DI container, Doctrine-based persistence, permissions and the page/block content model. concretecms/concretecms composes that core with the application/ configuration, the public/ front controller and the directory scaffolding needed to actually run a site. Consume the distribution package; this split repo is a read-only artifact of the release process with around 20 stars and zero dependents.
- Does concrete5/core work with Laravel's service container and service providers?
- No. Concrete CMS owns its own DI container, service-provider lifecycle, router and Doctrine persistence, and it does not resolve Laravel's container or register Laravel service providers. There is no supported configuration that makes the two frameworks share a process cleanly. Treat them as separate applications rather than composable libraries.
- Does Concrete CMS have a REST API I can consume from Laravel?
- Yes. Concrete CMS ships a supported first-party REST API, and release 9.5.5 includes many REST bug fixes plus an additive Page API transformer change for date_public. It is a genuine integration contract path, but the volume and nature of the fixes (double block updates, field clobbering, transformer gaps) show the surface is still stabilizing. Version the API contract explicitly and exercise read paths before write paths.
- How should I deploy Laravel and Concrete CMS together?
- Run Concrete CMS as a separate service behind a reverse proxy, mounted at /cms or a content subdomain, with its own front controller, Composer root and deploy unit. That is the only pattern where the two frameworks' opinions do not have to be reconciled. A Laravel-fronted route handoff also works, but you inherit two routers, two session configurations and two CSRF regimes on a single origin, which makes the boundary the most fragile part of the system.
- Can Laravel and Concrete CMS share a single Composer root and vendor directory?
- Do not do it. Release 9.5.5 explicitly fixes a concretecms/monolog-cascade incompatibility with symfony/config v6.4.44, which is exactly the dependency skew a shared vendor directory produces. Keep separate Composer roots per application and treat version alignment as an interface rather than a shared lockfile.
- Can I use Eloquent models against Concrete CMS's database?
- Not viably. Concrete's schema is large and structurally idiosyncratic, with collections, collection versions, per-block-type bt* tables and per-attribute-type at* tables, so Eloquent models would be a read-only, best-effort reporting layer at most. The REST API supersedes this approach entirely for interop. If you need reporting, replicate the data into your own schema on a schedule.
- Which Laravel versions does concrete5/core support?
- There are no Laravel version constraints to check, because the package declares no illuminate/* dependencies and is not a Laravel package. Its composer.json constrains PHP and Concrete's own libraries only, so Laravel version support is not a meaningful axis here. Compatibility questions belong to how you deploy and talk to Concrete CMS, not to its Composer metadata.
- How do I test a Laravel app that integrates with Concrete CMS?
- Test the boundary, not the internals: run Concrete CMS as its own container or service in CI and exercise the REST API contract from Laravel's test suite. Assert on response shapes and versioned endpoints, and cover read paths before writes given the recent double-write fixes. Avoid booting Concrete inside Laravel's test kernel, since two bootstraps in one process is the fragile pattern you are trying to avoid.
- Is concrete5/core actively maintained and safe to depend on in production?
- The upstream project is healthy and densely maintained, with release 9.5.5 carrying dozens of fixes and a large contributor volume. The split repo itself remains a read-only artifact with around 20 stars and zero dependents, so do not take a direct dependency on it for a production install; verify its tags track the distribution package's tags and pin forward. Also note that 9.5.5 fixed a case where installing Concrete via Composer was impossible with security auditing enabled, so plan Composer audit behavior in your pipeline.
Weaver
How can I help you explore Laravel packages today?