Epic #84101
closedThe core must provide configurable structures for both pages and elements out of the box
100%
Description
The successor of this Epic is described by the official structured content initiative on their official page now:
https://typo3.org/community/teams/typo3-development/initiatives/structured-content
Based on this Blueprint http://wiki.typo3.org/Blueprints/StructuredContentContainers
we created https://docs.google.com/document/d/1Wui-vM1K9fOoSYgi5n_vZMFe59v5o2Qg0-HE4fy3e7c/edit#heading=h.kcy7kg7ngpnn as a common base for Epic, Stories and Tasks.
WHY - REASONS AND MOTIVATIONS¶
There are several reasons, why people are constantly asking for structured content or content structures in the TYPO3 core for more than a decade now.
Sometimes a flexible use of multiple columns or maybe even more complex layouts to structure content is required.
Depending on the role these people got in their daily business we identified the following motivations for three different groups of users in the TYPO3 universe - editors, integrators and developers.
Editors¶
- I want to speed up daily work so I want to apply certain actions to multiple elements at once
- I need a visual structure of a flexible amount of multiple columns both in frontend and in backend that can easily be rearranged and nested on the fly
- I want an interface to be as simple and intuitive as possible
- I need to be able to make use of structures and containers in multilingual environments and workspaces or combinations of both
- I want to be able to edit content within structures on mobile devices
Integrators¶
- I want future proof concepts for upcoming and existing CSS features and HTML structures so I need to wrap content elements with certain markup in the frontend output.
- I want to be in full control of the output still I would want to be able to create structures without having to nest containers
- I want a solution that works independently from a certain frontend framework but still would be able to represent the structures of a given frontend framework as far as possible
- I want to have an option to add specific custom configurations to different parts of the structure regarding frontend and/or backend behaviour and rights management
- I want to enable people to edit content on mobile devices
Developers¶
- I want to separate concerns of structures and containers from the creation of functional containers and custom content elements
- I want an API that enables me to use structures and/or containers for my custom solutions in my own sitepackage or other TYPO3 extensions
- I want a smooth migration path and a sustainable solution that can easily be maintained in the future and reuse content provided by existing extensions as far as possible
TERMS¶
To be able to define the stories and make their goals understandable for everybody, we need to define some basic terms.
Page¶
The outermost structure with the current versions of TYPO3 of course is a page.
Each page can have a certain backend layout to seperate that page into several regions.
Backend layout¶
Each page can have a certain layout attached to it, that seperates the page into regions.
These backend layouts are used to create a basic structure for editors in the backend view.
They can be directly attached to a certain frontend output, but they don't necessarily have to represent a frontend layout at all.
Region¶
Regions have been known as columns before, but we needed to find another term here.
Since the frontend output might not always be based on rows and columns but on CSS grids or other solutions, region is the new term.
Regions will get real names instead of having just numbers, so you will be able to fetch the content from "footer" instead of "colPos 0".
Section¶
Just like a page each region of a page can be split into several parts again, which are called sections.
Basically the same functionality we already know from pages applies to these sections too.
They can have backend layouts, called section layouts for better determination, and they can hold one or more content elements.
So sections are the actual "structured content" we are aiming for.
Section layout¶
Each section can have a certain layout attached to it, that seperates the page into even smaller regions.
These section layouts are used to create a basic structure for editors in the backend view.
They can be directly attached to a certain frontend output, but they don't necessarily have to represent a frontend layout at all.
Content Element¶
This is the term for any other of the usual content elements besides the structured content elements we are going to provide as sections.
Protocolls¶
- February 13th, 2019 - 20:00 - 22:45 CET: https://docs.google.com/document/d/1CDUhpemaTJ-P5oqjV8tzNQ0RBoAzKme70qBiFUF9Ktk/
- March 13th, 2019 - 18:00 - 22:09 CET: https://docs.google.com/document/d/1KR1DCxSmPWKKcCkbrytHtGFf8HajgX2ao6sJ4uK-iw4/
- April 17th, 2019 - 18:00 - 22:00 CET: https://docs.google.com/document/d/1p1nUT2g7vO1DrVkpGZ_uG0E6-IyDtT6_tgm_WIPM-Eo/
- May 8th, 2019 - 18:00 - 20:00 CET: https://docs.google.com/document/d/1cmCW2TAGBkH85uywGlTMZ524jm1ykBnRI9s197hp05c/
- June 17th, 2019 - 18:00 - 20:00 CET: https://docs.google.com/document/d/1HKnP1J2TBSnXesEsl4w-7qvimf-CbjJVveaVuJiHMYE/
The initiative has started:¶
https://typo3.org/community/teams/typo3-development/initiatives/structured-content/
Further reports will be done as news on typo3.org or as comments / todos in this issue.
If you want to participate or know more, contact us at TYPO3 Slack #cig-structuredcontent