[TYPO3-core] (New) TYPO3 CMS Vision

[Claus Due]

If I may chip in here. In order of priority:

* Stop shipping so many rarely used extensions. The core should be made lighter - and I am not just talking about the execution time. Git cloning time, zip archive size, IDE scanning times - everything suffers from the current "every egg in one basket" approach. There's a number of extensions which I personally have already proven can be separated completely, without errors - see github.com/NamelessCoder/TYPO3.CMS/commit/cce9d429017de26842ac5c28a766f292fddf89af (WARNING: *HUUUUGE* diff - which just goes to further demonstrate this point's validity).
* Make TER not the only distribution channel for extensions: allow Composer support as well as GitHub hooks or even an official GitHub application that lets you attach a listener which creates new TER release records based on new git tags. This is both for developers and users: developers will have an easier life and users will have more frequent updates which match 100% with what you would find on GitHub as downloadable tag-zips.
* Move away from TypoScript into standard formats. Use more Fluid. In extension hereof, don't ever, ever integrate TypoScript2 and Eel in CMS unless as optional extensions. Do not ship them as disabled extensions either (as discussed in the first point).
* Remove css_styled_content from the core. Let users choose. And try to loosen the coupling that currently exists in the core, which gives CSC integration possibilities by specifically adding CSC as supported target (I'm thinking about the contentRender integration specifically).

Those are my own major irks and fears for TYPO3 currently. There's a huge amount of bloat I've never used myself or for any client during years and years and TER, while it certainly has been improved, still depends on an esoteric format and has zero integration with outside APIs (except for a newly added option to upload zip files).

If extensions are what vitalises TYPO3 (and I believe they are) then TER is currently a bottleneck.

A few replies to Alex Kellner:

> I think we should think about a replacement of css_styled_content to something like fluid_content

Look no further: github.com/FluidTYPO3/fluidcontent_core - to be published very soon. By the way, this extension also removes rarely used fields as your other point requests.

> FCE to core (and the discussion should not focus too much on technical details).

I whole-heartedly disagree. If you mean *column* elements then yes; this should be a native core feature, with proper recursiveness support and relation handling, all the bells and whistles. To this: YES!

If you mean some way to configure new elements using DB records or TypoScript then absolutely NO. I've personally tried to popularise the approach of storing compact form structure representations along with the rendering in a Fluid template and this is, in my humble opinion, the option that makes sense. Furthermore I've tried to press the idea that site templates should be stored in an extension, as files - not as database content.

I do like to think that "Fluid Powered TYPO3" contains many of the ideas that could, but don't necessarily have to be, core features: using Fluid files as page template files and content elements 1:1 and letting users select them; finding a dynamic replacement for XML FlexForms (in this case, also one that's integrated in each template). Using ViewHelpers (optionally custom looping and rendering), not TypoScript, to generate menus and pick content to render. Generally speaking, moving far away from the CMS traditional "TypoScript is a programming language" approach over to the "TypoScript is declarative, PHP is the programming language and Fluid is for (HTML) templates" approach. Plus, the features rely on *conventions* rather than configuration; template files, configuration settings, public resources - everything in its right place because conventions are enforced.

But it also works fine separately from the core and third-party extensions won't bloat the core for those users that don't wish a particular feature. That's why I don't include these as priorities for the *core*: no need to ship what can just as well be modularised.

Cheers,
Claus

PS: excuse the non-links, but according to the forum I have to spam another two messages in order to not be considered a potential spammer and be allowed to use actual links like a big boy.