TTWeb Basics 5. Content Regions

The region liquid tag has been created to specify parts of pages that are user-editable in the CMS. To use it, just drop in the tag {% region contact_intro %} wherever you want to have a user-editable content area. When a user interacts with this region via the CMS, a data file will be created (or updated) and committed to the github repository with a note of the user who made the change, so all content edits are tracked. The datafile will look something like this:

[{
  "_template: "html",
  "content": "<p>My Html Content</p>"
}]

The page where the region tag appears, the name of the region, and the current locale all determine the location of the data file. If you place the above region tag on the /_pages/contact-us.html page, the data file for the ‘en’ locale will be placed at /_data/_regions/en/_pages/contact-us.html/contact_intro.json. Note that this path is based on the placement of the *source() file, not the published file. So if the contact-us page was set to be published to the permalink /about/contact-us/index.html, the location for the region data files does not change.

A variation of the region tag is the regionblock tag which allows you to specify default content. For example

{% regionblock my_region %}
  <p>A user should change this content, but if they don't at least we have something.</p>
{% endregionblock %}

will render the given HTML if a user hasn’t specified other content for that region yet.

Region Tag Options

Both the region and regionblock tags can have a “type” parameter passet in such as

{% region my_region, type:html %}

The values are

  • html - default WYSIWYG region area
  • header - minimized WYSIWYG region that doesn’t force block elements (div, p) as wrappers
  • image - shows just an image picker instead of a WYSIWYG editor
  • multiple - makes the region a sortable multi-section region where each item can be one of the types set up in region_config

Includes and Editable Regions

Regions can also be defined in include files, but the region data is still specific to the primary page being rendered. For example if you have an include file _includes/two_column.html with the following content:

<div class="col-1">
  {% region two_column-col-1 %}
</div>
<div class="col-2">
  {% region two_column-col-2 %}
</div>

And that was included on both the _pages/about-us.html page and the _pages/neighborhood.html page, when a user edited the regions on each page, the content for the two_column-col-1 region would be unique for each page.

If you want to have global content that’s shared between pages you should use

  • The i18n system if it’s potentially translatable text
  • Content Settings if it’s non-translatable text (a globalized image, a phone number, address, email, hotel name etc)

type:image extras

For type:image regions, the rendered image tag will automatically contain a source set based on the image sizes that were created when the image was uploaded to the CMS. You can specify how these source set and sizes will be rendered in order to have the responsive image selection. This is done by adding a “sizes” attribute. For example:

{% regionblock intro_image, type: image, sizes: (min-width: 768px) 411px; 50vw %}

This means that screens that are 768px wide or wider, the image spacing be exactly 411px, so use the image src that fits that best without distorting. For all other screens (smaller than 768px) assume the image is 50% the width of the viewport. You can add any of the standard “sizes” img tag attribue values here, but note that you must use a ‘;’ in place of a ‘,’. In general the pattern is

sizes: <mediaquery> <size>; <mediaquery> <size>; <mediaquery> <size>;  <defaultsize>