When loaded the page in the builder mode, you should see a small logo icon on the screen's left (or right) edge. This icon opens the
builder panel, where we can get access to all the builder settings, the possibility to add new modules, drag and drop them, save changes etc.
This is the area where all added modules can be seen as HTML rendered on the page.
This is a JSON configuration which describes a template (modules and template settings) or global settings set.
It is the smallest component of the builder. Modules are "bricks" for creating and formatting the page content or layout of the page. Each module has settings that are aimed to customise it.
Many modules have their unique settings and presets, which are located under the
Primary tab. Examples are a setting for content for the Paragraph module or a setting for a date for the Time module.
CSS settings are standard for all modules. They are located under the
Advanced tab. There are also settings for
class attributes and for any other custom or standard HTML attributes.
Opening a module's settings makes such a module an active one. For instance, some hotkeys work for active modules only.
When several modules are "grouped" together, they form a layout. There is always one (and only one) parent module in the layout. So, every layout is a set (so-called "group") of several modules nested under one single parent.
These are built-in items or are added by third-party extensions.
These are copies of modules/layouts with specific settings which are saved to DB to be re-used in the same template or used in other templates. It is convenient to create a collection of design elements and have easy access to this collection from any template.
Saved modules are not available in the free version.
These are copies of modules/layouts with specific settings which are reusable across templates. Any changes in one instance of the global module will trigger updating all the same global module instances in all other templates.
Global modules are not available in the free version.
When we assign a template to specific WP objects, e.g. posts and pages, the latter become applicants. Each such WP object has its own data, e.g. posts have title, content, author ID etc, so WP object data become applicant data and is available in the builder through "data variables" (specifically, data variables with type "Query to DB")
Data variables are synthetic variables added by the user in the builder. Each variable has a name and value. Each data variable is getting evaluated and produces dynamic data that can be used inside the template.
A set of settings which are available for specific template only.
A set of settings which are available for all templates. However, these settings are also separated by template type, i.e, settings added for all templates of "single" type are not accessible for templates of type "collection". Global settings also can be assigned to all templates.
A set of settings that are available for each specific module. Some module settings are the same across all modules, but others are specific to a particular module type.
Page templates and publishing
A template is an entity which based on its
Apply Rules can be used to generate the web pages on our WordPress site.
Template does not contain page content itself, it is actually a VCS repository, which can have one or many branches which can have commits.
Rules based on which template can be applied to one or many web pages on our WordPress site. Mainly Apply Rules reflect WP Template Hierarchy.
Version control system
Version control system (also known as revision control) is responsible for managing changes made to template and global settings. It is very similar to GIT. It also has commits, branches and tags. Each commit is a specific revision or version of template or global settings. Commits cannot be deleted.
Each commit can be previewed. It also can be tagged. For instance, the common pattern of naming tags is to write the version of template changes, i.e "v1.0".
Continuous delivery system
WP sites can have multiple Builderius templates, global settings. They can have different branches, different commits, different quantities of commits. Final view of the site can be configured by picking specific commits of every VCS repository(templates, global settings) into the group. We can pick commits by tagging them. Commits from different VCS repositories tagged with the same tag are base for Builderius deliverables.
Builderius Deliverable is a collection of commits with the same tag. For instance, if we tag one commit of template settings as "v1.0", then another commit of global settings with the same name "v1.0", then we can create a deliverable by the tag "v1.0". This deliverable will include both commits mentioned before. Builderius can have different types of deliverables.
Release is one of Builderius deliverables types. It can be published/unpublished, exported and imported. Published release is the version of the site all visitors will see.