General Concepts

Edit

Improvements?

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.

Files

In Concrete, 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 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, 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 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

Attributes apply to Pages, Users, and Files in Concrete. 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.

Packages

In Concrete, 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.

Advanced Concepts

See the Advanced Concepts page for a high level description of other Concrete concepts.