Flexible Containers and Grids for TYPO3
How to add flexible in-page structures with a simple extension—the core way. TYPO3’s built-in concepts allow integrators to create setups for all kinds of page types, template types, and content management scenarios. Many projects end up needing more flexibility in placing substructures containing elements or modules within a content area. That’s precisely what our new Container extension is for!
This post is part of our Container Series
TYPO3 is a powerful tool for managing and presenting content in an element-based, structured form. b13’s Container extension allows the addition of layout “containers” to content areas. These can then contain modules and elements as optional variations to the main layout—think multi-column content, collapsible, accordion, tab container, and others. Container does this while following TYPO3 core best practices, keeping your site flexible, maintainable, and easy to upgrade.
Our container extension is an alternative approach to the Gridelements extension, born out of our experience working with it and the other options out there. We needed a more straightforward way to work. Ideally, we wanted a solution that introduced less overhead and complexity in the backend for our clients (e.g., no changes to existing backend wizards) and fewer risks for us (e.g., unintended data loss during upgrades and migrations).
Structure Pages With Core
TYPO3 offers a very flexible and customizable way of handling the layout and structural setup of any page template by using so-called “backend layouts.” A backend layout defines one or more content areas on a page where various content elements can be combined to create complex pages in an easy-to-use interface. Out-of-the-box, TYPO3 doesn’t support offering editors optional sub-layouts within these content areas, so you’ll need an extension.
Third-Party Extensions Add More Flexibility
There are several third-party extensions for adding grids, columns, and flexible element structures to the TYPO3 backend. From TemplaVoila! to Flux, several “multi-column” extensions, DCE and Grid Elements—we’ve seen them all in action, worked with (sometimes forced to work with) most of these concepts, and settled on Grid Elements for our projects in the past few years. While Grid Elements offered the flexibility we needed, adapting the backend page-level layout approach to a content-element level approach added a lot of complexity. We have struggled with updates, upgrades, and some of the concepts on a structural and database level.
Those Extensions made Upgrading to V10 More Difficult
We have been working with TYPO3 v10 in production since the week after the initial release of v10.0 in July 2019. Just like 18 months earlier, when version nine was released, we ran into incompatibilities between grids and structured elements. And the same scenario we faced before started to rear its ugly head: We migrated some elements to new custom content types to remove the need for third-party extensions. We postponed some updates in the hope of getting compatible versions of these extensions before the v10 launch.
From time to time, we thought about updating the extensions we needed ourselves. In itself, that is a viable option for some single-purpose extensions. However, most of these grid-generating extensions serve multiple purposes. Some change other parts of the TYPO3 system that may or may not have something to do with generating a container-type element. Investing the effort to upgrade a third-party extension to a new TYPO3 version, including all the code for features we never use, doesn’t make sense for us. And doing it without that doesn’t make sense for anyone else and will introduce new, potentially unexpected, problems for them or us down the road.
So we asked ourselves what we need in a grid- or container-generating extension and came up with a feature set and requirements that satisfy all our use-cases. We wanted a targeted solution that didn’t include unnecessary overhead or features. And we discussed what we would define as a “core-near” way of implementation, staying as close to TYPO3 core, best practices, flexibility, and “upgradability” as possible.
Please Welcome: Container!
The result is a new extension called ... *drum roll* ... Container. It adds containers as real content types, configured in a similar way to custom content element types. For integrators, container types work similarly to familiar solutions like the Grid Elements extension. You configure the “backend layout” for a content type using the same syntax as the Content Defender extension. Container adds data processors to render the content inside container elements in the frontend. And Container works in multilingual setups. And with Workspaces.
And that’s about it. Nothing more, nothing less. Our experience shows us that highly-targeted, “single-purpose” extensions offer practical advantages to our future selves: simpler maintenance, easier and less-risky upgrades, and cleaner code. Our Container extension does not solve other problems or change the behavior of TYPO3 in any other way. It just adds container elements, defined the same way as TYPO3’s core content element types. We can use containers for structuring content in multiple areas, like a two-column layout. We can use elements with pre-defined single-value fields and content areas for complex layout requirements—without resorting to flexforms for content.
When Should I use Container Elements?
Things you need to know about container elements:
- A container element structures content areas within a page template (see Fig. 1), adding a section to a page that “breaks up” a single content area into—in this case—two columns.
- They can be repeated and used multiple times on a single page: They are flexible and optional.
- A container can always hold multiple child elements of different types. It can hold several elements in a single container area to group these elements—for example, to have a common background color or background image, or to group a block of content into one collapsible container. Or to introduce multiple content areas within a page template area.
When to Avoid Containers
We do not use container elements to build page structures—that’s what the core backend layout concept is for. If you place all your content on a given page into a single container element (to be able to have a page layout with a sidebar, for example), you should consider adding a suitable backend layout instead. Because containers are optional, unlike layouts, they don’t “force” the page to have a given structure). If you don’t know what we’re talking about, consider yourself lucky. We have seen editor-headache-inducing setups like this too often to leave them unmentioned here.
We also do not use container elements to group or structure child content elements of a single type. An easy example would be a list of contacts, a list of links, a slider element with multiple slides, or a list of teaser elements. If all possible child elements are of the same type, we use a different concept we call “list elements”. Yes, you guessed it, there is a TYPO3 extension for that, too. Stay tuned. We’re preparing to release that extension, too!
So how do I get Container?
Installation
Install the extension using Composer:
composer req b13/container
That’s it—you can start creating and using container elements.
How Does it Work?
For a basic example, see Part 2. In Part 3 we will show an advanced example and explain all configuration options.
Thinking of Upgrading to TYPO3 v10?
Extensions such as Gridelements and Flux are just one of the areas you need to consider when planning your upgrade. We will be happy to help you analyze your instance for upgradeability, changes required, and cleanup for a smooth upgrade process.