Documentation

Manifest File

Manifest file that accompanies each block and describes the edited parts of a block. Manifest file also contains block name, description and JS/CSS files.

block manifest
  • Examples
  • Block manifest fields
  • block key
  • nodes key
  • style key
  • assets key
  • cards key
  • attrs key
    •
  • Principles for block styles alterations
  • For animation
    •

    Examples

    Important! Result of block operation must contain at least one tag, even when contains technical information only.
    For example: <div>This block works only after published</div>.

    Block example:

        <section class="landing-block container-fluid px-0 g-theme-business-bg-blue-dark-v1">
        <div class="row no-gutters align-items-start">

            <div class="landing-block-card js-animation fadeIn col-md-6 col-lg-6 g-flex-centered">
                <div class="landing-block-node-card-container text-center g-pa-30 w-100">
                   <div class="landing-block-node-card-header text-uppercase u-heading-v2-4--bottom g-brd-primary g-mb-40">
                       <h2 class="landing-block-node-title h1 u-heading-v2__title g-line-height-1_3 g-font-weight-600 g-font-size-40 g-color-white g-mb-minus-10">Help 
make <br> money</h2>
                    </div>

					<div class="landing-block-node-text g-color-gray-light-v2">
                                       <p>Sed feugiat porttitor nunc, non dignissim ipsum vestibulum in. Donec in blandit dolor. Vivamus a fringilla lorem, vel faucibus ante. Nunc
ullamcorper, justo a iaculis elementum, enim orciviverra eros, fringilla porttitor lorem eros vel odio. Praesent egestas ac arcu ac convallis. Donec ut diam
risus purus.</p>
					</div>
                </div>
            </div>

            <div class="landing-block-card js-animation fadeIn col-md-6 col-lg-6 g-flex-centered">
                <div class="landing-block-node-card-container text-center g-pa-30 w-100">
                    <div class="landing-block-node-card-header text-uppercase u-heading-v2-4--bottom g-brd-primary g-mb-40">
                        <h2 class="landing-block-node-title h1 u-heading-v2__title g-line-height-1_3 g-font-weight-600 g-font-size-40 g-color-white g-mb-minus-10">Help 
make <br> money</h2>
                    </div>

					<div class="landing-block-node-text g-color-gray-light-v2">
					<p>Sed feugiat porttitor nunc, non dignissim ipsum vestibulum in. Donec in blandit dolor. Vivamus a fringilla lorem, vel faucibus ante. Nunc
ullamcorper, justo a iaculis elementum, enim orciviverra eros, fringilla porttitor lorem eros vel odio. Praesent egestas ac arcu ac convallis. Donec ut diam
risus purus.</p>
					</div>
                </div>
            </div>

        </div>
    </section>

    Note: Adherence to unique manifest layout is required only within a single block. Same selectors between blocks can even have absolutely different meaning.

    Here is an example of how a manifest file can look like for the block above:

    <?php
if (!defined('B_PROLOG_INCLUDED') || B_PROLOG_INCLUDED !== true)
{
	die();
}

use \Bitrix\Main\Localization\Loc;

