Structured Vs Unstructured Data

There are primarily two types of data in the CMS, structured data and unstructured data.

Structured Data

Structured data simply refers to content (objects and fields) that is defined identically for every site on the CMS. An example is a blog which has blog posts, which in turn have an image, a summary, and content.

Some of the structured data is required and will be consistently present for all objects (eg: which blog a blog post belongs to) but most of the structured data is optional and may or may not have a value (eg: the blog post summary) - which templates should be created to take into account.

It should be possible to create a website entirely from structured data, but to fully customize and polish off a site it is helpful to also utilize unstructured data.

Unstructured Data

Unstructured data refers to content that may vary from site to site or even from object to object. Marketpath CMS provides multiple opportunities to define and utilize unstructured data, including custom fields on entities and pages, datastores, and custom site settings.

Wherever unstructured data is available, it is the site/template developer who should be responsible for setting it up. This is to ensure that it follows conventions used on the rest of the site and is consistent with how data is stored and accessed throughout the site.

Although it is more difficult to query unstructured data (with some provisions for datastores), unstructured data is included in the full site search.

Custom Fields

Custom fields on both entities and pages are defined at the template level. By default custom fields are saved on the page, but the template developer can choose to store custom fields on the entity instead - thereby making them accessible wherever the entity is accessed.

Due to the nature of unstructured data, there are a number of things that template developers should be aware of when defining custom fields:

  1. When a template developer defines custom fields, he/she may (and should) group multiple fields together in order to make it more intuitive when entering data. When the custom fields are accessed, however, the order and grouping of fields is inconsequential.
  2. A template developer may choose to mark a field as "required", which will prevent users from being able to save the page until that field has been entered. They may also add validation to a field to restrict input to a specific format (eg: enter an integer or a decimal number). Although we do our best to enforce the validation rules created by the template developer, there are intentional and unintentional ways around these measures which may allow users to bypass them. As such, template developers should still validate their fields before displaying them (typically utilizing code such as {% if field.is_valid %}).
  3. We do our best to include custom fields from partial templates, but we are limited in how we can detect partial templates to include custom fields from. We call these, "compiled templates." In short compiled templates are templates included using {% include "template_name" %}. The main limitation is that compiled templates do not include templates assigned to a variable (eg: {% assign template = "template_name" %}{% include template %} or {% include page.sidebar_template %}). Although dynamically included templates will be included, any custom fields defined by them will not be automatically included in pages created using the parent template.


Datastores are an interesting combination of structured and unstructured data. While there are a few core fields on every datastore item, the purpose is to allow developers to define their own data structure that every datastore item utilizes.

When a developer creates a datastore, they should add fields to it in a similar manner that they would add custom fields to a template. Some of the same limitations apply to datastore fields as to custom fields - including field grouping and required/validated fields. One of the main differences between datastores and custom fields is that it is much easier to query datastore items and to make datastore items selectable in custom fields and other datastores.

If a custom schema isn't enough, datastore items also have the ability to utilize custom fields just like every other entity in the CMS.

Custom Site Settings

Custom Site Settings are defined on a site-wide basis. This serves two purposes. First, it makes it easy to change the way the site works or is displayed with a single action and without modifying any code (eg: selecting a main menu or changing the logo). Second, since custom site settings can be exported and imported from site to site, it makes it easier to create reusable and customizable components without requiring a developer to modify templates on sites that the components are imported into.

Developers should e aware that even if they define a default value for a custom site setting, it will not be available on the live site until someone edits and publishes the site template settings.

Also, since custom site settings can be exported and imported between sites, developers should be aware of possible naming conflicts and should name their settings to avoid those conflicts. The easiest way to accomplish this is to use a consistent prefix for your settings (eg: if you company is "XYZ Corp" you might prefix all settings with "xyzcorp_" to make them unique.

A final note on custom site settings: regardless of where or when the setting was defined, custom site settings are always displayed under site template settings in alphabetical order. Be careful if you attempt to use this to your advantage so that you do not inadvertently make things more complicated than necessary when settings are imported from other sites.

Developer Overview

Liquid Markup