---
title: "Autoloading"
manual: "TYPO3 Explained"
version: "main"
permalink: "https://docs.typo3.org/permalink/t3coreapi:autoload@main"
source: "ApiOverview/Autoloading/Index.rst"
modified: "2026-09-16T13:05:25+00:00"
---

# Autoloading

The class autoloader takes care of finding classes in TYPO3.

## About `makeInstance()`

`\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance()` is a generic way
throughout Core and extensions to create objects. It takes care of singleton
and [XCLASS](https://docs.typo3.org/permalink/t3coreapi:xclasses@main) handling.

> [!NOTE]
> When dependent services are injected via [Dependency Injection](https://docs.typo3.org/permalink/t3coreapi:dependencyinjection@main), there is no need for `makeInstance()`:
> Injecting a different object is done by configuration - that's what
> dependency injection is for.

A developer can instantiate classes using `makeInstance()` \- if dependency
injection cannot be used. There are some situations where `new` is used
over `makeInstance()`, effectively dropping especially the direct ability
to [XCLASS](https://docs.typo3.org/permalink/t3coreapi:xclasses@main):

-   Data transfer objects are often created with `new`. A good example are
    [PSR-14 events](https://docs.typo3.org/permalink/t3coreapi:eventdispatcher@main): The calling class creates a data
    transfer object that is hand over to the consumer. These DTOs must never be
    changed by an extension, since they are a contract both caller and consumer
    must stick to. They are thus created using `new` to prevent XCLASSing.
-   Structures with a dedicated API that allows own implementations on a
    configuration level sometimes do not use `makeInstance`: Many Core
    constructs come with an 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](https://docs.typo3.org/permalink/t3coreapi:request-handling@main).

## Autoloading classes

There is one autoloader used, 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 with Composer mode

In Composer mode, the autoloader checks for (classmap and `PSR-4`) autoloading
information inside your extension's `composer.json`. If you do not provide
this, the autoloader falls back to the classmap autoloading like in
non-Composer mode.

### Troubleshooting

-   Dump the class loading information manually via

    ```bash
    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..
-   Check if you find the required class names in these files and install any missing extensions.

Example:

```none
$ 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
```

## 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 (`index.php`) are setup manually.

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 no longer evaluated](https://docs.typo3.org/permalink/t3coreapi:extension-declaration@main).

The generated `typo3conf/autoload_classmap.php` is a large array with a
mapping of classnames to their location on the disk:

**typo3conf/autoload_classmap.php**

```php
<?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**.

### Troubleshooting:

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

-   Dump the class loading information manually with the following command:

    ```bash
    php typo3/sysext/core/bin/typo3 dumpautoload
    ```
-   If that command itself fails, please (manually) uninstall the extension and
    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`.

## 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/](https://www.php-fig.org/psr/psr-4/).

## Further reading

-   [ComposerClassLoader](https://docs.typo3.org/permalink/t3coreapi:composerclassloader@main)