Epic #98134
Updated by Lidia Demin over 1 year ago
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. h2. 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 h3. 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 Backend preview is only partially possible with custom tt_content fields * No future strategy h2. 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) or So there will be two major changes: * Extract FSC as a third-party extension * Merge "EXT:mask":https://extensions.typo3.org/extension/mask and "EXT:contentblocks_reg_api":https://extensions.typo3.org/extension/contentblocks_reg_api as a TYPO3 core component: TYPO3 Content Blocks h3. Implementation blocks and roadmap h4. Phase 1: *TYPO3 Content Blocks:* * Identify content block for a composer package * Define field types * Documentation * GUI for creation of content blocks via backend 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 h4. 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 h4. 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":https://github.com/orgs/FriendsOfTYPO3/ * Migration from FSC to Content Blocks * Migrate-Button for CType-Switches with CType Mapping → no mapping, no switching