Content Blocks: Q2/2026 Report and the GUI for TYPO3 v14

This report covers the work since the Q1/2026 report. One focus of this period was the Content Blocks GUI, which now supports TYPO3 v14 and has picked up the feedback we collected at the TYPO3 Camps. On the extension side, the 2.4.x and 1.6.x lines of the Content Blocks (content_blocks) extension brought a replaceable YAML parser, support for several Record Types on an existing table, and a set of improvements to the JSON Schema that shipped with the linter in Q1.

Version 1.0.0 of the Content Blocks GUI runs on TYPO3 v13 and v14 from a single, dual-compatible codebase. The Composer constraints are typo3/cms-* ^13.4.19 || ^14.3 and friendsoftypo3/content-blocks ^1.4.6 || ^2.0, so the same package works with Content Blocks 1.x and 2.x.

Version 1.0.0 also carries the fixes from 0.4.0, most of which go back to feedback from the Zurich, Switzerland, and Heidelberg, Germany, TYPO3 Camps. Vendor, name, and host extension are now marked and enforced as required fields, and Record Types additionally require a table and a label field. Basics that are incompatible with the current content type no longer appear, either in the Basics list nor in the field property dropdown. The two editor panes scroll independently, so the field configuration stays visible while you work through a long list of fields. Save & Close is blocked when required fields are missing, and it no longer leaves a stuck Saving… overlay behind.

The GUI remains a development tool for local and development environments. You use it to build and edit your Content Blocks and then commit the generated configuration and templates to version control. Install it as a development dependency:

composer require --dev friendsoftypo3/content-blocks-gui

The Content Blocks GUI was on the program of the TYPO3 Developer Days 2026 in Karlsruhe. The session walked through the module and included a live demo of what already works today. Details are in the schedule entry, Content Blocks GUI: Building Content Blocks Visually.

On 13 and 14 July, 52 TYPO3 Association members met at the TYPO3 Company offices in Düsseldorf for the TYPO3 Dialogue Days, and André Kraus attended for our team. The two days covered the planned restructuring of the teams, a new governance model, and how the project can be funded sustainably. The exchange was lively and at times controversial. A fair amount of well-founded criticism was raised, and several participants said the process itself had not been clear enough to them.

What stood out to us is that everyone in the room agreed on one point: they want what is best for the project and act on that basis. Having been at many TYPO3 Camps over the past months, we also noticed that we went in better informed than some other participants. We would take that as a hint. Formats like the camps exist for exactly this kind of exchange, and using them beats relying on second-hand accounts.

Speaking for our team, the proposed Unit Structure is the part that touches our work directly. From our point of view, the restructuring is an opportunity for better collaboration and less bureaucracy for team leads. We look at it with interest and are curious how it plays out in practice. One word from the discussion stayed with us: confidence. Confidence that the people we elected as a community intend the right thing. Confidence that this is a continuous process rather than a single attempt. And confidence that the people working on it collect feedback from many sides and do their best to bring it together.

Both branches received the same feature set again, 2.4.4 to 2.4.8 for TYPO3 v14 and 1.6.1 to 1.6.3 for v13. The changelog in the documentation has the details for each version.

Content Blocks reads its YAML files through the new ContentBlocksYamlParserInterface, so the parsing step can be replaced with your own implementation. The change came out of the work on the GUI, which reads and writes the same configuration files that the extension consumes at runtime. If you do not touch it, nothing changes for you, the default implementation stays in place.

ContentBlockData now accepts any implementation of RecordInterface, not only the concrete Core class Record. The main use case is the Core RecordCreationEvent, where extension authors can substitute a record object of their own, for example to encapsulate business logic. Such objects used to stop with an exception but now pass through the complete Content Blocks pipeline. Worth knowing: A few system properties exist only on the concrete class and return null for other implementations, so check for null in your templates if custom records are involved.

Content Blocks can add new types to existing tables, for example to extend tx_news_domain_model_news with a type of your own. Until now that worked for exactly one type per table, and even that one was not mapped reliably, because Content Blocks ignored the type field the table declares in its own TCA. It takes that into account now, so you can register as many Record Types per table as you need, each with its own type. The workaround of declaring typeField explicitly in every Content Block is no longer necessary.

Nested Content Elements, meaning a Collection with foreign_table: tt_content that renders like a Core column in the page module, now carry the colPos value of their child records into the generated grid column. This affects the button for creating a new content element and the edit links inside the nested preview. If you moved your nested elements to a dedicated colPos to work around backend layout restrictions, new elements created from the preview now end up in that same column instead of colPos 0. The underlying conflict between Collection restrictions and backend layout restrictions is still open.

The linter that shipped in Q1 was adjusted in both directions: loosening some checks and tightening others. renderType is now allowed on Text fields, which have always supported it at runtime. Previously, the schema rejected valid configurations such as an Iconpack field, and the only way to keep the linter green was to move the field into a separate TCA override. In the other direction, foreign_table is no longer allowed for Select fields inside a FlexForm Section container, because TYPO3 has not permitted database relations there since v13. The missing hideInUi property was added as well. All of this affects the schemas only, so your configuration behaves exactly as before, but content-blocks:lint reports it differently, which is worth knowing if you run the command in CI.

The documentation has a new guide for combining Content Blocks with Container Content Elements (container) extension, updated for Container 4.0.0. Content Blocks handles the Content Element definition, icon registration, and frontend template, while Container Content Elements takes care of the grid configuration and the backend preview.

Version 2.4.8 adapts to changes in Core internal classes and requires TYPO3 14.3.5. If you are on an earlier 14.3 patch level, update the Core together with the extension.

As in the previous quarters, most of the work on the extension came from Nikita Hovratov, who handled issues, reviewed pull requests, and implemented the features described above. The GUI was developed mainly by André Kraus. Tobias Gaertner contributed to the documentation for the first time, and Matthias Vogel improved the Composer setup of the GUI. Thanks to everyone who reported issues during this period.

The complete and always up-to-date list of releases is on GitHub. The tables below summarize the releases since the last report.

The next steps for the GUI are less about new features and more about making it harder to end up with a broken configuration. The module should catch more misconfigurations while you are still in the editor, instead of letting them surface later in the linter or at runtime. On the extension side, a few features are still on the list and will find their way into the 2.x and 1.x lines. Beyond that, we want to work out what we can contribute to the integration of Content Blocks into the TYPO3 v15 Core.

Testing helps us most at this point. If you build Content Blocks regularly, install the GUI in a development environment, run it against a project you know well, and tell us where it gets in your way.

You can find Content Blocks on GitHub and install it via Composer with

composer require friendsoftypo3/content-blocks

The documentation provides comprehensive guides for getting started and exploring advanced features.

Thank you for your great feedback so far! Please keep testing and sharing your thoughts with us. You can reach us in the #cig-structuredcontent channel on TYPO3 Slack, or join our calls on the first and third Monday of the month at 20:00 CET (19:00 UTC).

The Content Types Team