Concrete5's documentation and comments refer to a number of internal conventions that, when learned, should make concrete5 more accessible to developers and end users alike.
At a summary level: Every Page has editable Areas, defined by its Page Type. Areas contain instances of Blocks (defined by Block Types) which may be anything from editable HTML to a highly customized survey. Each Page has its own Permissions and a Theme associated with it. Themes contain Template files that determine presentation for a given Page Type.
A page in concrete5 is just like a page on any website: it typically fills the full browser, and be found at a unique URL. Pages in concrete5 can have pretty URLs or standard CMS-y URLs. For example, the following URL maps to the same article on concretecms.com:
Every page has a unique cID ("c" stands for Collection -see below:) and a bunch of metadata about it in the Pages table.
There are some exceptions to this Page=Collection rule, some standard pages like login and register are called "Single Pages" and exist in their own directory in a concrete5 install. They are still skinned through the CMS, see the bottom of this page for more explanation of the exceptions.
Areas in concrete5 are parts of a particular page that can be edited using the content management system. Without any areas, a page would be completely static. Areas can have permissions applied to them, making it so that only certain kinds of blocks may be added to them, or they can only be viewed by certain people.
Blocks are bits of content added to particular areas on pages. A block is an instance of a certain type of content, as displayed on a page. When in edit mode, blocks may be hovered over with a mouse, clicked on, and edited within the page itself. All blocks have certain bits of data in common, like the ID of the user who added them, or the date the block was created and modified.
A block is the instance of content or functionality after it's been added to a page. The type of block determines how those blocks differ.
Types of blocks include:
- Some HTML content
- An in-page image gallery
- A navigation list
- A list of popular pages on a site
- A survey or poll
All of these are types of blocks. When a block type is installed, an administrator is able to add that type to an area on a page. When adding a survey to a page, for example, the survey is a block type, and the actual survey added to the page, with its customized questions, answers and results page is the actual block itself.
Blocks are typically self-contained, and blissfully ignorant of other items on a particular page. Every type of block has its own presentation layer, a form that gets called when it's being added, and a form that's called when it's edited. These forms are typically displayed in in-page popups dispatched by Concrete's interface layer. Developers interested in writing their own block types should check out the [[.:developers:developing blocks|blocks section of the developers manual.]]
Like block types, concrete5 also has the concept of "page types." A page type is a template and convention allowing different types of pages to be added in different areas of a website. Page Types are typically named and considered around functional requirements, rather than layout requirements. For example, here is a list of page types that might be found in a corporate website:
- Home - A page type corresponding to the main home page of the site
- Landing - A page type corresponding to one of the main sections of the site
- Detail - A detail article page type
- Press Release
- News Article
Page Types are typically made only for reusable pages (home is the one notable exception to this rule.) Single, one-off pages are described in "single pages" below.
Themes are the outer graphical skin of a concrete5 website. Separate from page types and single pages, themes allow the same types of pages to appear differently in different areas of a website. For example, an article within the sports section of a newspaper's website could have a completely different theme than an article page in the finance section. For more information about themes, see Developer's Guide: Themes.
Page & User Attributes
While all pages and users have data that's associated with them, Concrete allows site administrators to create their own bits of data and associate these with pages and user accounts. These are known throughout Concrete as "attributes." Example of page attributes might be:
- "Exclude From Nav?" (check box)
- "Meta Keywords" (text field)
- "Additional Description" (text box)
Examples of user attributes:
- "Gender" (radio button w/Male and Female available)
- "State/Province" (select menu)
Users are accounts used to edit a concrete5-enabled site. At its core, a user record in concrete5 consists solely of an ID, a unique username, and an email address. Extended user attributes can be added in the dashboard.
Groups are simply a way of combining users into a particularly semantic...well...//groups!// Groups are used primarily in concrete5 permissions: a given group of users can be allowed read, edit, delete, and administrative access to pages, areas and even individual blocks.
Interested in developing for concrete5? You probably ought to understand the following concepts, in addition to those above:
In versions of Concrete before concrete5, Collections mapped entirely to Pages (see above.) Collections were so-named because they were "collections" of blocks. However, in concrete5, a collection can exist without a record in the Pages table, and thereby group blocks together without having any presentional aspect to it, or appearing in the sitemap. Furthermore, these collections can be called programmatically, which can be helpful for programmers who want to use the power and flexibility of built-in blocks programmatically, without having to worry about where a page lives, its permissions, etc...
Single pages are Page records that don't have a page type. Instead, they're one-off pages that map directly to a file in the filesystem. These are nice because they can be added directly to the filesystem, and, once installed in the dashboard, exist at http://www.yoursite.com/pagename/. Generally it's a nicer practice to use single pages where you know a particular page will only be needed once. Examples of single pages automatically created by the system include:
- Various dashboard pages.
Single pages use Concrete's Model-View-Controller, which makes them useful when using concrete5 as an application platform.
The AttributeKey object is the concrete5 object that holds information about a particular attribute. Any time you use concrete5 create a new attribute for a user, page or file, you're creating a new AttributeKey object.
Every attribute key also has an attribute category. The attribute category is the object that it is bound to. Built-in page attributes like "Meta Title" and "Exclude from Nav" have an attribute category of "page." File attributes like "width" and "height" are part of the "file" attribute category. Every category of attribute keys has an object that extends the AttributeCategory object. Those who want to use the built-in attributes for their own objects will need to understand the attribute category object.
Finally, every attribute key must also have a type. The AttributeType object determines the way that the attribute key presents and stores its data. Attribute Types include objects like "Rating", "Textarea", "Number", etc... Those who want to extend the attributes system to store new types of data, or customize the presentation layer for existing attributes will need to understand the AttributeType object.Update