GitHub Repository
list of entry points



The current TYPO3 v4 bootstrap was not touched for ages and suffers from several issues which make it slow and painful.

This document aims to build a general consensus about how the bootstrap of TYPO3 v4 core can be refactored. It outlines current weakest points and ideas on how they could be solved. Those things have already been discussed with different persons, some like to volunteer on this tasks. Since this is a lot of work we may spread this over multiple versions and will need to stay backwards compatible.


  • There are a lot of different entry points to the core (fe, be, cli, eid, ajax, wizards, install tool ...)
  • There are tons of duplicated codes throughout the different entry points
  • Current bootstrap is slow, the existing caching mechanisms are more or less evil hacks that do not fix the real problem
  • Most main bootstrap code is spaghetti code without method or even class encapsulation
  • We have no clean definition of what extensions can and should do during bootstrap
  • Nobody really understands the weird difference between ext_localconf.php and ext_tables.php
  • The bootstrap and the install tool are heavily wired


  • Switch to class scope as soon as possible
  • Make final global arrays cachable
  • Refactor existing core modules that still do not use mod.php as entry point
  • Have a central class to set up main bootstrap things in smaller methods (like path definitions, autoloader, db, ...) that can be combined for different needs: Re-Kickstarted by Thomas Maroschik, Ernesto Baschny during the T3DD11
More details:
  • TCA & friends:
    • It would be great if all those globals arrays like TCA and TYPO3_CONF_VARS would be objects instead of arrays.
    • We should add a generic class that implements the arrayAccess and arrayIterator interfaces. This way our new objects can stay completely backwards compatible, since they behave exactly like arrays as before.
    • We can add classes that extend the generic class for the specific needs of the global arrays. For example the TCA manipulation methods from extMgm can be moved to a tca class (and renamed in this run as well, like 'addPiToSt43'). This way we create a new API that defines exactly what an extension can do and what it is not allowed to do.
    • We should drop the ext_tables and ext_localconf files and come up with a new file that only uses the new API to register TCA, services and so on.
    • We could make the global arrays/objects 'read only' after bootstrap to prevent extensions from doing nasty things afterwards
  • Caching:
    • The old caching should be dropped, the cf should be initialized very early during bootstrap to use it in the autoloader already
    • The caching framework can be used to store our fully parsed global in a php cache. This way no more parsing is needed for TCA & friends, we can just require a needed file and have everything.
  • Entry points:
    • The different entry points should basically broken down to small methods / classes that call the different bootstrap methods for the specific environment. This will dramatically reduce code duplication

If we do it right, we could imho keep this system fully backwards compatible and drop old things later on.

I think these are the main points we could start with:

  • Start refactoring of init.php, index_ts and config_default by splitting code segments into methods while still staying in globals scope at this point.
  • Add the arrayAccess class and see how it works out if we switch some main array to this class (for example TCA).
  • Finalize the caching patches to drop old caching and use the cf in the autoloader already.

Note from Julle about "global arrays as objects"

  1. Changing $TCA into an object with ArrayAccess
    During T3DD11 the idea of changing the global TCA array into an object implementing SPL ArrayAccess popped up. This has been mentioned several times over the years, but never tried.

Since efforts to refactor the bootstrapping is going on, now would be a perfect time to do this, since it would allow a more sophisticated initialization, while allowing backwards compatibility.

Also introducing access modifiers and getters for properties would yield better control and security.

  1. The problems with ArrayAccess
    Unfortunately the PHP ArrayAccess implementation has some limitations:

1. Setting of values in multidimensional arrays are not supported.
2. The behaviour of PHPs array functions [1] are not predictible. Most work, some doesn't, and some behaves differently

Setting of values in multi-dimensions could be partly handled by checking values and if the value is an array, a new ArrayObject is instantiated an attached to the property. But that would only work for explicit initializations of sub-arrays.


  1. Options
    As we have no control over who writes what to the TCA an implementation would have the following options:

1. An enhancement of the TCA, where everything in the core is ensured to explicitly define all subarrays, but that is robust to entries that are normal arrays. A "sanitize" method could be introduced to walk through the TCA and convert subarrays, which could then be called internally before using methods depending on it. An assesment of the performance of such an operation would be crucial before introducing it.

2. Make a breaking change to all TCA write operations. In such a case it probably makes more sense to make it a completely new datastructure and get the full benefits of the change.

  1. Conclusion
    As introducing TCA as an object would introduce breaking changes and substantial risk, the benefits should be considered and evaluated very carefully. Most likely the cons would be more than the pros.

//julle 2011-07-09

Other information