The class autoloader takes care of finding classes in TYPO3.
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance() is the generic way
throughout core and extensions to create objects. It takes care of singleton
and XCLASS handling.
A developer should usually instantiate classes using
makeInstance() - it is
the normal way to go. This has been a hard rule in the past. With younger core version
however, there are some situations where
new is used over
effectively dropping especially the direct ability to XCLASS:
- When dependent services are injected via Dependency Injection,
there is no need for
makeInstance(): Injecting a different object is done by configuration - that’s what dependency injection is for.
- Data transfer objects are often created with
new. A good example are PSR-14 events: The calling class creates a data transfer object that is hand over to the consumer. These DTO’s must never be changed by an extension, since they are a contract both caller and consumer must stick to. They are thus created using
newto prevent XCLASS’ing.
- Structures with a dedicated API that allows own implementations on a configuration
level sometimes do not use
makeInstance: Many core constructs come with API to allow custom classes by dedicated configuration. Those implement a factory pattern to deal with this. An example is the PSR-15 middleware stack.
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. Since TYPO3 7.0, there is only a single autoloader left, the one of Composer. No matter if you run TYPO3 in Composer mode or not (Classic Mode), TYPO3 uses the Composer autoloader to resolve all class file locations.
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/index.php) are setup
In this case, every time you install an extension, the autoloader scans the whole extension directory for classes. No matter if they follow any convention at all. There is just one rule: put each class into its own file. This also means that there can only be a single class per file.
You can also explicitly configure autoloading in the ext_emconf.php.
typo3conf/autoload_classmap.php is a large array with a mapping of classnames
to their location on the disk:
<?php // autoload_classmap.php @generated by TYPO3 $typo3InstallDir = \TYPO3\CMS\Core\Core\Environment::getPublicPath(); 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.
If your classes cannot be found, try the following approaches.
- Dump the class loading information manually with the following command:
php typo3/sysext/core/bin/typo3 dumpautoload
- 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
Loading classes with Composer mode¶
In composer mode, the autoloader checks for (classmap and
PSR-4) autoloading information inside
composer.json. If you do not provide any information, the autoloader falls
back to the classmap autoloading like in non composer mode.
- Dump the class loading information manually via
composer dumpautoloadand check that the autoload information is updated. Typically you would check
vendor/composerto hold files like
$ 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
- If you didn’t do so before, have a look at the
PSR-4standard. It defines very good rules for naming classes and the files they reside in. Really, read the specs and start using
PSR-4in your projects. It’s unlikely that there will be any other more advanced standard in the near future in the PHP world.
PSR-4is 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-4is 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.
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/.