[TYPO3-core] (New) TYPO3 CMS Vision
t3ng at bernd-wilke.net
Tue Aug 26 09:02:47 CEST 2014
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
> (WARNING: *HUUUUGE* diff - which just goes to further demonstrate this
> point's validity).
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
> * 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
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
> * 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
> 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.
More information about the TYPO3-team-core