TYPO3 v12.3—FREEZE

The TYPO3 core developers have been super busy in the last few weeks to bring in all the features we promised to deliver in the TYPO3 v12 release cycle. Our community of amazing developers and talented contributors from various backgrounds also helped bring this release over the line. Thanks to all this effort, we can proudly claim that TYPO3 version 12.3 is now feature-complete.

Our focus until the long-term support release in April is now on completing and improving existing features and polishing the user interface where required. Therefore, we encourage agencies to consider using TYPO3 v12 when building production sites and to leverage all the new technologies and features. This, in particular, applies to projects with long development timelines.

Let’s have a closer look at the main changes of the new release. Detailed technical insight with more in-depth information is available at docs.typo3.org.

You likely recall the new function “Reactions” introduced in TYPO3 version 12.1 (see release announcement). This feature lets integrators and administrators configure TYPO3 to react to incoming webhook calls.

To complete the objective defined in the overall goals for TYPO3 v12, the system can now also send event notifications to other systems through outgoing HTTP calls. This feature is called “Outgoing Webhooks” and comes with a new backend module System ➜ Webhooks that lets you configure the requests.

First, select an event from a predefined list of events (for example, when a frontend user fails to log in). Then, you assign a name and the target URL that TYPO3 should send the request to. A description is optional, but you have to generate a secret token. The secret can be used in the system that receives the webhook request to validate the data included in the request.

You can also provide additional data in the payload and add HTTP headers to fine-tune the HTTP request as required.

Automating tasks is a great way to reduce effort and mitigate risk—especially when working with integrated systems that are communicating with each other, exchanging data, and triggering remote functions. With TYPO3 v12 LTS it is now possible to configure incoming and outgoing webhooks. The special aspect of Reactions and Outgoing Webhooks is that TYPO3 does the heavy lifting for integrators and developers.

As a developer, you will now certainly ask yourself what actions you need to perform to register your events as outgoing webhooks. The answer is simple: you literally only need to add one line of PHP code to an event class. The TYPO3 documentation describes how to implement a PSR-14 EventDispatcher. To make an event available in the System ➜ Webhooks backend module, you tag the class with the attribute “TYPO3\CMS\Core\Attribute\RemoteEvent” as shown in the changelog.

If your project requires TYPO3 to send a custom webhook without the need for an integrator or administrator to configure anything, you can bypass the backend module by leveraging the TYPO3\CMS\Webhooks\Factory\WebhookInstructionFactory.

It’s worth pointing out that outgoing webhooks go through the message queue/bus that we implemented in TYPO3 version 12.2. See the TYPO3 documentation for further details.

Another highlight of TYPO3 version 12.3 is the new feature to conveniently configure Content Security Policies (CSP) for the backend and the frontend. The MDN Web Docs describe CSP as follows:

“Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.”

Cross-site scripting has been on the well-known web application security census OWASP Top-10 for many years. With the introduction of CSP to TYPO3, we aim to tackle security vulnerabilities that often occur due to the lack of proper encoding of user-submitted content.

TYPO3 developers and integrators now have the option to provide policies that instruct browsers on how to deal with certain resources. For example, a policy transmitted as an additional HTTP header to the client could instruct which externally hosted JavaScript or CSS files are legitimate. Malicious resources that an attacker possibly managed to inject into the system will be blocked, because they don’t match the CSP.

A new backend module Admin Tools ➜ Content Security Policy is still under development and is planned for TYPO3 v12 LTS. The user interface will, for example, provide an overview of CSP violations.

In addition to the optional Content Security Policies outlined above, the TYPO3 backend now also sends the following common HTTP security headers by default:

• Strict-Transport-Security: max-age=31536000
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin

You can customize the default security headers by adding, overwriting, or removing entries in the global configuration to meet your individual requirements:

These security headers come in addition to the “X-Frame-Options: SAMEORIGIN” header that TYPO3 has already sent when requests to the backend have been made.

Although the CSP and the default security headers don’t fix vulnerabilities in extensions, they add another layer to harden the security of the CMS and its users.

The backend module Filelist ➜ Files has received quite a number of exciting improvements in the course of the last few sprint releases. For example, the tile view in TYPO3 version 12.1, that features larger thumbnail images and fewer details for a better overview of the assets in a folder. The expansion of the drag and drop function that now even works between the content area and the file/folder tree is another great enhancement. And, of course, the new process to create folders through an intuitive modal window.

To have an even more unified experience across the TYPO3 backend as a whole, we extended the usage of the file list to the element browser. This is the built-in component where editors connect a content element with assets from the file/folder list.

Backend users who prefer the traditional list view of assets can easily toggle between both visual modes. To complete the user experience, the search function within the file browser now respects the currently selected folder and takes the subfolders into account.

When backend users delete records such as content elements or pages, TYPO3 marks these records as deleted but does not immediately remove the data from the database. This function lets users and administrators restore deleted records, for example, with the backend module Web ➜ Recycler. However, you don’t want to store deleted records in the database forever. The system extension “TYPO3 CMS Lowlevel” and its CLI command “cleanup:deletedrecords” has served well in these situations.

In TYPO3 12.3, we added a new option “--min-age” to the function that lets administrators define a minimum age. With this option, the command only deletes entries marked as deleted at least x days ago.

