Flux des variables d'affichage de Concrete5:

Chaque requête effectuée sur Concrete5 passe par le fichier index.php de la racine de votre site web. Si le système utilise les URLs simplifiées, le module mod_rewrite d'Apache est charger du routage de celles-ci en tâche de fond.

Index.php reçoit donc la requête complète, et renvoie celle-ci sur dispatcher.php, qui se trouve dans le dossier de base de l'application (/concrete). Ceci de façon à ce que de multiples sites concrete5 puissent partagés un même dossier d'application sur un serveur donné.

Voici une liste de requêtes prises en charge par dispatcher.php :

## Startup check ##
require('startup/config_check.php'); 

C'est le tout premier objet lancé. Cela inclut certaines vérifications, dont celle de savoir si le fichier /config/site.php est disponible. S'il l'est, il l'inclut. Sinon, il règle une variable de façon à "dire" à Concrete que l'installation n'a pas été effectuée. Elle est donc utilisée plus tard, après que certaines librairies "cores" aient étés chargées.

## Load the base config file ##
require('config/base.php'); 

Ici nous chargeons toutes les constantes et réglages initiaux de Concrete, incluant les chemins. Ce fichier prend également soint d'inclure le chargeur de librairies, qui est utilisé pour charger les objets et les exporter.

## Load the database ##
Loader::database(); 

