I would like to discuss a cleanup concerning content elements and its fields. Moving some content element types & fields to a 3rd party extension would simplify the available options and less to hide, document, explain and maintain.
I would like to move the following elements:
Divider (div)
Bullet list (bulletlist)
Text & images (textpic)
Further explanations
The elements divider and bullet list haven’t been used since ages by myself. Bulletlist can be easily replaced by a regular text element.
Text & images can be migrated to text & media
Cleanup of content element fields
To simplify the daily usage of content elements I suggest to move the following fields of tt_content to a 3rd party extension:
Layout (layout)
Frame (frame_class)
Space before (space_before_class)
Space after (space_after_class)
Append with links to top (linkToTop)
Further explanations
I am aware that having the fields “Layout” and “Frame” available is handy to apply additional CSS classes for styling. Nevertheless those fields are only useful if the integrator adds some values with a proper name and applies the correct CSS. By default the fields don’t add any value and makes it harder for beginners.
I am aware that many sites also don’t use the other elements like “text & media” because every use case is represented by its own content element which is created using e.g. mask, dce, flux or just plain TCA. Nevertheless I don’t want to discuss yet the plausibility of those elements.
Questions
Would it be ok for you to move the content elements to a 3rd party extension?
Would it be ok for you to move the fields to a 3rd party extension?
In general I agree that
a) we should consider moving the CTypes as mentioned (also “uploads”) to a third-party extension, maybe one extension for each CType. I also think that some fields might only be needed for these CTypes, so we could move them as well. This might be a good example and “best practice” on how integrators should be small “content-type” extensions for a specific use-case. In addition, I would even consider adding some handy functionality (a real lightbox feature for click-enlarge), or additional CTypes into core. Example: Slider, Gallery (yes, one could use textmedia, but “gallery” is IMHO more appropriate) or a “listing” CType, which could work with a CSV file or Excel file to show a table and update the table dynamically if the CSV or Excel file gets exchanged.
b) think we can move the mentioned fields to custom CTypes as well, especially “linkToTop” (nowadays there is one “to top” button per page, and not per CType) and “layout” which does indeed serve no purpose by default. Frame, Space before + after should actually ship with proper styles which could be adapted via Constant Editor.
So maybe (depends on the opinion of others) we could start with one by one (CType, field), taking the first one that most people can agree on?
Yes, these CTypes should be moved.
We also haven’t used these CEs for ages.
No, not all of these fields should be (re-)moved.
You’re right, per default most of them are doing nothing, so it’s hard for beginners to understand. But removing them would be even harder for beginners if they would need them.
Beginning with TYPO3 is mostly starting as an integrator. As an integrator, I wouldn’t like to care about PHP stuff just to have an additional field for switching my CEs layout.
Maybe, a better way would be to give these fields “real” default behavior. Options that really do visually change the layout. Of course, you should adapt these fields and the layout to your needs, but you would see the intention of the fields.
CTypes
I agree in all three - we currently use configurable list created in RTE, use only textmedia, and i can remember only about one or two uses of div in years.
Fields
We use space-before/-after in every installation, but we add two additional fields to manage margin AND padding before/after. So, manage all 4 fields with a 3rd party ext would be totally fine. Frame and layout is used often, but we disable it by default and readd it be CType. That would also be fine for me to be removed.
Never used linkToTop.
Yes, remove the three mentioned CE. In case of textpic, provide an Upgrade Wizard to allow migrating to textmedia (as we had in a previous core version).
Fields
layout: yes, I’d recommend to remove it (also in page properties). It is confusing to provide selections that don’t have a functionality by default. Also, the field’s integer value does not allow to set a descriptive name for styling classes („frame-layout-1“).
space_before / space_after: I’m indecisive here. You could argue that a website with proper styling won’t need those. But at some point, a usecase will come up on most projects. Also, the TYPO3 Core already provides styles for all options. So I’d vote to keep those.
frame_class: a valuable select field with pointless default options (e.g. indent classes for responsive websites). As Julian already pointed out, removing the whole field will make it difficult for beginners. So my proposal is to remove all options except Default and None. Then it can be extended more easily.
link_to_top: please remove. Never saw this used in a website on CE level.
Regarding the proposed new content elements from Benni:
I find it difficult to imagine a feature-complete gallery CE. Galleries could be styled with a grid or masonry layout. You need to specify image sizes and number of image columns per breakpoint. In short: you need a lot of styling, and in the end you will either write this yourself – or use a frontend framework. And I would strongly disagree with TYPO3 core depending on or promoting a single framework (be it Bootstrap, Tailwind or the like).
Hm, @just2b. Don’t know, why TYPO3 has frame_classandlayout. Nowadays, they seem to have the same functionality (Correct me, if I’m wrong). So, sure, one of these would do.
With the removal of the content elements I would have no problems. But I would have problems with removing the fields!
The assumption that everyone builds their own content elements is just that: an assumption! I know a lot of people who don’t do that, because very often it’s not even necessary.
If you outsource this to an extension, would it be guaranteed that it will be pulled along with future TYPO3 upgrades?
If not, I’m already scared of having to completely rebuild everything once layout and frame_class are gone for good.
This would probably lead to a lot of additional work for many agencies/freelancers/hobby users and would not be very good for the reputation of TYPO3.
Removing fields won´t (I agree with Wolfgang Wagners argumentation).
I saw many installation using one or even all of the mentiones fields and only a few with (useful) custom content elements.
Maybe en/disabling these fields via contant editor could be a good way and/or (if posible) set some useful defaults. If thats not possible → leave the fields empty or give a hint, that the output needs to defined.
Layout and frame class are completely different things. While frame class usually does exactly that, adding a CSS class to the outer frame (aka DIV) of a content element, layout is used in our projects way before in the rendering process.
In most of the cases we made use of it, we had a switch within TypoScript (later on within the Fluid template) that changes the HTML structure of the element based on the provided layout options.
i.e. we had “Default Card”, “Small Card”, “Large Card” and they provided different structures due to the different spaces they had available in the layout. So the small card and the large card got different image sizes and ratios and the large card got an additional text.
Of course one could do that with different CTypes too, but the idea was to provide just one CType “Card” with 3 different layout options to avoid flooding the new content element wizard.
Moving some contents and fields that we consider obsolete to an external extension is a comfortable way for agencies to take the time to adapt to the new good practices TYPO3 would propose, I think it’s a very good idea.
Usually I’m not one to keep things in place at all costs but this time I think that the selection of the content types we should move to an external extension is a bit arbitrary. It’s not possible to determine with certainty if an element is used a lot or not without having concrete statistics. Which we won’t have.
It is quite possible that many of us never use the divider, or frame_css and layout, but in fact other clients do. As far as a can read the previous answers, it seems that each of us will answer you differently
For example when you install the Bootstrap Package you can see exactly what those frame_css or layout fields are for and indeed, my agency use them the same way.
Another example, I use a lot for some sites (not all of them) the divider content (yes!) but not for what it did originally (a simple hr): mine “really” divides the colpos (it closes and reopens the div) and add background classes to create “sections like” system. It’s much more usable than containers because you can simply move the divider to decide when a background stops and another one starts.
A good intermediate step could be to change the TCA as a first step, because it would propose a new approach to organize the fields in the contents without deleting permanently the fields in the database.
Thus new projects would start on a more rational and current basis while platforms that need to migrate could simply reapply their own TCA if they really need to keep some fields.
From what I get from contributors, what bothers them most today is not the choice between many types of content, but rather :
the amount of fields in the form
the first tab (General) starts with everything that is not the content (title, subtitle, title alignment…) and that the really important data (like the image for an image content!) is in a second tab
contents can sometimes represent a very basic type of data (text, image, etc.) and sometimes a type of structured information (contact, call to action, etc.) there is no clear concept
So in short: yes, we need to do something to streamline content, a thousand times yes! but not just remove 3 types of content and 2 fields. Maybe we should work on a more holistic approach?
Devider: I condider it very important and use it very often, often with different layouts, to set up visual separators.
Bullet list: Since you don’t have links or other formatting (bold, italic) available, you better put them in the RTE anyway. Bulletlist is only a text formatting thing and belongs in the RTE. I always hide the CType for a long time and it can be deleted in my opinion.
Text & images: Some projects don’t have videos and I want to make it as easy as possible for the editors, so I like to use Textpic instead of Textmedia there. But maybe Textmedia can be restricted with a simple setting so that only images are allowed? In this case I would be happy about a small hint and can gladly do without Textpic, although a migration assistets would be very helpful.
Fields
I think the fields layout, frame_class, space_before_class, space_after_class are very important and I use them in nearly every project. I also find it very helpful that fluid_styled_content already automatically outputs CSS classes. The default layouts (1,2,3) and default frame_classes can be removed. The default space_before/after classes are very usefull.
I don’t use linkToTop that often, but I still think it should remain a core feature.
I don’t like a 3rd party extension in this context, because this means an additional effort for major updates. I think it makes more sense to have instructions that describe how to create such features with your sitepackage extension, in case something should be removed.
I agree with Rachel that we should have a broader approach about which types of content we want to have.
I really like the concept of 1 extension <=> 1 content element (CType) when moving CTypes out of a sysext.
I think we are all on the same page about:
Migrating textpic to textmedia.
I would also suggest:
Removing the layout “example” “Layout 1/2/3” select items from tt_content and pages. They are just there as an example and they don’t serve any purpose in a default install. Maybe we could even add a rendering option to TCA/FormEngine that hides that/a select field if there is only a single option. EDIT: Issues https://forge.typo3.org/issues/97562 and https://forge.typo3.org/issues/97563
I would not remove the field since it is one part of a type of “Content Framework” that we already have. Giving integrators an incentive to use it to provide “variants” helps with some TYPO3 commonality.
frame_class on the other hand duplicates the meaning of layout (although technically different for the HTML output): I think one of those should go.
Hi, I just want to mention, that fields like frame_class, space_before and space_after were been removed in Version 7 and they came back with Version 8. So I think, it wouldn’t be a good idea to remove them.
Except “to top”, I use the fields in nearly every project and would miss them.
Slider/Gallery: Sounds easy at the first shot, but those are all so different. Additional text, EXIF Data, you name it. Not sure if we find a common ground what should be there by default
Fields to keep:
space class before/after is actually quite valuable
I agree with Benni that moving all CTypes to separate extensions (except maybe the Text one, so you at least have 1 if you don’t install the other extensions) makes sense. This will also reduce the unused fields in tt_content for a lot of websites.
As for any new CTypes, if they’re in separate extensions, sounds good.
Fields
Not sure about the fields. Would I miss these fields? Probably not and if I do I’d probably add them through my site package. But I’ve worked with TYPO3 for a long time. I’m not sure if adding a class or “To top” link to a content element should be that difficult for developers who are more new to TYPO3.
Also if you move them all to a single extension it would mean that anyone who’d want one of those fields would get them all. And adding a separate extension for each field seems like overkill to me.
Like I said, not sure about the fields. For me it’s fine though.
You’re right. It’s possible to have a clear differentiation in using both fields.
(IMO we had the same use-case in a bigger project).
But if layout is for different layout variants of the same CE, then it’s similar to imageorient - and one of these two fields would be superfluous because both only differ in layout variants. Or not?
What does imageorient have to do with layout? In my opinion nothing at all.
With imageorient you control where the images or media files are placed in relation to the text in textmedia, textpic.
but this time I think that the selection of the content types we should move to an external extension is a bit arbitrary. It’s not possible to determine with certainty if an element is used a lot or not without having concrete statistics. Which we won’t have.
would love it!