Are static fields and layouts supported, to edit elements as files?

At the moment, no, but there are some workaround you can consider.

  1. Use Gitify to incorporate fields into a version control workflow.
  2. Use @CHUNK templates, and make those chunks static.

Using Gitify

With Gitify you "extract" database objects to simple files, and "build" them to update the database. This allows easier version control of elements, including for ContentBlocks.

Learn more about Gitify here.

To use Gitify with ContentBlocks, you can use the following configuration:

    class: cbCategory
    primary: [id,name]
    package: contentblocks
    class: cbField
    primary: [id,name]
    class: cbLayout
    primary: [id,name]
    class: cbTemplate
    primary: [id,name]
    class: cbDefault
    primary: id<br>

We do recommend using the ContentBlocks interface for managing fields and layouts (followed by doing  Gitify extract to write the information to file) to ensure the syntax and field names are correct. Right now we use a fair bit of JSON definitions for things like settings and properties, which, truth be told, may not be the most ideal format for direct manipulation. 

Using @CHUNK

Alternatively you can use a static chunk and tell ContentBlocks to write out a chunk template tag for you. While you could write a chunk tag yourself, the @CHUNK binding is preferred as that will automatically provide all the different properties that are available.

For example, define your template on a field/layout like this:

@CHUNK NameOfYourChunk

When saving the resource, a full chunk tag is built for you:

     &value=`Some Value`

As of ContentBlocks v1.9.0, you can also use placeholders in the chunk name itself. That's useful if you have subtypes of chunks depending on a field setting. For example:

@CHUNK CallToAction[[+style]]

Assuming "style" is a field setting with value "Card", ContentBlocks will parse that into the following chunk tag:

      &value=`Some Value`

Important: chunks are only processed when a page is rendered (whereas a standard template in ContentBlocks gets largely parsed when saving the resource), so this approach may have an adverse performance impact on uncached requests.

Still need help? Send us an email Send us an email