[TYPO3-v4] TYPO3 boostrap for 4.6 and beyond

[Christian Kuhn]

Hey.

Ideas and conclusion from this post mostly evolved from my performance 
findings (see thread "Core performance for 4.6 and beyond"), so this 
post is a bit specific to this, but other topics for the boostrap are 
important as well.

There was already a workshop leaded by Francois on T3DD, some documents 
evolved from this, see [1].

What is boostrap?
Boostrapping TYPO3 is the initial process of setting up a working TYPO3 
environment to answer the request. Involved are things like registering 
the core autoloader, read localconf.php, figure out loaded extensions, 
establish a connection to the database and so on. With the current 
implementation it is not very clear when boostrap is actually finished, 
but these are the important files that handle most stuff:
* typo3/init.php - Main entry point of the BE
* typo3/sysext/cms/tslib/index_ts.php - Main FE entry point
* t3lib/config_default.php - Default TYPO3_CONF_VARS and php code which 
is shared between FE and BE
* typo3conf/localconf.php - Local TYPO3_CONF_VARS overriding defaults
* ext_tables / ext_localconf of extensions - Add stuff to $GLOBALS 
during bootstrap.

All of these files are run in 'global' scope, without any class 
encapsulation.

Several other files come into play at an early point, for example 
autoload and t3lib_extMgm.


Here are some problems we currently face:
* There are several other entry-points to TYPO3 specific to some needs. 
Examples are browse_links.php, showpic.php and so on. All of them 
already showed security, maintenance stability and duplicated code 
related issues in the past.
* The overall boostrap is messy, the code is hard to understand, hard to 
debug and hard to maintain.
* There are different 'access scopes', which are not handled 
systematically: We have FE, BE, CLI, eid and scheduler all mixed together.
* There are different cache layers which are all sub-optimal and hard to 
change and hard to interweave with other layers.
* Most of the boostrap code runs in 'global' scope, without any class 
encapsulation. This bloats heavily and is no good thing at all.


What I think we should come up with in the long run:
* We should find *one* entry point for TYPO3. It should handle all 
scopes (FE, BE, CLI, eid, scheduler, special scripts like browse_links).
* This code should switch to class based scope as soon as possible.
* Imho we should get rid of *all* global arrays (typo3_conf_vars, tca 
and so on). If we manage to do this we can refactor everything we want, 
we can interweave caching where we want. Detail: I think we can actually 
reach this if we introduce data classes for those arrays which implement 
arrayAccess SPL, we can even manage backwards compatibility if we 
declare them global for two versions.
* We should think about the difference between ext_tables and 
ext_localconf and if we need that anymore or how we could set up a more 
clear definition of which code must go where and what can and should be 
done at this level.
* We should be able to cache different global arrays (read: data 
classes), after they where set up the first time. This way we could 
remove the weird need of temp_CACHED* stuff and cache whatever we need.
* We should be able to prevent write access to globals data classes at 
some point in boostrap. Example: If everything was set up, noone has to 
fiddle with $typo3_conf_vars anymore. This could lead to a situation 
where we can define exactly what an ext_localconf or ext_tables (or some 
successor) is allowed to do.


What we can reach:
* Maintainable classes
* Better understandable boostrap
* Far better ways to cache things at different levels (example: cache 
full parsed TCA).
* Far better protection against extensions, clear definitions of what 
extensions can do and what they must not do.


Entry points:
* I'd personally like to start with removing the old caching, enable the 
caching framework by default for 4.6 and load it earlier to use it 
already in the autoloader.
* I think it *is* possible to encapsulate global arrays in data classes, 
together with maintaining much backwards compatibility
* Split current boostrap into smaller methods, refactor
* Split config_default into a array definition class and a code class


What do you think about all that? Who would like to step in?
Looking forward to input and opinions,
Christian


[1] 
http://forge.typo3.org/projects/typo3v45-projects/wiki/Initphp_enhancements