---
title: "1.3"
manual: "Content Blocks"
version: "main"
permalink: "https://docs.typo3.org/permalink/friendsoftypo3/content-blocks:changelog-1-3@main"
source: "ChangeLog/1.3/Index.rst"
rendered: "2026-09-22T14:15:39+00:00"
---

# 1.3 {#changelog-1-3}

-   [Features](https://docs.typo3.org/permalink/friendsoftypo3/content-blocks:features@main)

## Features {#features}

### Restrict Collection child types {#restrict-collection-child-types}

It is now possible to set specific record types, which should be available for
the type selector of Collection items. The most common use case is probably some
kind of accordion or tab element, which should only have a few allowed Content
Elements as children.

#### Example {#example}

In this example only the Core types `text` and `images` are allowed in
`allowedRecordTypes` inside the Collection field.

```yaml
name: example/tabs
fields:
  - identifier: header
    useExistingField: true
  - identifier: tabs_item
    type: Collection
    minitems: 1
    foreign_table: tt_content
    allowedRecordTypes:
      - text
      - images
```

If you've used Mask before, you know this feature. The Content Blocks
implementation is based on the FormDataProvider API in contrast to Mask, which
used itemsProcFunc.

### Link EditRecord ViewHelper {#link-editrecord-viewhelper}

Content Blocks introduces its own `cb:link.editRecord` ViewHelper. In
contrast to the Core `be:link.editRecord` ViewHelper it has support for
Page Layout anchor links by default. This means when you click on a custom edit
link and close the editing interface again, you will automatically jump to the
referring Content Element.

> [!NOTE]
> This new ViewHelper is only useful in the Page Layout context for Content
> Element previews. For all other cases using the Core
> `be:link.editRecord` is still valid.

#### Example 1: Content Element {#example-1-content-element}

Here the bodytext of the Content Element is linked.

```html
<html
    xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
    xmlns:cb="http://typo3.org/ns/TYPO3/CMS/ContentBlocks/ViewHelpers"
    data-namespace-typo3-fluid="true"
>

<f:layout name="Preview"/>

<f:section name="Header"/>

<f:section name="Content">
    <f:asset.css identifier="cbCtaCssBackend" href="{cb:assetPath()}/preview.css"/>
    <div class="cb-cta">
        <h2>{data.header}</h2>
        <cb:link.editRecord record="{data}">
            <f:format.raw>{data.bodytext}</f:format.raw>
        </cb:link.editRecord>
    </div>
</f:section>

</html>
```

#### Example 2: Linking Collections {#example-2-linking-collections}

If you have a custom preview for your Collection, you can link the items
individually, making it easier for editors to edit one specific item quickly.
The important part is to add the `id` attribute following the schema:
`element-{table}-{uid}`. In this example the text of an accordion item is linked
this way.

```html
<html
    xmlns:f="http://typo3.org/ns/TYPO3/CMS/Fluid/ViewHelpers"
    xmlns:cb="http://typo3.org/ns/TYPO3/CMS/ContentBlocks/ViewHelpers"
    data-namespace-typo3-fluid="true"
>

<f:layout name="Preview"/>

<f:section name="Content">
    <f:asset.css identifier="cbAccordionCssBackend" href="{cb:assetPath()}/preview.css"/>
    <div class="cb-accordion">
        <f:for each="{data.accordion_item}" as="item">
            <cb:link.editRecord record="{item}">
                <div id="element-{item.mainType}-{item.uid}" class="accordion-item">
                    {item.text}
                </div>
            </cb:link.editRecord>
        </f:for>
    </div>
</f:section>

</html>
```

#### Migration {#migration}

If you already used the `be:link.editRecord` ViewHelper, just make a quick
search and replace: `<be:link.editRecord` -> `<cb:link.editRecord` and
`</be:link.editRecord>` -> `</cb:link.editRecord>`. The old parameters `uid` and
`table` still work as a fallback. After that, you can also remove the namespace
import in case you didn't use any other ViewHelper in the `be` namespace.
Importing the `cb` namespace it optional as it is registered globally.

### Re-definition of Core Page Types {#re-definition-of-core-page-types}

It is now possible to re-define the Core Pages Types of TYPO3:

-   Standard (1)
-   Link to External URL (3)
-   Shortcut (4)
-   Backend User Section (6)
-   Mount Point (7)

This is especially useful if you need custom fields for Core Page Types, but
it's not possible to use a custom Page Type like for Shortcuts or External
Links. This feature should not be used in third-party extensions, as this would
make it impossible for users to define the Page Type themselves.

#### Examples {#examples}

Override Page Type "External URL":

```yaml
name: vendor/external-page
typeName: 3
fields:
  - identifier: additional_field
    type: Text
  - identifier: TYPO3/External
    type: Basic
```

Override Page Type "Shortcut":

```yaml
name: vendor/shortcut-page
typeName: 4
fields:
  - identifier: additional_field
    type: Text
  - identifier: TYPO3/Shortcut
    type: Basic
```

### Default config {#default-config}

The content-blocks.yaml file has been extended to support arbitrary default
values for the generated config.yaml file from the make:content-block command.

#### Example {#example-1}

To use this new feature, create a content-blocks.yaml file in the root directory
of your project. Then, add a `config` key followed by a Content Type
identifier. In this case, we set default values for Content Elements, so we use
`content-element`. You can also set default values for `page-type`,
`record-type` or `file-type`. Values defined in here override the generated
configuration by the command.

```yaml
config:
  content-element:
    basics:
      - TYPO3/Appearance
      - TYPO3/Links
    group: my_group
    prefixFields: true
    prefixType: vendor
```

### Support for PAGEVIEW {#support-for-pageview}

The Content Blocks Data Processor is now able to resolve the Page Record for
page templates based on `PAGEVIEW`.

#### Example {#example-2}

This will add the variable `data` to your page template which contains the
resolved page record. This also works for Page Types not defined by Content
Blocks like the default Page Type "1".

```typoscript
page = PAGE
page.10 = PAGEVIEW
page.10 {
  paths.10 = EXT:content_blocks_examples/Resources/Private/Templates
  dataProcessing {
    10 = page-content
    20 = content-blocks
  }
}
```

### Core Types resolved to Record Objects {#core-types-resolved-to-record-objects}

Core Types are now also transformed to Record Objects by the Content Blocks Data
Processor. This unifies the experience for users who have both Core defined and
Content Blocks defined types in their installation.

> [!NOTE]
> Before Content Blocks 1.3 the Content Blocks Data Processor returned the
> raw array for Types not defined by Content Blocks. Check your templates
> whether they can be simplified now.

### Publish Assets Command {#publish-assets-command}

The command `content-blocks:assets:publish` publishes your public Content
Block `assets` into the Resources/Public folder of the host extension. Normally,
this is performed automatically every time Content Blocks is compiled. In some
deployment scenarios this command could be performed in the CI pipeline to
publish assets without the requirement for a database connection.