[TYPO3-core] (New) TYPO3 CMS Vision

[bernd wilke]

Am 26.08.14 00:04, schrieb 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).

+1
there are a lot of extensions I nearly never use. but as every software: 
it gots bloated with features someone needed once. and other features 
which get replaced by newer techniques are still available because 
someone might still use it.
being more modular everyone can activate just those features he actually 
needs

> * 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.

This might loose a whole bunch of TYPO3-'users'.
why? in my view we have more people who use TYPO3 than pure editors and 
developers. there are a lot of integrators which do a lot more than 
editors but are miles away from being able to program (especially in 
bigger concepts than old procedural programming) or handle developer tools.
these integrators are happy to have a TER where they find all extensions 
to resolve their problems. all in a nice(?) gui like EM.

maybe we can build up an infrastructure like the repositories for linux: 
you can register to a specialized TER and select your extensions from 
all available TERs. no need to work with git or zip-files (not everyone 
is so familiar with git and not everyone is able to access CLI on his 
server)

maybe we can have a TER for stable extension versions and another TER 
for beta versions and another one for nightly builds. selecting the 
appropiate TER can give the newest version neccessary within the used 
environment of EM and within the possibility to automate information 
about updates.

> * 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).

IMHO CSC should be one of many ways to start a FE rendering. (strictly 
speaking we already have multiple rendering schemes with the 
availability of older CSC-versions)
combined with a new structure for CEs (see my other posting) TYPO3 
should be modular to handle a wide range of individual and lean 
implementations.

> 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.

only in that way as integrators only use TER-extensions and a lot of 
developers move away from TER and so get lost from usage: e.g. 
gridelements 3.0 finaly reached TER. since 6.2ß users request a version 
to test (and give feedback) but the version was only available in a 
git-repository. how many downloads and feedbacks got it? I consider a 
big potential lost.
we have the possibility to mark extension versions as alpha beta and 
stable, but so old extensions mostly ignore this flag its information is 
ignored. aside of the possibility of differnt TERs all may prosper if EM 
supports a state selector.

and about 'esoteric format': as long as tools are available to handle a 
format it is not esoteric.
as EM lost the possibility to upload and store extensions in the last 
big rewrite the most important tool to generate t3x-files was removed.

bernd
-- 
http://www.pi-phi.de/cheatsheet.html