--- title: TYPO3 is becoming a standard Composer project url: "https://b13.com/core-insights/typo3-and-composer-weve-come-a-long-way" description: Composer and TYPO3 have had a long journey together. Now, work done in v11 is paving the way for v12—so that TYPO3 can become a fully-realized standard Composer project and consequently, an even more secure CMS. date: 2022-02-25 modified: 2026-02-09 lastUpdated: 2026-02-09 --- # TYPO3 is becoming a standard Composer project ![](https://vg08.met.vgwort.de/na/deb01661f7684b5ca00058132e2bd958) Composer is the go-to swiss-army-knife dependency manager for PHP. It will tell you if a particular PHP library is working with another library and if it conflicts, it will update them accordingly. It also ships with an optimized autoloader to load PHP files and classes when they are needed. TYPO3 has improved its support for Composer over the years, and now we’re excited to say that preparatory work done in v11 is paving the way for v12 to be a standard Composer project, delivering a much more secure CMS. Why Composer? ------------- There are a lot of benefits to using TYPO3 in Composer Mode (similar to most other PHP-based applications using Composer): - **Maintainability** - A Composer manifest file (composer.json) in your project defines the minimum required versions for your mandatory packages—upgrading to a newer version is a matter of a few lines on the command line. - **Security** - you can set up a Composer project outside of the public web directory (“htdocs/” or “public/”). Composer then puts all non-TYPO3-related PHP files in a place where a web browser cannot access them. - **Automation and Teamwork** - You can set up a project with versioning control (Git) the same way over and over again without having to download all the source files from a production system. This strategy paves the way for proper deployment workflows. A Brief History --------------- ### In the Early Days Back in the early days (version 4.x), TYPO3 had a lot of “require\_once” statements. In TYPO3 6.2.8 we migrated to the Composer Autoloader, bringing a considerable performance gain. Since TYPO3 v6.2, it’s been possible to set up a CMS project with Composer CLI as a Composer-based project. We then distinguished between “Composer Mode” and “Classic Mode.” Composer fetched all the packages needed, and TYPO3 still behaves in most places as if it was a simple PHP application like in 2003. ### The Composer Journey TYPO3 has improved its support for Composer over the years: - In TYPO3 v7, we split temporarily generated resources for the public and internal files (such as log files) into two separate folders: TYPO3temp/assets/ and TYPO3temp/var - With TYPO3 v8.7.6, it was possible to only download the required extensions instead of having all extensions shipped with TYPO3 Core available. We moved all publically available resources of an extension into the “Resources/Public” folder. Any other file in an extension should not be exposed directly to the web. The only protection we had, though, was an .htaccess file. - TYPO3 v9 introduced the Environment API, which defined specific paths outside the public web directory. This change was the first step towards moving the temporary internal files and parts of the configuration to a different, non-public location with TYPO3 Core’s knowledge. - TYPO3 v11 is much stricter with its dependency handling. When in Composer Mode, TYPO3 no longer evaluates the “PackageStates.php” file containing all installed extensions. All available extensions are now always active. TYPO3 does not have to worry about installing extensions anymore. Stopgap Solution ---------------- When using Composer Mode, TYPO3’s Core Extensions and Third-Party Extensions still had to reside in `public/typo3/sysext/` and `public/typo3conf/ext/` respectively. A Composer plugin called “[TYPO3/cms-composer-installers](https://packagist.org/packages/typo3/cms-composer-installers)“ took care of this change during a ”composer install“ command. People from the TYPO3 community built this plugin back in 2014 so that we could have Composer Support without having to rewrite TYPO3 from scratch. It has served us well, but we’re conscious that it was a misuse of Composer’s way of dealing with dependencies—which usually reside in your PHP project’s “vendor/” directory. The New Feature --------------- With TYPO3 v11, we’ve prepared the way for a huge milestone. All Core extensions and third-party extensions are now moved to the `vendor/` directory (because they are actual Composer dependencies for your TYPO3-based website). We no longer not touch PHP classes needed for your TYPO3 project, and they are in a secure location outside of your public webroot. We’ve done a lot of preparation in TYPO3 v11 LTS, and the actual feature is available in the upcoming version 4.0 of the TYPO3/cms-composer-installers Composer plugin. Try it out now! --------------- You can give it a try in your TYPO3 v11.5.4+ installation. ### Step 1: Preparation There is a bit of housekeeping you’ll need to do before you jump in: 1. Ensure you load all your project-specific extensions via a path repository , and require them properly [via Composer](https://getcomposer.org/). These extensions all need a composer.json file and must be referenced via `composer req me/my-extension@dev` in your Composer manifest. 2. Check all your Fluid templates or TypoScript options to see if you still use “`typo3conf/ext/`“. They need to be replaced with Fluid ViewHelpers and TYPO3’s internal resource resolver. 3. Make sure your Frontend Build pipeline is not depending on putting assets into TYPO3conf/ext/site\_mysite/. We ran into this issue quite a bit with our Frontend Stack. 4. Put the “`public/_assets`“ folder in your `.gitignore` file. If you don’t want to spend time addressing these issues now, but you do want to continue updating TYPO3 v11 LTS versions, you can pin version 3 of our Composer plugin for TYPO3 v11. `composer req typo3/cms-composer-installers:^3` In the upcoming TYPO3 v12.0, the new plugin version will most likely become a requirement—so be sure to test your sites as soon as possible with TYPO3 v11. ### Step 2: Load the cms-composer-installers plugin Use the following command: `composer require "typo3/cms-composer-installers:4.0.x@dev"` If your project is already running with Composer, you can remove `public/typo3/` and `public/typo3conf/ext/` right away and run the command above. The final 4.0 version will be released some time in 2022, and will then be installed the next time you use “`composer update`“ in your TYPO3 v11 project. ### Result The public folders of our TYPO3 installations now look like this: - public/index.php (generated by our composer plugin) - public/\_assets/ (symlinks of Resources/Public/ folders of all installed extensions) - public/TYPO3/index.php (generated by our composer plugin) - public/TYPO3/install.php (generated by our composer plugin) - public/TYPO3conf/LocalConfiguration.php\* - public/TYPO3conf/AdditionalConfiguration.php\* - public/fileadmin/ (files uploaded by the editors) - public/TYPO3temp/assets/ (temporary files generated by TYPO3 internally) \*The two leftovers, “LocalConfiguration.php” and “AdditionalConfiguration.php”, will hopefully find their way into a non-public location in the upcoming TYPO3 v12. TYPO3 creates a new folder called `public/_assets/`, which symlinks all extensions‘ `Resources/Public/` folders into this directory. TYPO3 v11 will resolve all the links for you when using a logo or CSS file from an extension. The names of the subfolders are auto-generated IDs, which should not matter to you when referencing files. What you gain is a TYPO3 installation closer to a standard Composer project without hacks and—ultimately—a much more secure CMS. TYPO3 and Composer—A Long Friendship ------------------------------------ Thanks to Helmut Hummel. His TYPO3 Console project paved the way for many automation parts. Helmut, with the help of many other contributors, spent hundreds of hours to get to this point. We’ve worked together over the past seven years to achieve this milestone for TYPO3. If you still haven’t gotten around to using TYPO3 with Composer, I can only recommend it. [Contact us](https://b13.com/lets-connect) if you need help migrating your TYPO3 installation to Composer. Let me know via Twitter or GitHub what you think of this change! More Articles by Benni Mack --------------------------- [ Benni Mack 18 September 2026 What’s ext\_emconf.php? What’s TER? And that does it have to do with Composer? The success story of decade-long support and upgrade paths! ](https://b13.com/core-insights/core-insights/one-manifest-typo3-extensions-no-longer-need-an-ext-emconfphp) [ Benni Mack 27 January 2026 With TYPO3 v14, Camino introduces a default theme that removes friction from first installs. Why this matters—and how TYPO3 laid the groundwork. ](https://b13.com/core-insights/core-insights/blog/camino-the-need-for-a-default-theme-in-typo3-is-real) [ Benni Mack 21 February 2022 Composer and TYPO3 have had a long journey together. Now, work done in v11 is paving the way for v12—so that TYPO3 can become a fully-realized standard Composer project and consequently, an even more secure CMS. ](https://b13.com/core-insights/core-insights/typo3-and-composer-weve-come-a-long-way) [ Benni Mack 21 January 2022 In 2021, many individuals and companies sponsored bug fixes and new features in TYPO3. We’re grateful for their support! ](https://b13.com/core-insights/core-insights/thank-you-to-our-2021-sponsors) [ Benni Mack 22 February 2021 6 min. read I’m pretty sure that the new Folder Tree in TYPO3 v11.1 feature will make editors daily lives with TYPO3 easier. ](https://b13.com/core-insights/core-insights/typo3-new-folder-tree-and-javascript-frameworks) [ Benni Mack 10 February 2021 2 min. read Let’s see if we can improve TYPO3’s Page Tree, from a non-developer perspective ](https://b13.com/core-insights/core-insights/typo3-page-tree) [ Benni Mack 11 January 2021 1 min. read Welcome to Core Insights by b13 - what is this place? ](https://b13.com/core-insights/core-insights/episode-1-hello-world) ![](https://b13.com/core-insights/_pixel?page=622)