return array(
	'block' => array(
		'name' => "Text in two columns",
		'section' => array('columns', 'text'),
	),
	'cards' => array(
		'.landing-block-card' => array(
			'name' => "Column",
			'label' => array(
				'.landing-block-node-subtitle',
				'.landing-block-node-title',
			),
		),
	),
	'nodes' => array(
		'.landing-block-node-title' => array(
			'name' => "Title",
			'type' => 'text',
		),
		'.landing-block-node-text' => array(
			'name' => "Text",
			'type' => 'text',
		),
	),
	'style' => array(
		'block' => array(
			'block-default',
		),
		'nodes' => array(
			'.landing-block-card' => array(
				'name' => "Column",
				'type' => array('columns', 'animation'),
			),
			'.landing-block-node-title' => array(
				'name' => "Title",
				'type' => 'typo',
			),
			'.landing-block-node-text' => array(
				'name' => "Text",
				'type' => 'typo',
			),
			'.landing-block-node-card-header' => array(
				'name' => "Title",
				'type' => 'border-color',
			),
		),
	),
	'attrs' => array(
		'.landing-block-node-text' => array(
			'name' => 'Text setting',
			'type' => 'dropdown',
			'attribute' => 'data-copy',
			'items' => array(
				'val1' => 'Value 1',
				'val2' => 'Value 2',
			),
		),
	),
	
	'assets' => array(
		'css' => array(
			'https://site.com/aaa.css',
		),
		'js' => array(
			'https://site.com/aaa.js',
		),
		'ext' => array(
			'landing_form',
		),
	),
);

    Block manifest fields

    Block key

    Block key contains name and category of the block (or an array of categories). There is a certain amount of categories in the system. They are:

    array(
    'cover' => Cover,
    'about' => About the project,
    'title' => Title,
    'text' => Text block,
    'image' => Image,
    'gallery' => Gallery,
    'phrase' => Citation,
    'benefits' => Advantages,
    'columns' => Columns,
    'separator' => Separator,
    'menu' => Menu,
    'footer' => Site footer,
    'pages' => List of pages,
    'tiles' => Tiles and link,
    'forms' => CRM form,
    'team' => Team,
    'feedback' => Reviews,
    'schedule' => Schedule,
    'steps' => Steps,
    'contacts' => Contacts,
    'social' => Social networks,
    'tariffs' => Plans,
    'partners' => Partners,
    'other' => Other,
    'popular' => Popular,
);

    If a required category is unavailable in the list, just write it in as text inside the manifest and such category will be added. The key for the new category is the value md5(strtolower($sectionName)).

    Additionaly, this key can contain the following settings:

    • dynamic => false responds to block that it CANNOT be used as dynamic (Occurs very rarely.)
    • subtype – type of special block; allows a single value or multiple as an array (for Bitrix24 Self-hosted.)
    • subtype_params – special block parameters. (for Bitrix24 Self-hosted.)

      • You can attempt to indicate available types in Bitrix24 cloud block, but vendor doesn't guarantee 100% operability of this construction.

    • type - can contain site type. Block is operational on this site landing pages (block is shown everywhere by default). Presently, the following sites are supported:
      • page: standard sites
      • store: online stores
      • knowledge: knowledge bases
      • group: social network knowledge bases

    Assets key

    Assets key contains JS and CSS files that must be connected when adding block to a landing page. If several blocks use the same JS/CSS file, it's ok: each file will connect only once.Ext key is the JS libraries of Bitrix24 kernel. You cannot connect any kernel extension in Bitrix24 cloud variant. Presently, it's only permitted to connect the library with the landing_form code. This library is responsible for CRM forms initialization on landing pages.

    When you use any third-party libraries in a separate code that are already connected to the main kernel (for example, jQuery), it's recommended to wrap system commands of your script into system code. As the result, your code is successfully initialized after all system connections are complete:

    BX.ready(function()
{
    console.log($(window));
});

    Nodes key

    Nodes key contains blocks, with its content permitted to be modified. Hereinafter, css-selector principles are applied to specify final nodes.

    It's recommended to choose a self-explanatory class name as the selector. To differentiate standard classes from structural selector classes, give a self-explanatory prefix to the name as well. For example, "landing-block-node-". It's permissible to use the same selector in different blocks. Selector of the node does not match with card selectors of this block.

    This way, selectors are enumerated by keys in the the nodes key. The content of selectors can be edited, with node name and type specified. See details about node types here.

    As you might probably realized, depending on the node type and its specification in this block, this node will become available for editing and will appear in the block content edit form.

    Aside from type, name and specific keys of various types, there are also general parameters of nodes of any type:

    allowInlineEdit – if key value equal to false is passed, inline editing for these nodes will be restricted. However, at the same time the node editing will be available via the block edit form.

    group – node group. When the same value of this key is specified for several nodes (within the same block), then when clicking on any node, an interface opens to edit the complete group of nodes.


    Style key

    Style key. This key is very similar to the 'nodes' key, with exception of the fact that the permissible design is marked in this key: which nodes are permitted to change visual appearance, and which type do they have.

    Presently, the following existing types:

    • box - block-level elements
    • button – links as buttons
    • typo - all typographics
    • typo-simple – simplified typographics
    • typo-link – links typographics
    • paddings – all paddings
    • navbar – navigational bars
    • navbar-full – navigational bars
    • and some others...
    Full list of available types and high CSS styles it unifies:

    Cards key

    Contains so-called block elements (cards). Its a repeatable content. For example, list of services, employee photos and etc. This way, after formatting a block with it, such features as cloning, deleting and modifying cards will become available in the interface.

    Its elementary appearance is the same as in the manifest. You can find additional details about expanded cards management.

    Its recommended to choose a self-explanatory class name as the selector. To differentiate standard classes from structural selector classes, give a self-explanatory prefix to the name as well. For example, "landing-block-card-". It's permissible to use the same selector in different blocks. Selector of the card does not match with modes selectors of this block.

    Cards of one selector should not share single parent with other selector cards. In the case of a shared parent, use expanded cards.


    Attrs key

    See description of attributes at the separate page.


    Principles of block styles modification.

    Style node attribute does not change when modifying external visual appearance of blocks. Only classes are modified. For example, if you want to change font-size from 12 to 16, the system will change not the 'font-size', but will change a conditional class g-fontsize12 to g-fontsize16.


    Animation

    The following is required to enable animation within standard setup:

    • the node must have the js-animation class;
    • the manifest must have the setting for this node in the style - 'type' => 'animation' section;
    • for animation to work immediately by default, an animation class must be added (in the provided block example - fadeIn), but is not mandatory; the setting will also operate without it.


    © «Bitrix24», 2001-2024
    Up