The following terms are used in Concrete CMS to describe the front-end content of a website. This is content that you see in a web browser when viewing a page.
In Concrete, a site is a collection of Pages. These pages are arranged into a Tree – every page except the home page has to have a parent page. The entire site tree is viewable through the Sitemap page in the Dashboard. The Dashboard is the back-end or back office to Concrete. Generally, content-related changes to your website happen right from the page where the content is located, and site-wide administrative actions like adding users or managing files happens from within the Dashboard. The Dashboard is protected by permissions.
Every Concrete site must have an active Theme, which maps to a directory on the server that houses template files, CSS, JavaScript, images and all other assets needed to render HTML. A theme directory contains PHP files that map to Page Templates. A page of a certain template will be rendered using that page template's PHP file in the active theme directory. Themes may optionally include a PageTheme class file that can describe various aspects of the theme, including whether it conforms to a particular Grid Framework. Themes may be marked as customizable, and may contain different style presets and assets.
A page template will likely contain PHP code that creates one or more Areas on the page. In Concrete, an area is a section on a page where a user may use the CMS to place Blocks. An area may be a regular area or a Global Area. A block added to a global area appears on every page that displays that global area, while a block added to a regular area only appears on that particular page. Blocks are added to areas in context, on a particular page, through simple and intuitive drag and drop. Every area on a page may house one or more blocks.
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. The block's Block Type determines how those blocks differ. Types of blocks include HTML content, slideshow, form, page title, survey, a navigation list, and more. While many blocks are static, they can also be interactive. Block types 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, or inline in the page themselves (if a block type supports this). Block types can easily be added by a developer. In addition to the default presentation layer (view) for each block type, a block type may also have multiple additional Custom Templates. These are additional presentation layers that can be swapped out through the CMS in edit for a particular block instance on a particular page.
Adding a new block to a page area isn't the only way to get content onto a page. The add panel also contains the ability to drag and drop blocks that have been previously pasted in to a user's Clipboard, or blocks that have been added to Sitewide Stacks. Stacks are collections of blocks that may be managed centrally in the Dashboard. Entire stacks can be dragged into a page, and will respect the version history and permissions of the Stack as managed in the Dashboard.
In addition to blocks, pages also may have Page Attributes attached to them. Page attributes are bits of data about the page, as opposed to viewable content displayed on the page. Examples of attributes include "Exclude from Navigation," "Meta Page Name," "Meta Keywords," "Blog Entry Topics."
Editing any block in Concrete will create a new version of the Page, and these Versions can be rolled back. Since these versions are essentially just collections of blocks and attributes, some Concrete literature will refer to Collections and CollectionVersions. As an object, Pages extend from the Concrete Collection object – but there isn't much that can be done with the Collection object by itself.
In addition to a page template, a page may be of a certain Page Type. A page type describes the classification of a page and doesn't convey any presentation information intrinsically. Examples of page types include "Basic Page," "Blog Entry," "Portfolio Project," "Portfolio Listing," etc… Pages of a certain type can be configured to only allow their creation in a particular set of page templates. Most pages in a website will have both a page type and a page template. End users may add pages of a certain type through the CMS to any part of their website. Every page type and page template combination can have Page Type Defaults. These are editable through the CMS and allow administrators to place default blocks in areas on a specific template for a specific page type. These blocks will then be automatically aliased to new pages created with this type and template.
Additionally, a page type also has a Composer interface. This interface is editable within the Dashboard, and allows an administrator to create a multiple Composer Form Layout Sets, which can contain multiple Layout Set Controls. Examples of Layout set controls include core page properties like "Page Name," "Page Template," "Page URL Slug", or instances of page attributes and blocks in edit mode. A composer interface is capable of being a completely form-based way to create a Concrete page (as opposed to in-context editing mode.) When adding a page of a certain type, the CMS user will either be shown this compose form or they will be immediately forwarded to the new page in edit mode. At this point, the page is a Page Draft since it has not yet been published. Page drafts exist in a special area of the Sitemap, not in the public site itself. In order to be publishable, a page draft must have a Page Target that has been chosen for it. Different page types may specify different page targets. For example, pages of some type may be publishable anywhere in the site, in which case users may choose a target parent page from the sitemap. Pages of other types may only be able to be published under pages of other types (an example being Blog posts publishable under only Blog Category page types).
Some pages aren't meant to be reusable or addable through the CMS, but still should exist in the Sitemap, since administrators may want to apply permissions to them, change their attributes through the CMS or add blocks to them. Examples of these include the Login page, or the entire Dashboard of Concrete. These pages are Single Pages. 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 not published in the same way – they are simply registered through the Single Pages section in the Dashboard. Single Pages are nice because they can be added directly to the filesystem, and, once installed, exist at their explicit path. Generally it's a nicer practice to use single pages where you know a particular page will only be needed once.