TYPO3 Content Blocks & PHP 8.4 Property Hooks: Less Code, More Control

Anyone who builds TYPO3 extensions knows the drill: a single new database field means edits in five separate places, ext_tables.sql, the TCA configuration, the Domain Model, the Repository, and the Fluid template. It is time-consuming, it breeds inconsistencies, and it turns maintenance into a test of patience.

The good news: two modern approaches do away with this overhead. Content Blocks handle declarative data structures and PHP 8.4 Property Hooks keep Domain Models lean. Together, they cut boilerplate by up to 80%.

Terminology  

Before we dive in, a quick clarification of terms:

Table of Contents  

What You Actually Save  

First, an overview: what do you gain by switching to Content Blocks?

Relative effort in percent – 1% represents fully automated (no manual effort). Lower is better.

Installing Content Blocks  

Installation takes just a few steps, via Composer or the Extension Manager, depending on your setup.

# Install Content Blocks extension
composer require friendsoftypo3/content-blocks

# Flush caches and update database
vendor/bin/typo3 cache:flush -g system
vendor/bin/typo3 extension:setup

Creating New Content Types via CLI  

The make:content-block command, inspired by the well-established EXT:make extension, scaffolds the complete base structure for a new Content Block in seconds.

Interactive Mode  

# Start the wizard – it guides you through all options
vendor/bin/typo3 make:content-block

Direct Invocation with Parameters  

# Create content element in one go
vendor/bin/typo3 make:content-block \
  --content-type="content-element" \
  --vendor="webconsulting" \
  --name="team-member" \
  --title="Team Member" \
  --extension="my_sitepackage"

Available Options  

After Creation  

# Flush caches (important!)
vendor/bin/typo3 cache:flush -g system

# Update database schema
vendor/bin/typo3 extension:setup --extension=my_sitepackage

The Problem: Fragmented Truth  

In classic TYPO3 extensions, the definition of a single field is scattered across several files:

Every change has to be synchronised by hand. Miss one spot, and the database schema and backend form fall out of step, a classic breeding ground for bugs.

The Solution: YAML as a Single Source of Truth  

With the Content Blocks extension, you define structure, type, and validation in a single place. From that, the extension automatically generates:

The Key Advantage  

Why a Single Source of Truth is Essential in the Era of AI Agents  

As AI-assisted coding agents increasingly analyse, extend, and refactor code, the structure of the codebase decides whether they succeed. Studies show that 65% of developers run into a lack of context when refactoring, a problem that fragmented code only makes worse.

"AI agents rely on the context provided by the codebase to generate relevant code. A poorly organized codebase can lead to 'context rot,' where the agent misses dependencies and produces suboptimal code."

— PropelCode: Structuring Codebases for AI Tools

Code Example: Team Member as a Content Element  

Defining a Content Element for team members takes just one YAML file:

# ContentBlocks/ContentElements/team-member/config.yaml
name: vendor/team-member
title: Team Member
description: Display a team member profile

fields:
  - identifier: full_name
    type: Text
    label: Full Name
    required: true
    
  - identifier: position
    type: Text
    label: Position / Role
    
  - identifier: email
    type: Email
    label: Email Address
    
  - identifier: biography
    type: Textarea
    label: Short Biography
    enableRichtext: true

Record Types: Defining Custom Records  

The Content Blocks extension is not limited to Content Elements in tt_content. With Record Types, you create your own database tables, ideal for news, products, events, or other structured data.

Content Elements vs. Record Types  

Extbase-Compatible Table Naming  

Important: for seamless integration with Extbase repositories, follow the naming convention tx_extensionkey_domain_model_*. Only then will model generators and repositories work correctly.

# Extbase-compatible naming
table: tx_mysitepackage_domain_model_news

Example: News Article as a Record Type  

A complete news system in one YAML file:

# ContentBlocks/RecordTypes/news-article/config.yaml
name: myvendor/news-article
table: tx_mysitepackage_domain_model_news
labelField: title
languageAware: true
sortable: true
softDelete: true
trackCreationDate: true
trackUpdateDate: true
restriction:
  disabled: true
  startTime: true
  endTime: true
security:
  ignorePageTypeRestriction: true
fields:
  - identifier: title
    type: Text
    required: true
  - identifier: teaser
    type: Textarea
  - identifier: bodytext
    type: Textarea
    enableRichtext: true
  - identifier: image
    type: File
    allowed: common-image-types
    maxitems: 1
  - identifier: publish_date
    type: DateTime
  - identifier: author
    type: Text

