TYPO3 Core

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

Problems¶

• 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: https://decisions.typo3.org/t/remove-outdated-ctypes-and-fields/745
• 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

Vision¶

“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:

• Extract FSC as a third-party extension
• Merge EXT:mask and EXT:contentblocks_reg_api as a TYPO3 core component: TYPO3 Content Blocks

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:

• Instead of FSC fields for backend functions (open items, live search), use https://review.typo3.org/c/Packages/TYPO3.CMS/+/70162

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