- 1 Blueprint: Content Node Tree
- 1.1 Target Versions/Milestones
- 1.2 Goals / Motivation
- 1.3 Concept
- 1.4 Implementation Details
- 1.5 Risks
- 1.6 Issues and reviews
- 1.7 Dependencies upon other Blueprints
- 1.8 External links for clarification of technologies
Blueprint: Content Node Tree
|Proposal||Cleanup tt_content and make it extendable|
|Status||Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn|
|Current Progress||Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed|
|Topic for Gerrit||###gerrit_topic###|
- Started during TYPO3 CMS 7.6 development
Goals / Motivation
The idea is to make content elements in TYPO3 CMS easily extandable and reduce the complexity of tt_content. This will also add the possibility to create content node tree structures and therefore things like "gridelements" or Structured Content Containers will become obsolete.
Status Quo of content elements in TYPO3 CMS
TYPO3 CMS has a page tree that represents, in most cases, the structure of the website. Content elements are created on these pages and could be assigned to a column on that page (colPos) and sorted by a numeric value (sorting). Different types of content elements are defined by the "CType" that also defines how the element is rendered in the frontend. All those content elements are stored in the tt_content table which is the connection between a page and the content displayed on that page. The tt_content table has a big set of predefined fields like those described above and stuff like:
- title (contains the headline - is used for most content types like "text & media", "form", "table")
- subtitle (a field to store a subtitle)
- bodytext (this field is used to store a big text like the text of an "text & media" element which may also contain RTE code. But also thinks like "tables" or "forms" are stored in there text representation in this field)
- select_key (this is a field that is only used for the CType "list" which is a "plugin" (references to a custom controller))
- imageorient (this is only used to define how an image is displayed in the frontend like "top", "left", "right" ...)
- image_zoom (defines if the image should become "zoomable" in the frontend - the frontend functionality depends on the frontend implementation)
- ... and many many more ...
Most of those fields are very specific and are only used for special types of content but each content element has those fields as they are part of the tt_content table and content is stored there.
Custom content elements
Currently it's not really easy to create custom content element. Example: You would like to create a customt content element that contains 4 varchar fields: "title", "name", "phone", "email".
- Version 1:
You can missuse fields that are already there in the tt_content table. The first on is easy - "title" should be stored in the "title" field. The "name" could be stored in the "subtitle" field. But now we are at a point where we have to reuse existing fields and store data in them. We can use the "bodytext" field to store "phone" in it and the "email" could be stored in the "select_key" field. But in the end this is very very confusing as the fields contain data which is not represented by the fieldname.
- Version 2:
You could create your own fields and add them to the tt_content table. But this would bloat up you tt_content table and each content element has now also that field which may slow things down and costs much more space.
- Version 3:
You could store you custom fields in XML structures like done in many of those FCE and Grid extensions. But i think i don't have to list all the drawbacks of XML in the database.
- Version 4:
You can add fields by using the TYPO3 IRRE feature which allows you to inline edit a record in another record. But this is not really scalable as there is no best practice how to do that and where to store the relations.
The goal is to remove all those fields from the tt_content tables that are not really required to manage the content on the page. The tt_content table should only contain fields like "uid", "pid", "colPos", "sorting", "CType" (and the other basic fields like "hidden", "deleted", "starttime" ...). All the other data like "title" or "bodytext" should not be stored in the tt_content table. There are multiple ways to handle the real content like:
- Version 1: EAV model
For each datatype a table is added which contains the data related to a content elment.
|1||1||title||This is the title of the content element 1|
|2||1||subtitle||This is the subtitle of the content element 1|
|3||1||This is the email adress related to the content element 1|
- Version 2: Custom tables
Based on the CType a custom table can be conntected to the tt_content table. That means a content element with the CType "textmedia" will also load data from the table "tt_content_textmedia"
WIP I've currently no time to work on this