This sounds like a small change but the business impact can be huge. With this option added, you can now execute the clean-up process as often as you want and meet data retention policies at the same time.

As the development of TYPO3 continues, so does the programming framework “Extbase”. The following two crucial changes affect TYPO3 developers.

For years, so-called magic functions let developers use function calls to retrieve data from repository classes. The special feature of these functions is that their methods are determined at runtime. If you want to, for example, look-up a user record by its first name, you can call the repository function findByFirstname(). If you don’t implement a method with this name, Extbase automatically determines the required functionality. The repository class derives the property name $firstname from the given term after findBy. As you can use arbitrary names such as findByLastname(), findByLocation(), findByVersion(), etc., these magic methods are convenient and save development time.

However, these magic methods also come with significant drawbacks. Most developers use an integrated development environment (IDE) for their programming work today. These IDEs can’t resolve the names of magic methods and falsely warn users about invalid code. Further issues are type declarations which are not possible, and static code analysis, which fail to analyze magic methods adequately.

Therefore, we introduced a new set of methods in TYPO3 version 12.3. The following functions provide the same functionality as magic methods, tackle the issues listed above, and coexist with the old methods for the time being:

• findBy(array $criteria, ...)
• findOneBy(array $criteria, ...)
• count(array $criteria, ...)

In addition, the new methods allow for multiple comparisons (called “constraints”), and their names follow the naming convention of the object-relational mapper Doctrine ORM.

We understand that magic methods are widely used in many TYPO3 extensions based on Extbase. Therefore, we marked the old methods as deprecated in TYPO3 v12 but will retain them in v12 and v13. This exceptionally long deprecation period gives developers sufficient time to migrate their code to the new methods.

The changelog entry provides further details about the migration steps.

The second significant Extbase improvement relates to the Reflection-API. Many modern PHP frameworks like Extbase analyze the program code, search for specific keywords, and generate new code that implements additional functionality. Code annotations in doc blocks are a typical example of a reflection, data types of properties are another.

Since PHP version 8.0, you can declare multiple types of properties, arguments, and return types (for example: “string|int”). These declarations are called union types and can replace any @var, @param, and @return declaration in PHPDoc comments.

Since TYPO3 version 12.3, Extbase now detects and supports union type declarations for entity properties. The relevant changelog outlines some further facts related to property mapping.

The TYPO3 Core Team devoted a lot of energy and did a major rework of the TypoScript and Page TSconfig functions. The outcome is a new TypoScript syntax parser that is astonishingly fast, more robust, and more logical. The tradeoff, however, is that a few syntax changes may break your TYPO3 site when you update to v12. Don’t worry, most sites will continue to work as they are, and we thoroughly documented the migration steps for the edge cases in the changelog. We are certain that TYPO3 installations will benefit from the substantial improvements.

You possibly already spotted some backend UI changes in previous v12 sprint releases in this regard. Everything TypoScript-related for the frontend is now located in the module Site Management ➜ TypoScript (previously: Web ➜ Template). Integrators should definitely take a look at this module and get familiar with its submodules. For example:

• Edit TypoScript Record (previously known as “Info / Modify”)
• Active TypoScript (previously known as the “TypoScript Object Browser”)
• Included TypoScript (previously known as the “Template Analyzer”)

The second new module in this area is Site Management ➜ Page TSconfig. (previously: Web ➜ Info ➜ Page TsConfig).

The new location of the Page TSconfig module and its new look and feel, streamlined with the TypoScript module, helps integrators and site administrators to manage, review, and debug the backend UI and its behavior.

The release date of TYPO3 version 12.3 marks the feature freeze for the v12 cycle. From now, no new features are planned until the LTS release in April 2023. This means that from now to the final LTS release, the Core team and contributors are focused on testing, polishing, and refining the source code and user interface. Some exceptions allow us to complete or improve the new features we added recently.

Extension developers are now advised to review the changes and improvements we made in all TYPO3 v12 sprint releases.

TYPO3 version 12.3 marks the last release before TYPO3 v12 LTS (long-term support) in April 2023. Now is a perfect time for extension developers to review and test their extensions and update the code base to support TYPO3 v12.

The more extensions that are compatible with TYPO3 v12, the more likely the LTS-release will be accepted and installed by the community. You can help to maximize the adoption rate of the upcoming TYPO3 v12 LTS release by publishing a compatible extension before the release.

Many TYPO3 integrators are excited to learn more about the new release and its benefits. You can leverage the improvements and update your existing TYPO3 sites to v12.

The system requirements for TYPO3 version 12.3 remain the same as outlined in the article “Get Ready for TYPO3 v12”. This includes PHP version 8.1, for example. Our support and maintenance promise also remains the same. Read more about the requirements and dependencies on get.typo3.org.

You will find all the details about the release and how to download and install TYPO3 at get.typo3.org. Detailed installation instructions are documented in the Installation Guide. We recommend using Composer to set up your TYPO3 environment.

The release of TYPO3 version 12.4—the long-term support release TYPO3 v12 LTS—is scheduled in about four weeks, on 25 April 2023. Despite the feature freeze state of TYPO3, we are still working on a few tasks to complete planned features. For example, the backend module to review configured CSP rules and violations.

Keep an eye on release party announcements and similar events. There will likely be online events, demos, talks, and parties (virtual and in real life).