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

Anyone developing TYPO3 extensions knows the scenario: A new database field means changes in five different places – ext_tables.sql, TCA configuration, Domain Model, Repository, and Fluid template. This costs time, causes inconsistencies, and makes maintenance a test of patience.

The good news: Two modern approaches eliminate this overhead: Content Blocks for declarative data structures and PHP 8.4 Property Hooks for lean Domain Models. Together, they reduce boilerplate by up to 80%.

Terminology  

Before we begin, a brief clarification of terms:

Table of Contents  

What You Actually Save  

First, an overview: What are the benefits of switching to Content Blocks?

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

Installing Content Blocks  

Install in just a few steps – depending on your setup, via Composer or the Extension Manager.

# 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 proven EXT:make extension – generates the complete basic 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 Call 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 multiple files:

Every change requires manual synchronisation. If you forget one place, discrepancies between the database schema and backend form threaten – 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 this, the extension automatically generates:

The Key Advantage  

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

In an era where AI-supported coding agents increasingly analyse, extend, and refactor code, the structure of the codebase determines success. Studies show: 65% of developers experience a lack of context during refactoring – a problem that is amplified by fragmented code.

"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  

Define a Content Element for team members – one YAML file is enough:

# 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, use the naming convention tx_extensionkey_domain_model_*. Only then will model generators and repositories function 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 offer automatic frontend rendering. Add the ContentBlocksDataProcessor to your TypoScript:

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

Afterwards, all fields are available in the template under {data.author_name}, {data.hero_image}, etc.

File Types: Extended File Metadata  

File Types extend the sys_file_metadata table with custom fields – perfect for photographers, 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 significant portion of classic Extbase models consists of repetitive getter and setter methods. PHP 8.4 Property Hooks change this 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) => $this->fullName = 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  

The combination of both technologies leads to a clear division of tasks:

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  

In addition to make:content-block, Content Blocks offers other useful 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 significantly simplifies multilingualism. You manage labels and translations centrally in a labels.xlf file within 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 not only reduces the initial development effort – it makes your extensions significantly more maintainable.