Concrete charge (mais n'y est pas encore connecté) la base de données. C'est réaliser à travers ADODB.

## Load required libraries ##
Loader::library('object');
Loader::library('model');
Loader::library('view');
Loader::library('controller');
Loader::library('block_view');
Loader::library('block_controller'); 

Concrete charge ses propres librairies cores requisent. Dans Concrete5, une librairie est une portion de code qui est utile sans être spécifiquement attaché au système de gestion de contenu.

## Load required models ##
Loader::model('area');
Loader::model('block');
Loader::model('block_types');
Loader::model('collection');
Loader::model('config');
Loader::model('groups');
Loader::model('package');
Loader::model('page');
Loader::model('page_theme');
Loader::model('permissions');
Loader::model('user');
Loader::model('userinfo');
Loader::model('version'); 

Concrete charge les modèles et les classes requis pour un rendu de page spécifique et les sessions. Les modèles sont directement reliés à la base de données, although there currently isn't much to them beyond a semantic definition.

## Default routes for various content items ##
require('config/theme_paths.php');
## Specific site routes for various content items 
(if they exist) ##
@include('config/site_theme_paths.php'); 

Ce bloc de code initialise les différents chemins internes pour les thèmes disponibles. Les chemins sont routés depuis les thèmes jusqu'au noyau de conrete. La gestion d'erreur est supprimée à la deuxième inclusion car ce fichier ne peut exister.

Note: Le répertoire de configuration existe actuellement à deux endroits - un dans le dossier de l'application, et un à la racine.

## Load session handlers
require('startup/session.php');
## Startup check, install ##
require('startup/config_check_complete.php');
## Load the site's database connection and library
require('startup/database.php');
## Set debug-related and logging activities
require('startup/debug_logging.php');
## run through user-related tasks
require('startup/user.php');
// Include Tools. Format: index.php?task=
include_frontend&fType=TOOL&filename=test.php
require('startup/tools.php'); 

Le bloc de code ci-dessus charge un certain nombre de sous-routines situées dans le répertoire startup.

1. D'abord, nous initialisons notre session.
2. Ensuite, nous vérifions, pour être certain, que l'application est installée. Configcheckcomplete inspecte la variable réglée par la routine config_check tout au début du fichier dispatcher. Si concrete ne peut pas trouver son fichier de configuration, config_check_complete va afficher le panneau d'installation et sortir du programme.
3. Après vérification de notre configuration, nous nous connectons à la base de données.
4. Puis, nous réglons notre serveur SQL et l'affichage des erreurs. Ceci est séparé de la connexion - ça détermine basiquement quand et quelles erreurs seront affichées à l'écran, principalement en mode verbeux, et affichera aussi les requêtes SQL. Ceci est réglé dans le tableau de bord.
5. Maintenant, nous chargeons nos classes d'utilisateur. Si l'utilisateur est connecté nous rafraîchissons sont paramètre uLastOnline.

6. Finallement, ce bloc de code initialise les requêtes sur le répertoire /tools. Les outils (Tools) sont des fichiers Php statiques qui éxécutent certaines fonction interne de l'interface de Concrete. Ils s'éxécutent, eux aussi, à travers le fichier dispatcher.

    // figure out where we need to go
    $cPath = $_REQUEST['cPath'];
    if ($_REQUEST['cPath'] != null) {
    $cInfo = '/' . $_REQUEST['cPath'];
    $c = Page::getByPath($cInfo, false);
    } else {
    $cInfo = (int) ($_REQUEST['cID']) > 1 ? 
    $_REQUEST['cID'] : '1';
    $c = Page::getByID($cInfo, false);
    } 
   

Ce code évalue la requête courante, et détermine comment en obtenir un objet de la page. Si nous passons un cID (qui est lié à Collection/Page ID), notre requête est numérique, utilisant la méthode getByID de la classe de la page. Si nous passons quelque chose à travers une requête sur la variable cPath, alors nous utiliseraons la méthode getByPath de la page.

if ($c->isError()) {
     // if we've gotten an error getting information 
     // about this particular collection,
     // then we load up the Content class, and 
     // get prepared to fire away
         switch($c->getError()) {
         case COLLECTION_NOT_FOUND:
         $v = View::getInstance();
         $v->render('/page_not_found');
         break;
         }
         } 

Ceci vérifie la Page pour voir si son initialisation retour un code d'erreur. Si c'est le cas, il ne peut y avoir qu'une seule chose à ce stade - un manque de page complet. Nous le vérifions donc, si la page est réellement manquante, nous affichons la page “404” de concrete5.

Note: Ces constantes d'eereurs sont définies dans /config/base.php

## Check maintenance mode
         require('startup/maintenance_mode_check.php');
         ## Check to see whether this is an 
         ## external alias. If so we go there.
         include('startup/external_link.php'); 

Arrivé à ce stade, nous vérifions si le site que nous voulons lancer est en mode maintenance ou non. L'activation de ce mode est contrôlé dans le tableau de bord. S'il est activé, le tableau de bord est accessible aux administrateurs, mais pas le site.

Ensuite, nous vérifions si la collection que nous chargeons correspond à un “lien externe.” Un lien externe étant un lien HTTP pointant sur un ressource externe, comme “http://www.google.fr” ajouté via le tableau de bord, les liens externes sont utiles pour ajouter des ressources externe dans la structure interne du site, comme les blocs de liste de page ou navigation automatique.

         ## Get a permissions object for this 
         ## particular collection.
         $cp = new Permissions($c);
         ## Now that we have a collections and 
         ## permissions object, we check to make sure
         ## everything is okay with collections and permissions
         if ($cp->isError()) {
         // if we've gotten an error getting information 
         // about this particular collection,
         // then we load up the Content class, and 
         // get prepared to fire away
         switch($cp->getError()) {
         case COLLECTION_FORBIDDEN:
         $v = View::getInstance();
         $v->render('/page_forbidden');
         break;
         }
         } 

Si nous arrivons jusqu'ici, nous essayons alors d'obtenir une page valide. Nous allons donc passer cet objet au dispositif de permissions, qui renverra un objet Permissions pour celui-ci. Enfin, nous vérifions cet objet permissions pour voir si aucune erreur y est associée. S'il y en a, c'est que nous essayons d'atteindre une page à laquelle nous n'avons pas accès. Dans ce cas, nous affichons une page 403, ce qui consiste généralement à vous re-diriger vers la page de connexion.

## If there's no error, then we build the collection, 
         ## but first we load it with the appropriate
         ## version. We pass the function the collection 
         ## object, as well as the collection permissions
         ## object, which the function will use to determine 
## what version we get to see
if ($cp->canWrite() || $cp->canReadVersions()) {
         $cvID = ($_REQUEST['cvID']) ? $_REQUEST['cvID'] : 
         "RECENT";
} else {
         $cvID = "ACTIVE";
}
if ($_REQUEST['ccm-disable-controls'] == true || 
intval($cvID) > 0) {
         $v = View::getInstance();
         $v->disableEditing();
} 

Cette portion de code est chargée de déterminer si nous devons ou non chager une version particulière de la page, et, si oui, savoir si nous devrions désactiver l'édition (l'édition des anciennes versions étant désactivée).

$vp = $c->loadVersionObject($cvID);
// returns the $vp object, which we then check
if ($vp->isError()) {
     // if we've gotten an error getting information 
     // about this particular collection
     // then we load up the Content class, and 
     // get prepared to fire away
     switch($vp->getError()) {
          case VERSION_NOT_RECENT:
          // the collection is not the most recent version. We're 
         // not going to allow any writing to the collection
         $cp->disableWrite();
         break;
     }
} 

La gestion des versions continue, l'édition est désactivées pour les anciennes versions.

## Make sure that any submitted forms, etc... 
## are handled correctly
## This is legacy cms specific stuff, like adding pages
require('startup/process.php'); 

Le fichier process.php est un gros fichier qui détermine si certaines actions doivent êtres lancées, basé sur les variables POST et REQUEST. Process.php est le fichier qui prend en charge toutes les opérations du CMS exécutées Concrete.

## Record the view
$u->recordView($c); 

Cette portion de code enregistre une entrée dans la table des statistiques.

## now we display (provided we've gotten this far)
$v = View::getInstance();
$v->render($c); 

Cette portion de code finale prend en charge le rendu de la page. La méthode de rendu est responsable de la déconnection de la base de données, autant que de l'affichage des requêtes SQL si le niveau de débogage est assez haut.