Epic #98134


Future of Content Elements in TYPO3

Added by Lidia Demin almost 2 years ago. Updated 3 months ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
Sprint Focus:


This epic describes, how CTypes (Content Elements) should be offered in future TYPO3 versions, what should be shipped by default, and how to ensure backwards compatibility.

Current state

The default CTypes and their rendering definition are shipped by EXT:fluid_styled_content:

  • EXT:fluid_styled_content:
    • TypoScript base rendering definition (lib.contentElement)
    • TypoScript rendering definition (per CType)
    • CType templates, layouts and partials
  • EXT:frontend:
    • Necessary tt_content fields (SQL)
    • CType definitions in TCA
    • TypoScript (tt_content = CASE)
  • EXT:backend:
    • Backend preview


  • Template and configuration are split into 3 extensions!
  • Some tt_content fields are rarely used
  • If not explicitly configured editors (meaning also admins) see a lot of information in the editing interface, that is unnecessary and confusing
  • This leads to discussions like this:
  • Not all CTypes are really usable by default with FSC (e.g. textpic is not responsive)
  • FSC specific fields for frontend representation are (mis-)used by TYPO3 for backend features like live search, backend preview, list module, my open records
  • A good backend preview is only partially possible with custom tt_content fields
  • No future strategy


“Defining ‘Content Elements’ in TYPO3 can be hard and the learning curve is steep. You need to learn PHP, TCA, TypoScript and Fluid and maybe even other languages.”
The Structured Content Initiative

Therefore, the goal is to:
  • Empower integrators/ developers with limited TYPO3 knowledge (e.g. beginners, frontend-only developers) to easily define CTypes
    • via a configuration file
    • via a GUI
  • Have only really necessary fields in tt_content:
    • system fields (e.g. uid, pid, ...)
    • fields defined by integrator
  • Enable integrators to define the backend preview
An integrator shall be able to decide if he/she wants to install
  • only selected (custom) CTypes or
  • a distribution/ meta package (e.g. FSC for all CTypes, minimal, menu, …, bootstrap-package)
So there will be two major changes:

Implementation blocks and roadmap

Phase 1:

TYPO3 Content Blocks:
  • Identify content block for a composer package
  • Define field types
  • Documentation
  • GUI for creation of content blocks via backend Module
  • Refactoring vue to LitElements in the backend module
Extract FSC from core:

Phase 2

Extract FSC from core:
  • Resolve dependencies of other system extensions to FSC (e.g. lib.contentElement, plugins)
  • Move all FSC-specific stuff from other system extensions to FSC

Phase 3

TYPO3 Content Blocks:
  • Improve UX
  • Mask / CB to Core Component Converter
  • CLI-Support (with strong defaults, like symphony does, or ruby on rails)
Extract FSC from core:
  • Extract FSC from core to FriendsOfTYPO3
  • Migration from FSC to Content Blocks
  • Migrate-Button for CType-Switches with CType Mapping → no mapping, no switching

Subtasks 1 (1 open0 closed)

Feature #99316: Move all Fluid Styled Content specific components to EXT:fluid_styled_contentUnder Review2022-12-08


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #94675: Improve the 'records overview' wizard for group elementsRejectedRalf Zimmermann2021-07-30

Actions #1

Updated by Lidia Demin almost 2 years ago

Actions #2

Updated by Lidia Demin almost 2 years ago

  • Related to Feature #94675: Improve the 'records overview' wizard for group elements added
Actions #3

Updated by Lidia Demin almost 2 years ago

  • Description updated (diff)
Actions #4

Updated by Benni Mack over 1 year ago

  • Subtask #99316 added
Actions #5

Updated by Nikita Hovratov 3 months ago

  • Subtask deleted (#98135)

Also available in: Atom PDF