Blocks are content components that can be reused in many places.
Introduction
When structuring and working with content, blocks are useful as they are reusable components that can be used in several places. For example a Banner block is typically used in many places, with the same graphical rendering, although with different images in different places depending on the story you are telling. If the case is that the banner should have the same image and texts in multiple places, there are global blocks, which content is centrally managed.
Blocks are nested (version 8.9), meaning that a block can contain another block, increasing flexibility in structuring content for managebility.
Entities that can have blocks
|
Page |
Campaign |
Website |
Category |
Data model and field templates
The lowest level of data modelling in Litium is a field, which technically is a field definition based on a field type. To set up different types of blocks you define a data model using fields and field templates.
As an example, a banner block can be defined as below and used for pages and campaigns.
Field template: Banner
|
Field: Image |
Field: Header |
Field: Text |
Field: Link |
Field: Button text |
Nested blocks
Blocks can have nested blocks allowing more flexibility in the data modelling of your content structure. In the field template of a block you define what block types is allowed for a block to have nested.
By allowing only certain block types, we facilitate for administrators managing the content, and minimize the risk of errors in rendering the blocks.
As an example, a footer with columns that have links, can be defined as in the image and table below using nested blocks, and used by the website entity.
Note the block container explained in the next section.

Conceptual image of nested blocks for a footer.
Block container: Footer
|
|
|
Allowed nested blocks: Footer column |
|
|
|
Field template: Footer column |
|
|
Allowed nested blocks: Footer links |
|
|
|
Field template: Footer links |
|
|
Allowed nested blocks: None |
|
|
Field: Header |
|
|
Field: Links (array) |
Table with field templates of nested blocks for a footer.
Block containers
Block containers are needed to render blocks, and to be able to place a block in an entity, the entity needs at least one block container defined.
Block containers are defined in the field template of entities supporting blocks, and the block container is needed in the code for a view to know how and where to render the block.
Best practices
A home page migh have only one block container, and administrators can add and sort the blocks freely insode the whole page.
A website, on the other hand might need several containers to indicate where in the framework content should be placed. For example, a website might have defined one container for the primary navigation and another for a footer.

Image showing concept of using block containers.
Global and local blocks
Global blocks are updated centrally. This is convenient if the same content is used in several places, for example a banner promoting the same campaign would probably have the same image and text even though it is showed in many different places in the site.
Local blocks are the opposite of global blocks, and they in use only by an instance of a an entity like a page or a campaign.
A local block can be converted to a global and vice versa.
A block can have both local and global blocks nested.
Global blocks are listed in its own space in the backoffice under Websites > Blocks.
Draft and published
A draft version of the block will be stored when any changes are made to it. There can only be one draft version of a block at any time. Technically, when the draft is published, the changes are migrated to the corresponding block.
Note: A block and its draft always have the same SystemId.

Settings
All blocks instances share a number of settings.
Channels
Use the channels to define the channels where the block should be active and visible to site visitors.
The channel settings are inherited from the block's parent entity.
Permissions
You can set permissions on block instance level to restrict which users should be able to read, write or publish the block.
The permission settings are inherited from the parent entity.
Audience
Use the audience settings to personalize the experience of site visitors, by defining which target groups or groups that should see the block.
Creating your own blocks
There is a detailed guide to defining and working with your own custom blocks. The guide is split into two, one for the MVC Accelerator and one for the React Accelerator.