New CLI commands and better automation for Continuous Integration

TYPO3 can be installed via Composer, PHP’s standard for managing dependencies in a PHP project. With Composer all dependencies and third-party extensions are defined via the “composer.json” file in your TYPO3 project folder. This “Composer Mode” requires some interaction via the Command Line, but is better suited to work with versioning control systems (for example, Git), and deployment setups. 

Let’s take a closer look at the improvements in TYPO3 version 11 for such setups.

PackageStates.php is no longer evaluated

The PackageStates.php file is now history, at least for Composer-based TYPO3 installations. TYPO3 itself is built with extensions, and TYPO3 Core ships with 36 system extensions as of TYPO3 v11. Not all of them are required, so via Composer you can require–and thus load–only those extensions that you need for your website. For example, if you don’t need TYPO3’s “indexed search” because you’re using the Solr extension, then your code base is much smaller. Less code is always a good thing for maintainability and security. 

For non-system extensions, TYPO3 has always checked the typo3conf/ext/ folder for third-party extensions. The ones that are “active” (that is, recognized by TYPO3’s internal configuration management) are listed in the PackageStates.php file. In the past, we’ve been using Helmut Hummel’s great TYPO3 Console extension to create the PackageStates.php file on each Composer command as a custom script.

In TYPO3 v11, all of the required extensions of TYPO3 Core, and third-party extensions defined in composer.json, are always active. This is a convenient way to move closer toward Composer’s native concepts: that is, if you require a package, it’s active. If you don’t need it, just remove it via Composer. 

Upgrade to TYPO3 version 11, and the PackageStates file will never again be evaluated in Composer Mode. If you’ve already worked with the best practice in Composer—to have all required extensions active at any time—then you’re already prepared for TYPO3 v11.

CLI Command extension:setup

When activating an extension for the first time in TYPO3 via the Extension Manager, a few other interactions happen under the hood: Necessary database tables are created or extended, TYPO3’s caches are flushed, and if configured, some database imports happen.

This can now be executed by using the new CLI command extension:setup, which should be executed on the target system (e.g. production or staging environment) via vendor/bin/typo3 extension:setup. The last part is important to ensure that the actual database connection is used, and not a testing database. Re-running the command multiple times, for example, at each deployment, is no problem for TYPO3 v11.

Flushing and warming the caches

Helmut Hummel’s TYPO3 Console extension, which has pioneered TYPO3’s CLI functionality over the past 7 years, has had the important cache:flush command from almost the beginning. This command is especially important to use when a deployment on production has happened, to ensure new configuration is loaded. TYPO3 v11 ships the cache:flush command directly, with the possibility to only flush the caches for a specific cache group, such as the system-related caches.

Once the caches have been flushed, the next hit in TYPO3 backend or frontend takes a while in order to re-build the caches such as the Dependency-Injection Cache, or the Rootline Cache. Over the past versions, TYPO3’s cache handling system has improved, so TYPO3 v11 now ships with a cache:warmup which automatically loads the configuration of all extensions, making the next hit on the browser instantly fast again. And your editors won’t even notice a deployment.

Both commands are meant to be used on the target system – right after a deployment – and not on a CI server.