Structured Content Initiative—What Happened Between July and November?

Categories: Development, Community, TYPO3 CMS Created by Rachel Foucard
Photo: Dan Gold /
A lot of things have happened since our last update in July 2020. We’ve made progress on UX concepts, on content blocks creation, and on rendering strategies. Here is some important information about our latest achievements.

The Structured Content Initiative is the core Strategic Initiative focused on improving the content editing user experience in TYPO3 CMS. Read our last update to learn more about what we’ve been working on. 

Connect to TYPO3 Slack … and join us in the #cig-structuredcontent channel.

Welcome Paul Hansen to Our Team!

We are very pleased to welcome Paul Hansen to our initiative. For several months he has invested a lot of time helping with the tasks of our different groups. Here is a short introduction by our new member:

“Hello! I've really enjoyed collaborating on this initiative and putting my experience to work improving TYPO3. I live in Vermont, USA, and I've been building sites with TYPO3 since 2004. My agency, Ecopixel, provides TYPO3-powered web development and web design services to a variety of nonprofits, municipalities and outdoor adventure businesses, with a particular focus on serving conservation organizations. I'm also an avid skier, sailor and photographer.”

Latest Survey Results

This summer we launched two surveys to better understand editors’ preferences for viewing the frontend version of the pages they build, and their use of the mobile version of the backend. About 85% of the respondents of both surveys were “mostly technical” users (developer/integrator). Here is a summary of the answers we collected:

The “Mobile First” Survey

72% had never used the TYPO3 backend via mobile device, either because they didn't know it was possible or because they always have a computer at hand. This is probably related to the mostly technical profile of these users. For those survey participants who had used a mobile device, the primary reason cited was during an emergency, when it’s impossible to use a computer (54%). The second reason is when the user is on the move (in a train, subway, bus, waiting room, etc.) (31%). For those who use the TYPO3 backend in mobile version, it is mainly with a smartphone (92%) and not a tablet. Respondents reported that the user experience is good enough to modify existing content, or records such as news, addresses, etc. However, they mostly avoided creating a whole new page using their smartphones, or found the experience to be less than satisfactory.

The “Preview My Work” Survey

We asked participants about how they view their content in the frontend after creating a page, changing the pagetree, before making page edits, or after editing content. We learned that the View Module is rarely  used (between 0% and 7%), whatever the situation. When you want to view the frontend of an existing page before working on it, when you have just created a new empty page, when you have just created, modified, moved, deleted content inside the page, when you have just modified the page tree (renaming, moving or deleting pages), what do you use to view the result in the frontend? Instead, survey respondents were most likely to view the frontend page by:

  • Clicking the “view webpage” button at the top of the page module
  • Reloading the frontend of the page that is already open in another tab

So, what are we going to do with this feedback? Don't worry, we certainly won't decide that mobile support in the page module is unimportant. We believe it’s not being used much on mobile devices because it’s not good enough,  we will improve it in the new page module. The View Module feedback is relevant to both our initiative and the frontend editing initiative. It's an important part of the process of creating a page, and it deserves more consideration, with all the stakeholders, before finding the best solution.

The November Sprint

The first (remote) sprint of the TYPO3 Structured Content initiative took place on November 5-8, 2020. It was particularly productive, as we were able to make progress on many tasks, such as user stories, mockups, concepts, and even coding the new content block creation API and the new page module extension.

Content Block Creation

The API for content blocks registration has a lot of technical issues to consider: custom composer installer, validation of content block packages, generation of necessary code for TYPO3 (TCA, TSconfig, TypoScript) and of course, the big question of storage method. In order to have the main idea of our concept test-ready as soon as possible, we chose the “divide and conquer” approach, splitting the implementation into parts which we will deliver as an extension.

The first and most important part includes all key features of our concept:

  • Identification of a content block package
  • Generation of necessary code for TYPO3 (TCA, TSconfig, TypoScript)
  • Parsing the EditorInterface.yaml

Our research about performance on the persistence layer to identify the best suitable storage method for content blocks is still in progress. So, we decided to go for a Flexform-based approach first: generate a Flexform instead of pure TCA out of the EditorInterface.yaml and store it in the new field “content_block” in “tt_content.” This is only a temporary solution that helps us to accelerate the first deliverable and will be replaced in the next version.

For our API extension, we created the content-block-registration-api repository on GitHub and made tremendous progress during our code sprint. The extension currently features two installation methods: development with ddev, and the usual composer installation to just use the API for your own content blocks in a project. It does a basic validation of a content block package (Are all necessary files present? Is the EditorInterface.yaml in a valid YAML format?) and then registers it in TYPO3. It also brings a number of example content blocks which are located in the “Build/packages” folder.

We also made a lot of progress on the mapping of Symfony-based field types used in the EditorInterface.yaml to TCA. You can find a definition of all currently mapped field types in YAML and its matchingTCA definition in the “example-local” content block.

The extension still needs some fine-tuning, but it can already be tested. Your feedback is highly appreciated! Please use GitHub’s issue tracker or contact us directly on Slack in #cig-structuredcontent-contentblockcreation.

Our goals for the next version are:

  • Migrate the registration draft to documentation to the API extension repository in RST format
  • Add field mappings to documentation
  • Schema validation for the EditorInterface.yaml
  • Identification of the proper storage method to move away from FlexForms.

Apart of coding, we also raised two questions on that we need your feedback on:

Page Module

The new page module will have a cleaner interface, with a new content creation wizard, and will offer a dynamic grid system out of the box. We have identified several steps to divide our work into deliverables that can be tested as an extension. Also—and this is important to mention—the accessibility of this module will be considered during all the steps.

Of course, not everything was finished in a single sprint and we have to keep working on the different stages. However, here are some screenshots to illustrate what is in progress:

First step: Page module simplification

Less visual pollution, only important information at the right time and in the right place.

Second step: New content creation wizard

The use of drag-and-drop, click-and-click, touch screen, and keyboard is also optimized even at this step.

Third step: Dynamic grid system

As far as the backend is concerned, the dynamic grid system will be based on CSS Grid Layout. This solution has many advantages and offers a simple and modern method for editors to quickly structure content blocks in a freely “divisible” area.

Some complex questions needed a simple answer: If an editor adds new content in a new column, what should its ideal size be? How would we resize the other existing columns correctly? How would we guess what the editor would prefer?

What do editors want when they need to visually structure a page? Sometimes, they need to divide the content into perfectly equal parts whether it is for 2, 3 or 5 columns. Sometimes, they just want to give more space to one content or less space to another, without needing to know the multiples of 12, or to subtract to get 100%. They don't have time for that.

This is where fractional CSS units go from the status of "boring mathematical calculation" to the status of "obvious solution to all our problems.” Of course, we are certainly not going to ask the editors to calculate fractions—TYPO3 will do it for them. They will simply think in "pieces,” like pieces of a cake. An editor might say, "I need 3 equal parts," or "this content should take twice as many parts as the others.” This is how editors need to think about their content, because its position and the space it takes up on the page corresponds to editorial logic, its importance, its priority, etc.

We will do a more detailed article soon on the different behaviors of the dynamic grid system. For now, here is a very short and simplified video of what we have planned:


Star and watch the TYPO3 Structured Content repository on GitHub to be notified of upcoming feature issues.

Connect to TYPO3 Slack … and join us in the #cig-structuredcontent channel.

The Structured Content Initiative team.

Additional contributors for this article
  • Proofreader : Paul H
  • Content Publisher : Mathias Bolt Lesniak