Page Types: Defining Custom Page Types  

Page Types extend the pages table with custom page types, ideal for blog articles, landing pages, news pages, or other page types with special properties.

When to Use Page Types  

Example: Blog Article as a Page Type  

# ContentBlocks/PageTypes/blog-article/config.yaml
name: myvendor/blog-article
typeName: 1705234567   # Unix timestamp as unique ID
group: default
fields:
  - identifier: author_name
    type: Text
    label: Author
  - identifier: teaser_text
    type: Textarea
    label: Teaser
  - identifier: hero_image
    type: File
    allowed: common-image-types
    maxitems: 1
  - identifier: publish_date
    type: DateTime
    label: Publication Date

Integrating the Frontend Template  

Page Types do not provide automatic frontend rendering. Add the ContentBlocksDataProcessor to your TypoScript:

page.10 = FLUIDTEMPLATE
page.10 {
    dataProcessing {
        1 = content-blocks
    }
}

All fields are then available in the template as {data.author_name}, {data.hero_image}, and so on.

File Types: Extended File Metadata  

File Types extend the sys_file_reference table with custom fields, perfect for photographer credits, copyright notices, or additional image options.

Available File Types  

Example: Extended Image Metadata  

# ContentBlocks/FileTypes/image-extended/config.yaml
name: myvendor/image-extended
typeName: image
prefixFields: false
fields:
  - identifier: image_overlay_palette
    type: Palette
    label: Extended Image Options
    fields:
      - identifier: alternative
        useExistingField: true
      - identifier: description
        useExistingField: true
      - type: Linebreak
      - identifier: photographer
        type: Text
        label: Photographer
      - identifier: copyright
        type: Text
        label: Copyright Notice
      - type: Linebreak
      - identifier: crop
        useExistingField: true

PHP 8.4: Property Hooks Replace Getters & Setters  

A large share of every classic Extbase model is taken up by repetitive getter and setter methods. PHP 8.4 Property Hooks change that fundamentally.

The Paradigm Shift  

<?php
declare(strict_types=1);

namespace Vendor\TeamExtension\Domain\Model;

class TeamMember
{
    // Simple property without logic – no hook needed
    public string $position = '';
    
    // Property with transformation logic
    public string $fullName {
        get => strtoupper($this->fullName);
        set(string $value) => trim($value);
    }
    
    // Property with validation
    public string $email {
        set(string $value) {
            if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {
                throw new \InvalidArgumentException('Invalid email format');
            }
            $this->email = strtolower($value);
        }
    }
    
    // Virtual property – no database column
    public string $slug {
        get => str_replace(' ', '-', strtolower($this->fullName));
    }
}

Concrete Advantages of Property Hooks  

What Property Hooks Enable  

The Synergy: Content Blocks + Property Hooks  

Combining the two technologies gives you a clean division of labour:

The Result:

• YAML defines the data structure (Single Point of Truth)
• PHP Models now only contain business logic (Property Hooks)
• No more boilerplate for TCA, SQL, or trivial getters/setters

Overview of Additional CLI Commands  

Alongside make:content-block, Content Blocks ships several other handy commands:

# Show all Content Blocks
vendor/bin/typo3 content-blocks:list

# Generate language files
vendor/bin/typo3 content-blocks:language:generate

# Publish assets
vendor/bin/typo3 content-blocks:assets:publish

Internationalisation (i18n)  

Content Blocks makes multilingual sites far simpler. You manage labels and translations centrally in a labels.xlf file inside the Content Block folder.

Folder Structure  

ContentBlocks/ContentElements/hero-banner/
├── config.yaml
├── language/
│   ├── labels.xlf          # Default language
│   └── de.labels.xlf       # German translation
└── templates/
    └── frontend.html

Using Labels in Templates  

<!-- Access labels.xlf -->
<f:translate key="{cb:languagePath()}:my_label"/>

<!-- Label from another Content Block -->
<f:translate key="{cb:languagePath(name: 'vendor/other-block')}:shared_label"/>

Making Record Types Multilingual  

For Record Types, activate languageAware in the config.yaml:

name: myvendor/news-article
table: tx_mysitepackage_domain_model_news
labelField: title
languageAware: true   # Activates translation fields

Tooling and Resources  

Conclusion: Act Now, Profit Later  

The combination of TYPO3 Content Blocks and PHP 8.4 Property Hooks does more than cut the initial development effort; it makes your extensions far more maintainable in the long run.