Views: 14521
Last Modified: 29.03.2023
  • Site Template
  • Page Structure
  • Page Templates
  • Page Properties
  • Parameters
  • Execution Procedure
  • Site Template

    The synonyms of the term site template are: "site design" or "site skin". Several templates may be used to display a site. The site template includes:

    • set of files in the catalog /bitrix/templates/site template ID/
      where site template ID - the "ID" field in the site template edit form ("Site template" admin menu item). Below is the structure for such catalog:
      • header.php - template prolog;
      • footer.php - template epilog;
      • styles.css - styles content and included areas. These styles can be applied in a visual editor;
      • .menu type.menu_template.php - template for corresponding site settings menu;
      • chain_template.php - default template for showing navigation chain;
      • /components/ - catalog with components belonging to a specific module;
      • /lang/ - language files for both this template and individual components;
      • /images/ - catalog with images for this site template;
      • /page_templates/ - catalog with page templates and their description stored in the file .content.php;
      • as well as other auxiliary and arbitrary files included into this template.

    You apply a specific template to site in the site settings form, inside Templates section. You can use various conditions to apply a template.

    If section property "phone" is "Y"


    If current section is "/en/catalog/phone/"


    If current user - administrator


    Note. You can connect prolog/epilog at the page without template:


    You can enter your code between these connections.

    The site template is also can be selected by calling CSite::GetCurTemplate. Its algorithm can be described as follows:

      All site templates are chosen in the following order:
    • those containing the PHP condition (the highest priority);
    • sort weight (the less is the value the higher is the priority);

      Thus, templates containing either the PHP condition or the less sort weight value, will have the highest priority.

        Then, the loop iterates on all the chosen templates. If the template contains the PHP condition, it is evaluated and if the result is "true", the path /bitrix/templates/site template ID/ is checked for existence. It this path exists, the loop breaks and the function CSite::GetCurTemplate returns this site template ID. In case none of the templates could be matched, the default template .default.php is returned.

      When specifying the PHP condition, it should be considered that the check is implemented by the function which has its own scope of variables. That's why the global variables should be specified by using the array $GLOBALS, the request variables - through the array $_REQUEST (or $_GET, $_POST) etc.

      The current site template is determined at the end of the prologue service section (prolog_before.php). Hence, the following can be used:

    • $APPLICATION object of the CMain class;
    • $USER object of the CUser class;
    • all the system constants of the type A;
    • all the standard PHP arrays: $GLOBALS, $_REQUEST, $_SERVER, $_SESSION, $_ENV, $_COOKIE etc.
    • When specifying the PHP condition for choosing the site template, it should be considered that the use of section properties is allowed, while page properties are not allowed. This is because the section properties are stored in a separate file .section.php, and the page properties are specified usually in a page body, after the including the prologue service section.

      Note: In the public section, the current site template ID is stored in the constant SITE_TEMPLATE_ID.

      Page Structure

      A Page is a PHP file consisting of a prolog page body (main working area), and epilog:
      • header
      • workarea
      • footer

      A site page is formed dynamically based on the page template used, data retrieved by the components, and the statistic information located on the page. The creation of site templates and the allocation of components in them are taken care of by site developers.

      Generally all site pages have the following structure:

      • Top – header. As a rule, includes the top and left part of the design with a static information (logo, slogan, etc.), top horizontal menu, and left menu (if they are stipulated by design). Dynamic informational materials may be included.
      • Main working area – work area. The page working area where the proper informational materials of the site are located. Both a physical file and a dynamic code created by the system based on complex components may be connected as the Main working area.

        If a physical file is connected as the Main working area, such a page is called static. If a dynamic code is connected, such a page is called dynamic.

      • Bottom – footer. As a rule, includes a static information (contact details, information about author and owner of the site, etc.), low horizontal menu, and right menu (if they are stipulated by design). Informational materials may be included.

      Note: For more details about the page structure, see the lesson Design Template.

      Top and bottom parts of the design are formed based on the site design template. I.e. the information displayed in these areas is determined by the parameters of the site template.

      Generally, the page structure looks like the following:

      // prolog connection
      page body
      // epilog connection

      Thanks to the technology of deferred functions a part of visual elements displayed in the prolog may be set in the page body. These are such elements as:

      The key feature of this technology consists in its possibility to defer the performance of certain functions by performing them in the epilog, with the results of their performance substituted to the aforementioned code.

      A number of tasks cannot be resolved using the technology of deferred functions, for example when certain actions must be performed in the Prolog with values that in the previous example would be set in the page body (for example, page properties). In this case, the prolog must be divided into a service and a visual part, and the values must be set between them.

      It is achieved as follows:

      // connection of the service part of the prolog
      // here, for example, a page property may be set
      // using the function $APPLICATION->SetPageProperty
      // and then process it in the visual part of the epilog
      // connection of a visual part of the prolog
      Page contents
      // connection of the epilog

      The following occurs in the service part of the prolog:

      • Database connection;
      • Execution of agents;
      • Initialization of service constants;
      • Verification of access rights to files and catalogues;
      • Connection of necessary modules;
      • Execution of event handlers OnPageStart and OnBeforeProlog;
      • A number of other necessary actions.

      The service part of the prolog has a particularity that it does not display any data (does not send the header to the browser).

      In the visual part of the prolog the file /bitrix/templates/site template ID/header.php is connected, where site template ID is the identifier of the current site template. This file stores top left part of the current site template.

      The epilog may also be divided into a visual and a service part:

      // connection of the service part of the prolog
      // connection of the visual part of the prolog
      Page contents
      // connection of the visual part of the epilog
      // connection of the service part of the epilog

      In the visual part of the epilog the file /bitrix/templates/site template ID/footer.php is connected, where site template ID is the identifier of the current site template. This file stores bottom right part of the current site template. In addition to this, a number of invisible IFRAMEs used by the technology of redirection of visitors is displayed.

      The following occurs in the service part of the epilog:

      • Sending of mail messages;
      • Execution of event handlers;
      • Database disconnection;
      • A number of other service actions.

      Tasks often occur when there is no need to connect visual parts of the prolog and epilog. In this case, the connection of service parts of the prolog and epilog will suffice.

      // connection of the service part of the prolog
      Page body
      // connection of the service part of the epilog

      For the correct operating of the system, the service parts of the prolog and epilog must be connected.


      Page template is a PHP file wherein the contents are strictly consistent with the rules of forming the page structure. The templates may be used to create a new page.

      Page templates are stored in the following catalogs:

      • /bitrix/templates/.default/page_templates/;
      • /bitrix/templates/site template ID/page_templates/.

      Each such catalog may contain the proper page template files and also the service file .content.php of which the principal task is to store descriptions and the procedure for sorting page templates. This information is stored in the $TEMPLATE array of which its structure is presented below:

          [fine name] => Array
                  [name] => header of the page template
                  [sort] => sorting index

      The following algorithm is used during the formation of the list of page templates:

      • Connect site template ID for the current site that connects without PHP condition;
      • Connect the following file one by one:
        • /bitrix/templates/.default/page_templates/.content.php
        • /bitrix/templates/site template ID/page_templates/.content.php
        Each of these files will contain a description of its own $TEMPLATE array. After the connection of these files we will have a single $TEMPLATE array. Then, the following shall be performed for each element of this array which represents a description of one template of a page:
        • Verify physical existence of the page template
        • If it does exist, we add it to the list of templates
      • Sort out the resulting list of templates by sorting index (see $TEMPLATE array structure above).


      The section properties are stored in the file .section.php of the relevant catalog (site section). The page properties are set, as a rule, either in the page body or between the service and visual parts of the prolog.

      The section properties are automatically inherited by all subsections and pages of this section. If necessary, you can edit the properties of any separate page of the section by correcting its parameters as needed.

      The following functions are used in work with the properties:

      Property Setting Methods

      CMain::SetPageProperty - sets the page property.

          $APPLICATION->SetPageProperty("keywords", "web, development, programming");

      CMain::SetDirProperty - sets the section property.

          $APPLICATION->SetDirProperty("keywords", "design, web, site");

      Show Property

      CMain::ShowProperty - displays a page or section property using technology of deferred functions.

      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
      <body link="#525252" alink="#F1555A" vlink="#939393" text="#000000">

      Get Property Value

      CMain::GetProperty - returns a page or section property.

          $keywords = $APPLICATION->GetProperty("keywords");
          if (strlen($keywords)>0) echo $keywords;

      CMain::GetPageProperty - returns a page property.

          $keywords = $APPLICATION->GetPageProperty("keywords");
          if (strlen($keywords)>0) echo $keywords;

      CMain::GetPagePropertyList - returns an array of all the page properties.

          $arProp = $APPLICATION->GetPagePropertyList();
          foreach($arProp as $key=>$value)
          	echo '';

      CMain::GetDirProperty - returns a section property.

          $keywords = $APPLICATION->GetDirProperty("keywords");
          if (strlen($keywords)>0) echo $keywords;

      CMain::GetDirPropertyList - returns array of section properties collected recursively up to the site root.

          $arProp = $APPLICATION->GetDirPropertyList();
          foreach($arProp as $key=>$value)
          	echo '';

      Working with Meta Tags

      Page and section properties are used to work with meta tags. The following functions are used to work with them:

      CMain::ShowMeta - displays a page property or a section property with an HTML tag frame using a deferred function feature.

      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
      <?$APPLICATION->ShowMeta("keywords_prop", "keywords")?>
      <?$APPLICATION->ShowMeta("description_prop", "description")?>
      <body link="#525252" alink="#F1555A" vlink="#939393" text="#000000">

      CMain::GetMeta - returns a page property or a section property with an HTML tag frame:

          $meta_keywords = $APPLICATION->GetMeta("keywords_prop", "keywords");
          if (strlen($meta_keywords)>0) echo $meta_keywords;


      Page parameters are intended to translate parameters into module functions in order to change their standard behavior. E.g., if it is necessary to deactivate the memorization of the last page in a session (when using a page by page navigation) or to change a standard data display mode in the functions of the Information Blocks module.

      Page parameters are accessible only within a page. They cannot be saved either in the database or in a session.

      The class CPageOption is intended for working with page parameters.

      Module IDNameParameterDescriptionDefault value
      main Main modulenav_page_in_sessionIf the value is “Y,” the last open page in a page by page navigation will be memorized in the session; if the value is “N,” the last page will not be memorized.Y
      iblock Information blocksFORMAT_ACTIVE_DATESIf the value is FULL, the dates referring to an element of an information block (fields ACTIVE_FROM and ACTIVE_TO) will be returned in full format (time included); if the value is SHORT – in short format (without time).SHORT

      Examples of use:

      CPageOption::SetOptionString("main", "nav_page_in_session", "N");
      CPageOption::SetOptionString("iblock", "FORMAT_ACTIVE_DATES", "FULL");

      Execution Procedure

      General page execution procedure is as follows:

      • Service part of the prolog;
      • Visual part of the prolog;
      • Page body;
      • Visual part of the epilog;
      • Service part of the epilog.

      Component and template parameters can be accessed from the component and template program modules as $arParams array. The result of work of the component program module is $arResult array submitted to the component template entry. The regular echo operator streams the resulting HTML code (and it gets incorporated into a proper place within the page).

      During the work on a component and template it is possible to use the functionality of Bitrix Framework modules which, in their turn, may access the product database.

      Page Execution Procedure

      Page is a PHP file, consisting of a prolog, page body (main work area) and epilog:

      • header (/bitrix/header.php)
      • workarea
      • footer (/bitrix/footer.php)

      Page has a certain structure, properties and parameters. It can use its own templates.

      Sequence of page execution:

      No.OperationDefined constants and variables Note
      1.Prolog service part (/bitrix/modules/main/include/prolog_before.php)
      1.1 Connection
        Connected file must contain definitions of variables for connecting to a database, constants for debugging and access permissions.
      File with core D7 settings is connected upon a first config query.
      1.2 Connecting with database $DB In case of connection errors, connects the file /bitrix/php_interface/dbconn_error.php instead.
      1.3 Connecting
        Connected file can contain operations, necessary for executing immediately after establishing database connection.
      Defines all classes and functions of the main module.
      If at this moment, you have a defined constant with SITE_ID, this site won't be defined as per current folder and domain name but the rest of constants will be defined for this site.
      1.5 Connecting
        Can contain initialization for event handlers. Connecting extra functions - shared for all sites.
      1.6 Connecting
      /bitrix/php_interface/site ID/init.php
        Contains parameters, function definitions for specific site.
      1.7 Opening session All session variables $_SESSION  
      1.8 Event OnPageStart
      1.9 Defining user, user authorization, session completion, registration (depending on the query parameters) $USER  
      1.10 Defining current site template SITE_TEMPLATE_ID  
      1.11 Event OnBeforeProlog    
      1.12 Verifying level 1 access permissions   In case permissions are insufficient, prints autherization form and page finishes execution.
      1.13 Starting result buffering   After initiating the buffering, you can display online, before setting cookies and otherwise set cookies before displaying online.
      1.14 Event OnProlog    
      2. Prolog visual section (/bitrix/modules/main/include/prolog_after.php)
      2.1 Connecting
      /bitrix/templates/Site template ID/header.php
      3. Page body
      4. Epilog visual section (/bitrix/modules/main/include/epilog_before.php)
      4.1 Connecting
      /bitrix/templates/Site template ID/footer.php
      4.2 Calling the function CMain::ShowSpreadCookieHTML   This function prints set of invisible IFRAMEs for deploying cookies between sites
      5. Epilog service section (/bitrix/modules/main/include/epilog_after.php)
      5.1 Event OnEpilog    
      5.2 Page buffering finalization   Completing and printing buffer initialized as per para. 1.14
      5.3 Event OnAfterEpilog    
      5.4 Checking agents    
      5.5 Sending emails   You can find more information about emails in "Email system"
      5.6 Finishing connection with database $DB variable is no longer accessible  

    Courses developed by Bitrix24