In Concrete CMS 8.5.x and below, we don’t make any opinionated decisions about how themes should behave, what assets they should include, etc… Yes, since we include Bootstrap 3 with the core for the editing toolbar and the Dashboard, it’s become pretty common to use Bootstrap 3 as the building block for a theme, but it’s not required. We do define grid frameworks, but we have several of them.
In Version 9, this has changed a little bit. No, we’re not going to mandate that themes be built a certain way. But if a theme builds on Concrete Bedrock (which is really just a superset of Bootstrap 5) then that means all the default blocks will look really nice in it, and shared elements in the Containers and Boards model will look great as well. Marketplace developers can even build standalone templates for features and boards that utilize the markup Bedrock supports, and any user who has a theme that takes advantage of it will know that the templates will be nice and interoperable.
Definition: Concrete Bedrock
Bedrock is a list of third party libraries like Bootstrap 5, jQuery UI, jQuery, Vue and more, coupled with custom SASS and JS/ES6 code from the core. It is installed via npm, and in turn installs its dependencies via npm. It is the bedrock of the three different domains in Concrete – the frontend, the CMS and the backend.
The Concrete, Dashboard and Atomik themes that ship with Concrete CMS 9.0 are built on Bedrock. Additionally, Bedrock contains the minimal asset for all features that ship with the core. If functionality ships with the core (like the Calendar), there needs to be a minimal version of its required assets that also come with the core. A theme could enhance or supersede that functionality, but if it doesn’t, and the core needs to employ that functionality, the minimal JS and CSS provided by the Bedrock will be used.
- To make it easier to build Concrete themes: all the assets necessary are delivered together, bundled in sensible ways, and easily includable. Just include the asset bedrock in your Concrete theme project, and import JS and SCSS files into your theme files.
- To improve performance: we’re cutting down on extraneous view.js and view.css files in the core.
- To add flexibility: themes can specify exactly what features they provide specific support for, and let the asset fallback work in the core for those they don’t support.
In all previous versions of Concrete, Concrete’s CSS and JS code is contained within the main Concrete project repository. In later versions of Concrete, much of this code was separate out into a separate build folder, so it could be minified and compiled before delivery. This even included third party dependencies like jQuery.
In version 9, we've moved our entire asset system into npm, so it can be included in the core as though it were a third party dependency. The main reason for this? Third party theme developers can also include it in their themes as a dependency, making it easier to include the Bedrock without a lot of copy and pasting, and without having to also install the entire specific version of a Concrete CMS core in order to start working on a specific theme.
Let's get started!