TYPO3 Core

Summary¶

This issue occurs in the rare edge case when the TYPO3 cli dispatcher is called in a chroot environment and the site is delivered via a non-chrooted web server.

In this case, all classes in the class cache will be stored with PATH_typo3 as base path, except the TYPO3\Flow classes in the core extension. These are based on the __DIR__ constant, which according to [1] resolves symlinks that generates directory paths that are invalid outside of the chroot environment.

Example¶

Consider the following chroot environment directory layout:

<root>
\_ html
|   \_ typo3
|       \_ index.php
|       \_ ...
\_ home
    \_ www
        \_ /p123456 -> ../../

Note the backwards-recursive symlink that is required for processes inside the chroot (like a PHP process called from the CLI) to be able to resolve non-chrooted paths.

Now consider that the CLI dispatcher is called with the absolute path:

$ php /home/www/p123456/html/typo3/typo3/cli_dispatch.phpsh ...

TYPO3 will now build the PATH_site constant from the path of the called file, i.e. /home/www/p123456/html/typo3. This is a valid path both within the chroot environment (thanks to the backward symlink) and system-wide. This path is also used in the cache_classes cache that might be built during the CLI call.

This, however, is not the case for the TYPO3 Flow classes that are included in the core extension. In the core extension's ext_autoload.php, the magic __DIR__ constant is used as base path for all TYPO3 Flow class files. Since these paths are absolute, they are used in the cache_classes cache.

However, the __DIR__ constant resolves symlinks, and in the chroot environment will resolve to /html/typo3/... instead of /home/www/p123456/html/typo3/.... This results in invalid cache entries when the cache_classes cache is accessed in a non-chrooted context.

Suggested solution¶

Use PATH_typo3 as base path for the TYPO3 Flow classes. Change request in Gerrit will follow shortly.

[1] http://php.net/manual/en/language.constants.predefined.php