TYPO3 Version 9: Manage core patches with Composer

And it also means that you can no longer easily integrate core patches. You can find out how to do this in this article.

Instead, we can use the composer package typo3/minimal, for example. If we take a look at the sources at https://github.com/TYPO3 /minimal, we can see that the package is essentially just a meta package that integrates the following TYPO3 system extensions:

This procedure has many advantages: Only code that is actually used is loaded. This means that the sources are smaller and there are fewer security vulnerabilities due to code that is not used at all. The motivation behind this is described very well in this blog article.

But now to our actual problem: Let's imagine the unlikely event that there is a bug in the TYPO3 version we are using, for which there is already a patch but which has not yet been merged into the current version and which we would like to use in our TYPO3 installation.

This can be done with the help of the composer plugin cweagans/composer-patches and is described very well and clearly in this Blog article about patching TYPO3 and extensions up to version 8.7.

Unfortunately, the one large package typo3/cms no longer exists and therefore the patches provided at https://review.typo3.org cannot be used without further ado. Instead, you now have to check exactly which system extensions the changes in the patches relate to. If a patch refers to files from different system extensions, the patch must be split into one patch file per system extension. And then you have to create a composer configuration for each extension under extra/patches.

Here is an example:

Let's take the patch https://review.typo3.org/#/c/58979/ for TYPO3 version 9.5.1, which fixes a problem with the alias field in the page properties for multilingual websites (as of December 2018).

If you download the corresponding patch file and unpack the diff file it contains, you will notice that the following files are changed:

• /typo3/sysext/core/Classes/DataHandling/DataHandler.php
• /typo3/sysext/core/Tests/Functional/DataHandling/DataHandler/GetUniqueTranslationTest.php
• /typo3/sysext/frontend/Classes/Page/PageRepository.php

The patch therefore refers to the system extension core on the one hand and to frontend on the other.

We therefore have to turn the diff file into two diff files, each containing the changes for a single system extension.

In our new diff files, we simply omit the entire prologue of the original diff file, which starts with FROM in line 1 and ends with - before the first diff.

We copy the individual diff areas starting from the diff to the last line before the next diff into new diff files.

As no tests are supplied in the composer packages from TYPO3, we must omit the change to the GetUniqueTranslationTest.php file. This generally applies to files in the Tests subdirectory below a system extension. This is because these are not part of the composer packages from TYPO3 and therefore the patch could not be applied without errors.

We therefore create 2 diff files for this patch:

• Build
  • Patches
    • c1ce767_core.diff
    • c1ce767_frontend.diff

To integrate these patches via composer, we extend our composer.json as follows:

The names of the composer packages are derived from the name of the system extension with the prefix typo3/ cms-. For example, typo3/ cms-core for the system extension core.

To ensure that the patches are also applied, we must of course not forget the composer package required for this:

We can then install the patches:

It should be noted that subsequent local changes to the patches are not taken into account during a new composer install. The cweagans/composer-patches plugin offers a number of other configuration options, which are well documented on github.