In general I like the idea of hiding fields that might not be needed in a “standard” setup (whatever that may mean is up to interpretation, I hope this helps, although I feel it does not).
To cater to @dermattes, I’d say that this could be a selling point as well. Imagine having like two distributions of TYPO3:
one for the big girls and boys (like us), who have worked with TYPO3 for 10+ years and who "like it the way it is"™
one for the “beginners” who use TYPO3 for their hobby or association website and who do not know that they need to use spaceBefore or spaceAfter or wouldn’t even know what to do with that
Both distributions cab be built and maintained the same way, one just arrives with an additional configuration file (that is maybe installed via a dependency, let’s call it typo3/simplified which displays what a random set of people decided would be the bare minimum to have TYPO3 working.
This way we can try to solve the “TYPO3 is too complicated” to use issue, by giving the audience that feels this way a version that is not too complicated.
And cherry on top: maybe, just maybe, there could be an additional package, let’s call it typo3/configurator that allows people to configure what fields they’d like to see in whichever cType is available in their instance (regardless of their mode of installation, I guess the config/ folder is always availble in newer installations, so maybe config/overrides is somewhere where this could be written, and it could even be deployed, so much convenience).
I’m not saying, this is the perfect solution, but maybe there is an idea or two that could be picked up for v12 or v13 that are worth looking at (especially with @crell working on reworking configuration from the ground up).
I think that removing the Content Elements is a good idea.
But I’m against removing the Fields. They are often used. But I think that hiding them via TypoScript would be great. That way it is more simple for new users, and experienced users can make them with one line visible.
Maybe it could also done automatically, hiding all fields that don’t have more than one value to select.
I’m not quite sure what you mean by that exactly, but I’m afraid that would be in the direction of the doc team again? I think it’s a bad idea, because I think this is notoriously understaffed anyway, if I’m following this so correctly…
Otherwise, that would certainly be quite an option, not my favorite, but an option^^
Hiding those fields is just sweeping them under the rug.
They are still there: in fluid files, ext_tables.sql, TCA and language files.
And they are decreasing the performance within fluid files in every case, and they can become a relevant negative factor in the database in large scale installations.
Additionally I think hiding stuff with TSConfig is a bad practice.
Instead content elements should be defined positively and explicitly: every field they consist of should be listed within their TCA defintion.
This reduces complexity drastically. And I think alone the possibility that fields are hidable with TSConfig is one part that makes TYPO3 complicated. There are too much ways to achieve the same outcome.
One main problem of the way content elements are defined in TYPO3 is that you can reuse fields within different content elements without defining an explicit dependency.
What you want a content element to be within your application is a vertical slice with clearly defined borders and no bleeding in other areas. Reusing fields is such a bleeding, and it is hard to find. That creates a high barrier to clean up or even touch those fields, and that is what make fundamental changes in this area in TYPO3 so hard.
I propose to look what Neos is doing (that CMS that TYPO3 supposed to be at some point ) which gives a great impression about good UX concerning content elements: https://youtu.be/NOwNRnIxlWE?t=21390
tldr: You can make a great use case for the “layout” field actually (but I still recommend having a look at the talk)
quite interesting - for me that would be optimal, instead of having text selections, i would rather be for an arte preview images. Since a kind of “preview” image is simply more, better meaningful.
From that point of view, i miss this option for example with the field “layout” (something like the selection field for text left, text right, top bottom… etc. already has) - maybe a tick bigger so that one also recognizes something^^
Maybe you can hide something like that behind a “question mark” (something like “show me a preview of this layout”).
Text explanations are always difficult for me, especially if the layouts are only marginally different. (of course text is part of it, just because of accessability blubb…) but i think you know what i mean: a picture says more than 1000 words) ^^
You have my blessing. I also use only one text element and the other content elements are written per TCA so that they show the editor only the necessary fields of tt_content. If I ever need more fields, I extend the tt_content table accordingly.
if you want to change the fields layout and frame_class you should implement a better handling.
This was discussed years before but nobody had realized it:
As you could only select one value it’s not possible to add multiple classes which vary the output in a combined way.
e.g. have classes for different background-color, different kind of borders, different kind of font sizes.
Of cause this would be not needed in every instance, it would make handling easier and the necessity for multiple fields would be reduced.
I don’t know the current state, but the field layout formerly was used in the seldom used CEs like uploads to select what information was shown beside the filename (icon,size, date).
In this way I use it in some own CEs so a CE can be rendered as a carussel, an accordion, or a slider, as all can use the same data. Of course this can also be achieved if the same fields are used and the type of the CE is changed. but that could be a philosophical question: realize each variant as an own CE or use one CE with multiple variants (the former CE menu was split into multiple CEs for each variant)
e.g. have classes for different background-color, …
Since it is not needed in every instance, there is no reason to add it by default. It is even bad to do so. Integrators can add multiple fields and show them next to layout thanks to the power of TCA.
I’m working with TYPO3 for more than 15 years now and I love the TYPO3 ecosystem. But as already noted above: sometimes it’s hard to win the “fight” against other CMS because of the “complexity” of TYPO3. In a perfect world the TYPO3 integrator would provide a backend with only the relevant fields - which would help to increase the editor acceptance. I know that this can be complicated and time-consuming and therefore there are a lot of TYPO3 installations which show all the available fields and options to every editor.
As a reason of that I totally love the idea of cutting away all the not essential parts from the core and shift them to dedicated extensions. For performance reasons I would argue that moving them into extensions is by far better than just disable or hide them. Why load things that you will never need.
I read the arguments, that it would be complicated for beginners, but if someone is able to install TYPO3 via composer, he/she should be able to install another extension via composer as well. Furthermore, a hint in the docs should solve this “issue”.
Remove whatever fields you want. As soon as someone discovers EXT:mask, they will add dozens of new fields.
But one serious point: I’m wondering, why noone talked about removing the CType “html”. I mean, there is a great TYPO3 security team and extension authors, who fight against cross site scrpting issues. And on the other site, the CMS provides a plain HTML content element which, I’m sure, is enabled for editors in too many projects.
It’s up for every system administrator/ integrator to remove the HTML-CE for regular editors.
in our installations it is acessable for admins only.
In my opinion it’s very handy if you need some javascript and/or very special HTML (e.g. external content which is loaded by javascript) and don’t want to write a whole extension for it.
) which gives a great impression about good UX concerning content elements: 