TYPO3 v9 Roadmap

Between the TYPO3 v8 LTS release in April 2017 and the first sprint release of v9.0 in December 2017, the TYPO3 Core Team reviewed the main achievements of v8.7 (the latest LTS release).

It became clear that many developers, integrators and editors have embraced the new Form Framework, the mobile-ready backend UI and the integration of the new Rich Text Editor “CKeditor”. Under the hood, TYPO3 v8 LTS now features a robust database abstraction layer by using Doctrine DBAL and cleaner localization. In addition we successfully managed to implement a simpler way of handling backend editing forms and command line functionality.

We also spent time on composer-based installations and streamlining our internal release and security processes over the last few months. The result is an even better and fail-safe release procedure for upcoming versions of TYPO3.

Upgrading projects from TYPO3 v7 to v8 is already much easier than an upgrade of older versions, but our aim is to improve this process even further. An upgrade to the latest LTS version should always be as simple as possible with a minimum of effort. TYPO3 developers have already created some nice features and useful extensions to detect and report if specific actions are required. The new extension scanner, which is already part of the new system maintenance area (formerly known as Install Tool) in TYPO3 v9, provides a detailed overview what needs to be done to accomplish a successful migration to the next version of TYPO3.

We understand that TYPO3 still lacks functionality to support web developers to launch new websites with ease in a modern way. Two features worth mentioning are frontend editing and speaking URLs out-of-the-box. Both should be TYPO3 core features, rather than added by extensions.

The TYPO3 backend should also focus more on the target audience, namely editors, integrators and site administrators. On one hand it‘s beneficial to keep elements positioned where they have been for the last decade in order to make it easy for users to work with new versions. On the other hand, web technologies are continuously evolving and modern concepts often improve usability. We aim to continue balancing these two conflicting needs in TYPO3 v9.

These facts are convincing enough to set a high priority on making life easier for integrators and site administrators. No matter if the installation they are responsible for is small or big.

That’s why a focus for TYPO3 v9 is making the upgrade process easy and straightforward and to simplify the processes to set up new sites and maintain existing installations.

Let’s discuss these points in a little bit more detail.

The current “Frontend Editing” extension (extension key “frontend_editing”) by the Swedish TYPO3 agency Pixelant has been very successful. Unfortunately, this extension did not make it into the core of TYPO3 v8 LTS. But the decision to improve it even further so it can be included in TYPO3 v9 pays off. The extension (freely available from the TYPO3 Extension Repository) can already be used in production environments and users are encouraged to share their feedback on the active Github repository or on Twitter.

Missing features at this point are a native image handling functionality and proper page creation / metadata handling. This would allow editors to make quick TYPO3 changes without accessing the TYPO3 Backend anymore.

Integrating the “Frontend Editing” extension into the TYPO3 core would also mean that we will get rid of the old “fe_edit” functionality completely. By moving the latter into a legacy state, it will remain available for TYPO3 v8 and below.

Extensions like RealURL, CoolURI and SimulateStatic have served us well for many years. They will likely continue to work in TYPO3 v9. However, they all share the same conceptual issues:

• They resolve the URL during a frontend request and have to deal with generating URLs for backend and CLI context with hacks.
• They map URLs to GET variables (most notably the internal “?id=123” parameter) and vice-versa, instead of natively dealing with domains and URL paths attached to a certain page.
• A defined URL cannot be distinctively mapped to a page in a deterministic way, as URLs are generated on-the-fly and based on certain contexts.
• Configuration is tedious (and on top of a regular site configuration).

Since all language configuration is done in TypoScript, this leads to a lot of dependencies of TypoScript for URL resolving. In its basic variant, a speaking URL should be mapped to a single page and additional query parameters/URL paths can be mapped to other logic.

These are the main reasons we kept the current state as it is, but did a lot of groundwork in the last TYPO3 release to be able to finally tackle this topic in TYPO3 v9.

In addition, speaking URLs natively in TYPO3 will also be the foundation to handle RESTful web services (Representational State Transfer) in the future.

The concept of page overlays is also still a significant show stopper to handle speaking URLs in TYPO3 properly. However, removing this is not only a major task, but also a breaking change. With several significant improvements for language handling introduced in TYPO3 v8, the final step to simplify translations is to migrate “pages_language_overlay” into “pages” itself. This is the main reason why the release of the first v9 version took longer than expected. We have finished this important task for TYPO3 v9.0 including a smooth upgrade path.

This change allows for further exciting developments in TYPO3. Performance improvement is only one of them. Simplification of code in various places and new functionalities such as showing translations in the page tree are other possible options.

TYPO3 -- as an enterprise open-source content management system -- can handle multiple sites within one installation. This has been possible for a long time and this feature makes TYPO3 versatile and outstanding from many of its competitors.

In TYPO3 v9 we plan to thoroughly review this area and aim to streamline the resolution of the entry points of a website. The definition of a “site” is on our agenda and the handling of sites as a base for multi-site projects will be updated. This may include extending the logic of “sys_domain”, “sys_language” etc. for frontend entry points for example.

As pointed out before, the last TYPO3 release lies well in the past. In order to keep the most notable breaking changes in a “dot-zero” release, we have scheduled the release of v9.0 to the end of the year 2017. Although we are not precisely following semantic versioning in TYPO3, we aim to keep breaking changes to a minimum for all following 9.x versions.

The most significant changes we already achieved to date are the page translation handling (“pages_language_overlay”) and the elimination of ExtJS. In addition, the deprecated “css_styled_content” functionality and TYPO3_DB have been removed (you can still use the latter by installing “database compatibility layer” from the TER), plus a few more.

The first releases of TYPO3 v9 will have the same system requirements as TYPO3 v8 LTS, except for the PHP version, this is due to conflicts in our PHP dependencies, see the current decision. However, we want to ensure that an upgrade is as simple and smooth as possible.

Due to the fact that it is still a long way to the LTS version of v9 (October 2018), we cannot guarantee that this will not change. Please keep an eye on the release notes for each release, before you plan an update.

The table above shows that releases are planned on Tuesdays as a general rule. The feature freeze for sprint releases is one week before the estimated release (9.0 being an exception). Releases will not be postponed due to missing features.

TYPO3 has a reputation of being a stable and robust enterprise content management system. This has been and will always be one of our highest priorities. Therefore, it should be noted that features and details described in this article are accurate and up-to-date as of the date of writing, but may change or may be adjusted as required.