Actions
Epic #98134
openFuture of Content Elements in TYPO3
Status:
New
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2022-12-08
Due date:
% Done:
0%
Estimated time:
(Total: 0.00 h)
Sprint Focus:
Description
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
- 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
- only selected (custom) CTypes or
- a distribution/ meta package (e.g. FSC for all CTypes, minimal, menu, …, bootstrap-package)
- 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
- 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 to FriendsOfTYPO3
- Migration from FSC to Content Blocks
- Migrate-Button for CType-Switches with CType Mapping → no mapping, no switching
Updated by Lidia Demin about 2 years ago
- Related to Feature #98135: TYPO3 CMS Content Blocks added
Updated by Lidia Demin about 2 years ago
- Related to Feature #94675: Improve the 'records overview' wizard for group elements added
Actions