Templating
The following examples are for templating with Fluid. Content Blocks brings some additional features like own variables and ViewHelpers with it.
Accessing variables
Inside your frontend. or backend- file you can access the
properties of your Content Element as usual by the {data} variable.
This variable, however, is special. It has real superpowers!
In contrast to the usual array, we are dealing with an object here. This allows
us to magically access our own custom properties very easily. Normally you would
access the processed properties. This is done by simply accessing the desired
property like {data.. The raw properties have to be accessed by
{data..
All fields with relations are resolved automatically to an array. This includes
Collection, Select, Relation, File, Folder, Category and Flex
fields. There is no need to provide additional DataProcessors for them.
Content Blocks applies relation resolving for you (recursively!).
Have a look at this code example to grasp what's possible:
<!-- Any property, which is available in the Record (like normal) -->
{data.title}
{data.uid}
{data.pid}
<!-- Normal access to custom relational properties -->
<f:for each="{data.collection1}" as="item">{item.title}</f:for>
<!-- Recursive access to custom relational properties -->
<f:for each="{data.collection1}" as="item">
<f:for each="{item.categories}" as="category">
{category.title}
</f:for>
</f:for>
<!-- Language related properties -->
{data.languageId}
{data.languageInfo.translationParent}
{data.languageInfo.translationSource}
<!-- The overlaid uid -->
{data.overlaidUid}
<!-- Types are a combination of the table name and the Content Type name. -->
<!-- Example for table "tt_content" and CType "textpic": -->
<!-- "tt_content" (this is basically the table name) -->
{data.mainType}
<!-- "textpic" (this is the CType) -->
{data.recordType}
<!-- "tt_content.textpic" (Combination of mainType and record type, separated by a dot) -->
{data.fullType}
<!-- System related properties -->
{data.systemProperties.deleted}
{data.systemProperties.disabled}
{data.systemProperties.lockedForEditing}
{data.systemProperties.createdAt}
{data.systemProperties.lastUpdatedAt}
{data.systemProperties.publishAt}
{data.systemProperties.publishUntil}
{data.systemProperties.userGroupRestriction}
{data.systemProperties.sorting}
{data.systemProperties.description}
<!-- Computed properties depending on the request context -->
{data.computedProperties.versionedUid}
{data.computedProperties.localizedUid}
{data.computedProperties.requestedOverlayLanguageId}
{data.computedProperties.translationSource} <!-- Only for pages, contains the Page model -->
<!-- Workspace related properties -->
{data.versionInfo.workspaceId}
{data.versionInfo.liveId}
{data.versionInfo.state.name}
{data.versionInfo.state.value}
{data.versionInfo.stageId}
<!-- To access the raw (unprocessed) database record use `rawRecord` -->
{data.rawRecord.some_field}Note
Note that we are omitting _processed when accessing properties, even
though you might think this would be correct due to the debug output.
Frontend & backend
Content Blocks allows you to provide a separate template for the frontend and the backend out of the box. The variables are the same for both templates, and while using the asset ViewHelpers, you can also ship JavaScript and CSS as you need. The main goal behind this is, that you can provide a better user experience for the editors. With this feature, there is the possibility to provide nearly the same layout in the frontend and the backend, so the editors easily find the element they want to edit.
The frontend template is located in templates/frontend.html and the backend template in templates/backend-preview.html.
Asset ViewHelpers
Content Blocks provides a new AssetPathViewHelper to access assets from within the current Content Block in the template.
<f:comment><!-- Include the assets/frontend.css stylesheet --></f:comment>
<f:asset.css identifier="myCssIdentifier" href="{cb:assetPath()}/frontend.css"/>
<f:comment><!-- Include the assets/frontend.js script --></f:comment>
<f:asset.script identifier="myJavascriptIdentifier" src="{cb:assetPath()}/frontend.js"/>The information of the current Content Block is stored in {data}. This
means if you use an asset ViewHelper in a partial, you have to provide
{data} as an argument to that partial. Alternatively, you can set
name by hand:
<f:comment><!-- The name of the Content Block is set explicitly --></f:comment>
<f:asset.script identifier="myJavascriptIdentifier" href="{cb:assetPath(name: 'vendor/name')}/frontend.js"/>LanguagePath ViewHelper
Content Blocks provides a LanguagePathViewHelper to retrieve the LLL-path for the labels.xlf file of the current Content Block.
<f:translate key="{cb:languagePath()}:header"/>As described above in the asset ViewHelper, the {data} variable is
required to resolve the Content Block automatically. You can also set
name by hand:
<f:translate key="{cb:languagePath(name: 'vendor/name')}:header"/>Partials
Partials are a very useful feature of Fluid. You can use them to split up your templates into smaller parts. If you want to use a partial in a Content Block, you can create a subdirectory partials in the templates directory and place your partials there.
This part is automatically added, but you can also extend or overwrite this TypoScript configuration in your sitepackage.
Remember, that you should ship the {data} variable to the partial if you
want to make use of automatic detection of the current Content Block.
<f:render partial="Component" arguments="{data: data, foo: 'bar'}"/>See also:
Layouts
Analogous to partials, you can also use layouts. You can create a subdirectory
layouts in the templates directory and place your layouts there. The
configuration is added automatically, but you can also extend or overwrite the
TypoScript configuration in your sitepackage. Afterwards you can use your
layouts as usual in Fluid.