Attention

TYPO3 v7 has reached its end-of-life November 30th, 2018 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

There is no further ELTS support. It is recommended that you upgrade your project and use a supported version of TYPO3.

Autoloading

The autoloader takes care of finding classes in TYPO3. It is closely related to \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() which takes care of singleton and XCLASS handling.

As a developer you should always instantiate classes either through \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() or with the Extbase ObjectManager (which internally uses makeInstance() again).

Autoloading classes since TYPO3 7.x

TYPO3 6.2 was still delivered with a couple of different autoloaders, that all had different approaches and rules to find a class. This led to the naming conventions in and outside extbase and the optional ext_autoload.php file to load classes that didn't follow the conventions. Since TYPO3 7.0 all this is gone and there is only a single autoloader left, the one of composer. No matter if you run TYPO3 in composer mode or not, TYPO3 uses the composer autoloader to resolve all class file locations. However, the autoloader is little bit more sophisticated in composer mode as it then supports PSR-4 autoloading.

Loading classes without composer mode

This means, you did not install TYPO3 via a require-statement inside your composer.json. It's a regular old-school install where the TYPO3 source and the symlinks (typo3/ and index.php) are setup manually. In this case, every time you install an extension, the autoloader does the following:

  • First, it checks if extensions have a composer.json. If so, it will be evaluated and the autoloading definitions (only classmap and PSR-4) will be used.

  • If the autoloader did not find a composer.json it generates a classmap for the whole extension. The generated classmap is a huge array with a mapping of classnames to their location on the disk.

Important

The fallback mechanism (classmap of all classes in your extension) is quite handy but it can cause problems if you have classes with the same name in different extensions. This might happen if 3rd-party-libraries are shipped along with the extension classes and you have multiple extensions that come with different versions of the same library. It's a rare case but it can lead to a very frustrating debugging session.

Example:

<?php

// autoload_classmap.php @generated by TYPO3

$typo3InstallDir = PATH_site;

return array(
   'Schnitzler\\Templavoila\\Clipboard\\Clipboard' => $typo3InstallDir . 'typo3conf/ext/templavoila/Classes/Clipboard/Clipboard.php',
   'tx_templavoila_pi1' => $typo3InstallDir . 'typo3conf/ext/templavoila/Compatibility/class.tx_templavoila_pi1.php',
   ...
);

This method is failsafe unless the autoload information cannot be written. In this case, check the install tool for warnings and make sure that typo3temp is writable.

Troubleshooting:

If your classes cannot be found, try the following approaches.

  • Dump the class loading information manually with the following command: php typo3/cli_dispatch.phpsh extbase extension:dumpclassloadinginformation

  • If that command itself fails, please (manually) uninstall the extension and simply try reinstalling it (via the extension manager).

  • If you are still not lucky, the issue is definitely on your side and you should double check the write permissions on typo3temp.

Loading classes with composer mode

In composer mode, you completely rely on composer and its features. Thus you need to provide a composer.json with all necessary autoloading information for each extensions. See https://getcomposer.org/doc/04-schema.md#autoload to learn all possible ways to configure autoloading with composer.

Troubleshooting:

  • Dump the class loading information manually via composer dumpautoload and check that the autoload information is updated. Typically you would check vendor/composer to hold files like autoload_classmap.php and autoload_psr4.php etc.

Example:

$ tree vendor/composer
.
├── ClassLoader.php
├── LICENSE
├── autoload_classmap.php
├── autoload_files.php
├── autoload_namespaces.php
├── autoload_psr4.php
├── autoload_real.php
├── autoload_static.php
├── include_paths.php
└── installed.json

Best practices

  • If you didn't do so before, have a look at the PSR-4 standard. It defines very good rules for naming classes and the files they reside in. Really, read the specs and start using PSR-4 in your projects. It's unlikely that there will be any other more advanced standard in the near future in the PHP world. PSR-4 is the way to go and you should embrace it.

  • Even if you do not use composer mode and the class mapping of the autoloader allows you to use whatever you want, stick to PSR-4. It's not only a very good standard to find classes, but it will also help organizing your code.

  • PSR-4 is all about namespaces. No matter if you like namespaces or not, use them. Namespaces exist since PHP 5.3, so you will be able to use them in any modern TYPO3 project due to the minimum PHP requirements of TYPO3 itself.

Tip

PSR-4 is a standard that has been developed by the PHP Framework Interop Group (FIG). PSR-4 is an advanced standard for autoloading php classes and replaces PSR-0. If you want to know more about the PHP FIG in general and PSR-4 in specific, please visit https://www.php-fig.org/psr/psr-4/.