The default installation of Concrete in setup in the following manner. (The root directory in these examples corresponds to the root of your Concrete5 website. These examples also assume you are running one website, and not sharing the Concrete5 core amongst several sites.)
Client Application Contents
These are directories directly within your web root.
This directory contains block types used throughout your Concrete5 site. This will typically be empty on an initial installation - core block types are installed inside the concrete directory.
This is the Concrete Application directory. Concrete5 owns these files - they should typically be off limits in most projects. For more information about what's inside this directory, skip down to Concrete5 Internal Contents
This directory contains “site.php,” the configuration file added by the Concrete5 installation program. This stores your database connection settings and some server-specific information. Additionally, this directory contains “site_theme_paths.php,” which allows a developer to manually specify certain themes for certain areas of a site. Click here for more information about site_theme_paths.php
The controllers directory contains controllers for any single pages, views or dashboard modules used by your website. Click here for more information about controllers and Concrete5's MVC syntax.
The elements directory is a place for you to keep snippets of PHP code reused throughout your site. Examples of this might include a header menu or a reused sidebar. Elements are presentational in nature; if you have special functions or libraries you want to reuse for your website, these should go in ”/libraries” or ”/helpers.”
The files directory holds all files added by your user's through the CMS. Additionally, the files directory may hold cache information or logs.
The helpers directory store reusable functions based on the type of assistance they provide. You can include your own helpers in your helpers/ directory, as well as use helpers that come with Concrete5. A complete list of Concrete5 helpers is available here.
The difference between helpers and libraries is largely a semantic one. Helpers are typically smaller in scope, and assist in one specific purpose, while libraries serve an underlying purpose. For example, Concrete5 ships with a “feed” helper. This feed helper exposes a couple of methods for the parsing of RSS and ATOM feeds; it is the public accessor to this functionality. However, the feed helper itself is really just a simple gateway to the very nice SimplePie library, which itself is contained in “concrete5/libraries/3rdparty/simplepie.php.”
The mail directory contains mail templates that your site uses, in conjunction with the Mail Helper.
Items in the models directory correspond to database-backed items in your custom Concrete5 application. For example, if you added a “properties” table to your database, you'd need a PHP class for querying this information. In Concrete5, you'd add “property.php” to your models directory. Models are mostly optional, but if your model extends the Model class (loaded by the Concrete5 core), you'll be able to use ADODB Active Record syntax to query it.
Single pages - one-off pages like /login, /register, etc… - live in here. They inherit the active theme, and can have their view templates overridden by templates in a given theme directory. Single pages are most useful when paired with Concrete's MVC syntax.
Directories corresponding to your site's theme live here. Concrete5 ships with a default theme, but you can add your own theme to this directory and activate it in the dashboard.
Tools is a catch-all directory for other PHP scripts that you might need to integrate with Concrete5. These scripts are wrapped in Concrete5, and have access to the database and everything else, but aren't wrapped in Concrete5 permissions, have no MVC support, etc…
Concrete5 Internal Contents
These are the items inside the ”/concrete” directory, typically off limits to all but the most wizened or foolish developers.
Concrete's internal configuration directory, and it contains the main installation database file, as well as some constants that rarely change.
This contains presentational stylesheets used by the content management system, including its menus, dialog boxes, the dashboard and rich text editor.
The main runtime of the program, dispatcher.php is responsible for parsing every request to Concrete5.
This contains flash assets used by the CMS, including a flash uploader, image thumbnailer, etc…
This directory contains Concrete5's core helpers. Application helpers should go into their webroot.
This directory contains images used by Concrete5's interface components.
The core libraries directory contains libraries used Concrete5. These include some relating to Concrete5's MVC syntax, as well as some third party libraries used by various components of the system.
Most of Concrete5's internal CMS components keep their data access classes within the models directory.
The packages directory contains directories corresponding to various “packages” available to the system. These are so named because they can be deployed to all Concrete5 websites on a given server (if those websites all share the same core libraries.) Individual sites can also make use of packages as well, by copying them into the packages directory and installing them. Packages can include single pages, blocks, elements, dashboard modules, controllers, mail templates and themes. At this time, the only package available is the core package, which is responsible for setting up the default Concrete5 theme, its login/registration process, the dashboard, and the block types which ship with the system.
Items within the startup directory are subroutines included during a page load by dispatcher.php
The items within the tools directory are interface components used by the content management system. These include popup windows, etc…