Documentation

Updating system template

Attention! We strongly recommend first to learn more about Sites module REST documentation to understand how the module functions (with REST available in Bitrix24 Self-hosted editions). View this documentation as useful source when working with Bitrix24 Self-hosted editions and find out more details about API and only REST is not enough.

Only for Bitrix24 Self-hosted!

  • Configuration file
  • Use markers in template
  • Site24 template is connected in the page editor as well as via the public section. Third-party site integrations into this template can reset updates during site update.

    At the same time, system is quite flexible in modifying the template as described below.


    Configuration file

    The .config.php file is placed inside the template /bitrix/templates/landing24. File is connected when editing and in the published site and can affect template behaviour.

    Below is the example of file contents (current array version can be found in the method Bitrix\Landing\Config::getDefaultConfig()):

    return [
       'js_core_public' => [
          'landing_core'
       ],
       'js_core_edit' => [
          'landing_core'
       ],
       'disable_namespace' => [],
       'enable_namespace' => [],
       'public_wrapper_block' => true,
       'google_font' => true
    ];

    Let's analyze all keys in more detail.

    js_core_public – array of JS extensions required for module to operate when published. We recommend you do not scrap landing_core, because it has several libraries, needed for display (for example, vendors_base.css, its Bootstrap), instead you can add or update several scripts into it.

    Here's how system kernel landing_core looks like (you can copy it into your extension, register it and then specify your code into js_core_public):

    <?php
    
    // $pathJS = '/bitrix/js/landing';
    // $pathTemplate24 = '/bitrix/templates/landing24';
    
    $jsConfig = array(
        // ...
        'landing_core_custom' => array(// update key, because we are registering our own extension
            'js' => array(
                $pathJS . '/utils.js',
                $pathTemplate24 . '/assets/js/helpers/onscroll-animation_init.js',
                $pathTemplate24 . '/assets/js/helpers/go_to_init.js',
                $pathTemplate24 . '/assets/js/helpers/popup_init.js',
                $pathTemplate24 . '/assets/js/helpers/hamburgers_init.js',
            ),
            'css' => array(
                $pathTemplate24 . '/assets/vendor/vendors_base.css',
                $pathTemplate24 . '/assets/vendor/icon-awesome/css/font-awesome.css',
                $pathTemplate24 . '/assets/vendor/icon-line/css/simple-line-icons.css',
                $pathTemplate24 . '/assets/vendor/icon-line-pro/style.css',
                $pathTemplate24 . '/assets/vendor/icon-hs/style.css',
                $pathTemplate24 . '/assets/vendor/icon-etlinefont/style.css',
                $pathTemplate24 . '/themes/themes_core.css',
                $pathTemplate24 . '/assets/css/custom.css',
                $pathTemplate24 . '/assets/css/themes_custom.css',
            ),
            'rel' => array('landing_public'),
        ),
        // ...
    );
    
    foreach ($jsConfig as $code => $ext)
    {
        \CJSCore::registerExt($code, $ext);
    }
    
    // update the .config.php
    return [
        'js_core_public' => [
            'landing_core_custom'//indicate your own extension for public section
        ],
        'js_core_edit' => [
            'landing_core'//editor can have system extension without changes, as an option.
        ],
        'disable_namespace' => [],
        'enable_namespace' => [],
        'public_wrapper_block' => true,
        'google_font' => true
    ];

    Note. Learn more about extension registration.

    js_core_edit - the same as js_core_public, but only for draft editing mode.

    disable_namespace - this parameter can enumerate the comma-separated block namespaces that may be hidden in editor. For example, you can block bitrix namespace and show only your personal blocks:

       'disable_namespace' => [
          'bitrix'
       ],

    enable_namespace - on the other hand, this parameter can contain priority namespaces - only they will be considered in the editor. When key is specified, the key disable_namespace is ignored.

    public_wrapper_block – each block is wrapped into additional div in the published version. When it's not required for some reason, just indicate false.

    google_font – several google fonts are connected in the template header by default. If not required, just indicate false.

    However, when file is located in the system template, it will never be modified during updates and you can openly use it.

    This file is connected once and can contain additional logic. For example, for connecting a block namespace depending on current template.


    Using markers in template

    A template has quite a lot of so-called display markers. Marker - is specific location within the layout, containing the code, inserted by the developer. For example, let's insert a code after the opening tag <head>. You can use any suitable event at the page building stage. We'll use OnBeforeProlog.

    $eventManager = \Bitrix\Main\EventManager::getInstance();
    $eventManager->addEventHandler('main', 'OnBeforeProlog',
       function()
       {
          if (\Bitrix\Main\Loader::includeModule('landing'))
          {
             \Bitrix\Landing\Manager::setPageView(
                'AfterHeadOpen',
                '<meta http-equiv="X-UA-Compatible" content="IE=edge">'
             );
          }
       }
    );

    Please note, neighbouring events may be left as is, since such events can set some values into these markers. Each new query for setPageView will only supplement (comma-separated) an already existing displayed page, but will not overwrite it. Only the sequence is important.

    Presently, the following template markers are available:

    HtmlClass - <html> tag class.

    AfterHeadOpen - text immediately after the opening tag <head>.

    BeforeHeadClose - text in front of closing tag </head>.

    HtmlClass - <body> class tag.

    BodyTag - any text inside the tag <body> (for example, styles, attributes).

    AfterBodyOpen - text immediately after opening tag <body>.

    HtmlClass - <main> class tag (wrapper for complete page content).

    FooterJS - text in the JS code display in the page footer.

    BeforeBodyClose - text in front of the closing tag </body>.

    And visualization template

    <!DOCTYPE html>
    <html class="HtmlClass">
    <head>
       AfterHeadOpen
       <meta http-equiv="X-UA-Compatible" content="IE=edge">
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <title>title
        <!-- Google Fonts -->
        <!-- CSS -->
        <!-- OG -->
       BeforeHeadClose
    </head>
    <body class="BodyClass" BodyTag>
    AfterBodyOpen
    <main class="MainClass">
       <!-- Body -->
       FooterJS
    </main>
    BeforeBodyClose
    </body>
    </html>


    © «Bitrix24», 2001-2024