Advanced Concepts


Let us know by posting here.

How a Page is Built

In Concrete CMS, your website is structured as a hierarchy of pages organized within a sitemap. Each page adheres to a specific Page Type and utilizes one of its associated Templates. These Templates are PHP files that combine standard HTML/CSS with dynamic Block Areas. Within Block Areas, you can insert Blocks, which range from basic HTML Text to advanced interactive features like forms. Block Areas can be further refined using Layouts or Containers. While Layouts simply split a block area into columns, Containers are code-defined and can encompass additional markup and styling.


In Concrete CMS, a File typically references the core object used to represent media uploaded through the Dashboard's file manager or its overlay during website content editing. Such files might be inserted in image blocks, linked within a rich text editor, or provided for download via the file block.

Every uploaded file is associated with a specific File Type (e.g., JPEG, DOC, MPEG), which in turn corresponds to a Generic Type like "Image" or "Audio." For organization or specific functionalities, files can be categorized into File Sets, with a single file potentially belonging to multiple sets. Files also exist within Folders in the file manager. Files are linked with File Attributes such as "Width" or "Height." Whenever there's a change to a file's attributes or core properties, a new Version of the File is created.

Internally, the File object serves as a container for the active version, which has the attributes. This active version then points to the actual FileRecord—the reference to the physical file. Notably, files in Concrete CMS can reside in multiple File Storage Locations, including external ones like Amazon S3. The FileRecord ensures proper retrieval of the file, irrespective of its storage location.

On file import, via the Importer class, files might pass through an optional Inspector. This PHP class can execute additional operations on specific file types during upload or rescanning. For instance, image files undergo width and height scanning through the image inspector. This process also generates file Thumbnail entities based on predefined Thumbnail Image Types. Different thumbnail types can be configured in the Dashboard, allowing for functionalities like retina imagery, responsive image thumbnailing, and more.

Users, Groups & Authentication

In Concrete CMS, Users are accounts designated for site editing. A user record primarily consists of an ID, unique username, and email address. Users can be linked to User Attributes, which store additional account details. Every Concrete site must have an admin user, with user ID 1, holding complete permissions. Users sign into Concrete via an Authentication Type, like built-in Concrete authentication or third-party methods like Facebook or Twitter. Developers can introduce new authentication types.

Groups in Concrete group users together, primarily for permissions. Through groups, users can be granted permissions like reading, editing, or deleting pages, areas, and blocks. Advanced permissions in Concrete support Combination Groups, allowing permissions for users in multiple specific groups. Group Sets let administrators manage groups collectively.

Every user can access the My Account section, allowing password changes, private messages, and user attribute adjustments. Administrative or Dashboard access isn't required for this. Public User Profile pages can be enabled to showcase public user attributes.

Concrete's user profile features make it ideal for community sites. It supports User Points, where users earn points manually or through site activities, and Badges—groups with visual representations and potential points, listed on user profiles. Automatic group assignments can award badges based on community involvement.

Permissions & Workflow

Concrete CMS has a strong permissions system. While most of its depth is hidden by default, users can turn on advanced features from the Dashboard's Advanced Permissions page.

Concrete uses a Permissions Checker class, often seen in code as the "Permissions" class. Developers use this class to check permissions:

$c = Page::getByPath('/path/to/page');
$pc = new Permissions($c);

Here, the Page object is the Permission Category. Developers can add new categories for different needs. The "Permissions" class helps get details from the Permissions Response, which tells us if we have permission access. When checking a permission, its Permission Key is pulled from the database, getting a Permission Assignment for that key and permission object. This tells us what kind of access we have and for how long with an Access and an optional Duration object.

When setting a permission, administrators are linking it to an Access Entity. Most of the time, these are users or Groups. But they can also be conditions like only allowing the creator of a page to view it.

Workflow is another key part of Concrete. Any permission key can start a Workflow, and administrators can pick which workflows are triggered by that permission. When a workflow begins, the Workflow Request is saved and not acted on until the workflow ends. There are different kinds of workflows, like the basic one-step or the more advanced multi-step. As a workflow goes on, the Workflow Progress object keeps track of it, connecting the Workflow type to the workflow object and the final Request object.


Attributes apply to Pages, Users, and Files in Concrete CMS. They can also be grouped togehter into their own objects using Express. While they can be used by these objects, they aren't bound to them. Concrete uses an Attribute Category to link attributes to these objects.

Attribute Keys define details for an object, like "Meta Name" for a page or "Width" for a file. Creating attributes in the Dashboard means adding a new key.

Keys vary in display, like text inputs for "Meta Name" or checkboxes for "Exclude from Nav". They're grouped into Attribute Types based on their function and look, which are sets of codes added or registered by users.

Attribute Values connect attribute keys with their data. Objects typically have a method, like getAttributeValueObject, to access this linked data.


In managing a Concrete website, sometimes lengthy maintenance actions are needed, such as clearing cache or regenerating sitemap.xml.

Tasks represent these actions. They can be initiated from the Dashboard or command line, scheduled, logged, and even batched in queues.


In Concrete CMS, a Package is a set of components with a PHP Controller that defines its properties and behaviors. It streamlines the installation or removal of features, and bundles both code and content. Marketplace-delivered themes or add-ons come as zipped Package files. Starting Point Packages offer sample content, residing in a distinct directory with a content.xml, but largely mirror regular Packages.


Concrete CMS uses various storage locations for configuration data through Config loaders and savers. Most values are stored in the filesystem with FileLoader and FileSaver, but database options are available. ConfigRepository manages these values using the Config facade class.


Assets in Concrete refer to JavaScript or CSS files. These can be grouped as Asset Groups. Instead of using file paths, you can use group names for better flexibility. Assets have version control to prevent conflicts and can be minified or combined for efficiency.


Developers can tap into Concrete's Events. These events activate at specific moments, allowing custom code execution. Developers can also initiate their own events.

Views & Controllers

Concrete follows the Model-View-Controller approach. Items come with their own Controllers and Views, like blocks, attributes, single pages, and more.

Service Providers & Core Classes

Service providers are PHP classes not tied to Concrete's specific objects. Registered at startup, they're accessible via Concrete's "Core::make()" function and can be adjusted by custom code. Examples include "\Concrete\Core\Mail\Service", initiated with Core::make('helper/mail').


Concrete adopts Symfony2's Routing Component to set various user interface routes. Custom code can register these routes, accessible via a browser, which can trigger a PHP closure or a specific Controller method.

Database & Database Manager

The DatabaseManager class manages multiple database Connection objects. Configurations enable automatic connections. The global Database facade gives access to the current connection with \Database::get().


Facades are static classes linked to actual implementations. These can be adjusted as needed. Concrete examples are "Image", "Config", "Database", and others.