[go: up one dir, main page]

TYPO3 v9 LTS Release Notes

Site Handling

Introduced in version 9.2

The most notable new feature in TYPO3 version 9.2 is the Site Handling functionality. Already introduced in version 9.1, the Site Management module in the backend of TYPO3 now contains a new sub-module “Configuration”. This enables integrators and site administrators to add and modify a global configuration for one or multiple sites.

A site configuration has a unique (human-readable) identifier and configuration values such as the root page ID, the base path (entry point), language definitions, etc. By storing the settings in a YAML file under “typo3conf/sites/site-identifier/”, it is easy to maintain the configuration in a version control system such as Git for example.

The Site Handling functionality already supports configurations such as domains, languages, error-handling and will be extended further until the the v9 LTS release later this year.

Documentation

>
>
>
>

Debugging and Profiling

Introduced in version 9.2

The well-known “TYPO3 Admin Panel” provides a deeper insight into the internal processes of TYPO3 at run-time. Once activated, TYPO3 integrators and site administrators can access performance and cache statistics, settings of a specific page, etc. They can also simulate certain frontend access situations. It is for example possible to impersonate a specific user group or simulate a timestamp, which may have an impact what is shown in the frontend.

Do not worry - we have not removed this awesome feature from TYPO3, but the Admin Panel will receive a major overhaul to be state-of-the-art again. As the first step, it was moved from the core into a dedicated system extension, which allows integrators to activate and deactivate the feature easily as required. This step also builds the foundation for further improvements such as a modern re-design and more new functions. Better profiling capabilities and the option to add custom functions via an API are just two enhancements on our list.

Do not be shy and get involved if you have a great idea or if you want to contribute in any way to support this initiative.

Please note that the (new) Admin Panel needs to be activated in the Extension Manager once you have updated an existing TYPO3 instance to version 9.2.

Another new feature that TYPO3 integrators and developers alike will embrace is the fact that values of fields are displayed in the backend. The labels of dropdown box items often do not clearly represent the values that get written into the database. A good example are CSS class names: when editors can choose from a list of options in a dropdown box, the labels could be “Ruler Before” or “Indent, 33%/66%”. These are not the values that get stored in the database of course, but “ruler-before” or “indent-left” are.

If the backend debug mode is enabled ([BE][debug] = 1), the real values of fields are displayed in square brackets to backend users with administrator privileges. This enhances the recently introduced feature of showing field names even further.

Documentation

>

Built for the Future

Introduced in version 9.2

If the improvements and new features described above are not exciting and technical enough, you are probably a hard-core PHP developer!

TYPO3’s reputation of being a dinosaur on the CMS market does not mean, the code base can not feature contemporary technologies and adopt modern software paradigms. Earlier this year, the PSR-15 middleware specification was officially released. The PSR-15 standard is defined as follows:

“[PSR-15] describes common interfaces for HTTP server request handlers (request handlers) and HTTP server middleware components (middleware) that use HTTP messages [...]. HTTP request handlers are a fundamental part of any web application. Server side code receives a request message, processes it, and produces a response message. HTTP middleware is a way to move common request and response processing away from the application layer.”

TYPO3 aims to support PSR-15 middlewares out-of-the box. This approach will improve interoperability with independent libraries and all requests in the TYPO3 core will return a PSR-7 response. As one of the first enterprise content management systems on the market, TYPO3 version 9.2 introduces PSR-15 middlewares in the frontend, as well as in the backend.

TYPO3 v9 LTS (scheduled release date in November 2018) aims to avoid constants and global variables if possible. Therefore, a new class “Environment” was developed, which acts as a central place for storing properties commonly used throughout the core. This class also contains methods that are relevant for all kind of PHP, CLI and web requests.

Documentation

Mail Queue

Introduced in version 9.2

The SwiftMailer project provides a sophisticated PHP library, that is the de-facto standard for creating and sending RFC compliant emails in PHP with a multitude of features. SwiftMailer has been integrated in TYPO3 since version 4.5.

With TYPO3 version 9.2, it is now possible to leverage SwiftMailer’s queue functionality - also known as “spool transport”. In most cases, developers want to send out emails immediately, but under certain circumstances, “spooling” emails and processing them later is beneficial, e.g. for performance reasons. Therefore, we are happy to announce, that the Mail API of TYPO3 version 9.2 now supports SwiftMailer’s “SpoolTransport” functionality.

Mails can be queued in memory (and only sent, if the HTTP request did not cause an exception or error) or in files. If latter, the sending of spooled emails can be triggered by a command line call or by a scheduler task. In both cases, the number of emails to process can be limited, as well as the maximum time.

Documentation

Hardening the Security

Introduced in version 9.2

Security has always been one of TYPO3’s top priorities and as we know, hardening the security of a system is an ongoing process.

TYPO3 stores various files in the “var/” directory, which is typically located under “typo3temp/var/”. Some of these files are for example Install Tool session files, caching framework files, files related to locking or logging, Extension Manager data files or files generated by TYPO3’s import/export or core update functions. Despite the fact that a properly configured web server and TYPO3 instance prevents accessing any sensible files in the “var/” directory, it is obvious that these are non-public files, which should better be located outside the web root.

As part of the ongoing effort to enhance the security of TYPO3 even further, the path to the “var/” directory can now be configured as an environment variable TYPO3_PATH_APP. The following configuration directive can be used by the Apache web server for example:

SetEnv TYPO3_PATH_APP /var/www/example.com/

This would instruct TYPO3 to create and use directory “/var/www/example.com/var/” whereas the web root should be “/var/www/example.com/htdocs/”. If the environment variable is not set, non-composer installations of TYPO3 continue to use “typo3temp/var/” as the default. Composer-based installations benefit from this functionality directly, as data is stored within the project roots' folder under “var/”.

Documentation

Improvements for Editors

Introduced in version 9.2

TYPO3 would not be so successful as it is today, if we only concentrated our efforts on improvements  for integrators, developers and administrators. Backend users, e.g. editors, have always been in our focus. Two notable new features in TYPO3 v9.2 especially for this target audience prove this again.

A content element on a page can often be used as a template for other, very similar elements. This could be a text/image for example, where most of the individual settings, e.g. the headline, visual appearance, access restrictions, etc. should be exactly the same or only need minor adjustments. In these cases, it makes sense to clone the existing element, which has been possible already by using “WEB → List” and copy/paste functions. However, this process requires a number of steps and clicks.

A new button “Duplicate” has been added, which appears when adding or editing a content element in the backend. With one click, backend users can clone a content element, which simplifies the process significantly.

The second improvement directly impacts the backend user interface (UI) and affects editors, as well as developers and designers alike. A set of so-called “toggle switches” have been introduced in TYPO3 version 9.2, which do not only look nice, but are also a useful tool to allow backend users to switch between two states easily.

The render types “checkboxToggle” and “checkboxLabeledToggle” can now be used for the checkboxes. On top of that, checkboxes are now displayed with icons provided by the IconFactory.

Documentation

>
>

Backend Main Module "Site Management"

Introduced in version 9.1

The new main module "Site Management"completes the existing modules "Web", "File", "Admin Tools" and "System" and aims to become the central place for all site-related configuration tasks, e.g. languages, domains and routing.

The first sub-module of "Site Management" is the new "Redirects" Module.

Documentation

>

Redirects Module

Introduced in version 9.1

There are several methods how a request to a web server or the web application is processed. The first request to a resource does not always result in a HTML page for example. Redirecting the user to a specific different resource (e.g. a file or page) is not unusual.

A new backend module named "Redirects" has been introduced in TYPO3 version 9.1. As the name suggests, it allows TYPO3 integrators and editors to configure redirects for their website. The redirects can be limited to a specific domain and the HTTP response code can easily be configured. On top of that, the source path can be enabled to be represented as a regular expression and a redirect to HTTPS can be enforced if required.

Redirects are an important part of every SEO strategy and often used for marketing campaigns to implement a short, meaningful URL, which possibly does not match the page structure in TYPO3.

This new module makes the old redirect feature obsolete and therefore, the option to configure a redirect, when a domain was added to a specific page or page branch, has been removed.

Documentation

>

Show Field Names in Debug Context

Introduced in version 9.1

TYPO3 integrators and developers often deal with input fields in the backend and need to know the corresponding name in the database. If the debug mode is enabled in TYPO3, the field name of every FormEngine field is shown to admin users in the backend now. This also makes the process of configuring access rights much easier, because the same field names appear when backend users or user groups are configured.

Documentation

Feature Toggles

Introduced in version 9.1

Another exciting new feature of TYPO3 version 9.1 comes in the form of a new API class "Features". This allows to check if a feature is enabled/disabled in a TYPO3 instance. The main benefit is, that new features can not only be developed in parallel to existing features and simply switched on and off, but also to have admins switch to new features explicitly or disable legacy programmatically.

Documentation

System Maintenance Area

Introduced in version 9.0

The well-known “Install Tool” represents an important component in every TYPO3 instance. Every integrator and developer knows, that it provides much more than some functions to install TYPO3. It is also used to configure TYPO3, run system and environment checks, test the setup and even update the instance to a new core version with a click of a button. 

Therefore, “Install Tool” is not the right terminology and the component deserves a new name as a logical consequence: System Maintenance Area. 

Besides an improved look and feel, which integrates the System Maintenance Area smoothly into the backend of TYPO3, it is split into four modules: “Maintenance”, “Settings”, “Upgrade” and “Environment”. Some long-term users of TYPO3 might find this a little bit unfamiliar at first, but the benefits are obvious and make perfect sense. The constantly growing number of features provided by the module require a clear, logical and distinct separation into these categories. As a result, users will find the desired functions more quickly. 

As a matter of fact, everything that impacts TYPO3’s global settings (also known as the system-wide configuration and stored in the “LocalConfiguration.php” file) belongs to the System Maintenance Area. It is not surprising that the configuration of extensions have been moved from the Extension Manager to this module, too. 

No further explanation is needed to understand that only selected users should access the System Maintenance Area. For this group of experts, we have introduced a new role called System Maintainers. Backend users with administrator privileges can be promoted to have this role. As a consequence, they can access the System Maintenance Area directly from the backend without providing a password. Everyone else requires access credentials (the previously known “Install Tool password”).

Documentation

Extension Scanner

Introduced in version 9.0

One of the challenges in every major TYPO3 upgrade (for example from v8 to v9) is the fact that the new version may contain breaking changes. Some competitive content management systems simply do not officially support an upgrade, but suggest to re-build the website from scratch using the new major version. 

TYPO3 has a reputation of being upgradable, even across major versions. This was not always straightforward, but has been improved significantly and often heavily depends on third-party extensions. 

The new extension scanner, which is already part of the System Maintenance Area in TYPO3 v9, provides a detailed overview of what needs to be done to accomplish a successful migration to the next version of TYPO3. If extensions use deprecated API calls, the extension scanner suggests documentation on how to migrate this specific piece of code. 

We understand how important an upgrade from one major version to the next is. This process should be as simple as possible with a minimum of effort (in particular from one LTS to the latest LTS release) and we will continue to work hard to pave the way.

Documentation

Unassigned Content Elements

Introduced in version 9.0

Content elements, which are not assigned to any column are shown in an additional column named “Unused” at the end of the page. This makes sure, that these elements do not get lost when switching from one backend layout to another with different columns. 

Even if the layout is switched back to the original one, the elements nicely fall back into their original position.

>

New Page Tree

Introduced in version 9.0

Performance optimization and the leverage of modern web technologies has always been on our agenda. We are proud to present a re-worked page tree in the backend of TYPO3 v9, which is based on SVGs and features superfast rendering times.

The new page tree enables us to finally remove ExtJS from TYPO3 completely. A goal we aimed for, for a very long time - no ExtJS in the TYPO3 backend anymore!

Documentation

>

Creating New Content Elements

Introduced in version 9.0

Editor and integrators will experience that modal boxes will appear more often in the backend of TYPO3. A first step in this direction has been made by moving the wizard for the creation of new content elements into such a box. This helps users not to loose the focus of the context where new content is created.

Further implementation of this concept will follow in subsequent releases of TYPO3 v9.

Documentation

>

Translated Pages

Introduced in version 9.0

When it comes to language handling, one of the biggest obstacles in TYPO3 was the way page translations were handled. This has been improved in TYPO3 v9 by having page translations handled the same way as other records.

From a technical point of view, this means, the database table “pages_language_overlay” became irrelevant and is not required anymore, as all data is stored in the main “pages” table.

Documentation

Logging

Introduced in version 9.0

Developers know how important logging is and that a common interface can be crucial to track errors, record important events and debug problems. The PSR-3 standard describes a logger interface for PHP applications, which is used by all logging procedures throughout the TYPO3 system now. At the same point, logging record changes are properly stored in TYPO3’s history database, but the logging is separated now. Thus, all logging of TYPO3 runs through the PSR-3 standard we had in place since TYPO3 6.2, but is now 100% in use.

Documentation

Re-Designed View Module

Introduced in version 9.0

Websites are accessed using a wide range of devices and screen sizes today. The need for editors to check the appearance of a page is obvious and the view module allows backend users to do exactly this. 

The view module received a modern and streamlined look and feel in TYPO3 v9. The introduction of named and categorized device presets makes it even easier for editors to view a page and to get a better idea of what the page looks like on a specific device. Even the device orientation can be changed without selecting a di

Documentation

>

Composer Improvements

Introduced in version 9.0

If you are running TYPO3 via composer, we have good news for you. Over the last months, we achieved some huge improvements. You can now install only the packages you actually use and all TYPO3 system extensions are available separately on packagist. The benefits are clear: only extensions you really need are installed on the server. 

Installing TYPO3 via “composer require typo3/cms” is not possible and not required anymore. Each system extension can be selected individually and can be required separately via “composer require typo3/cms-core” or “composer require typo3/cms-workspaces” if actually needed in a project. 

We also reduced the number of system extensions from 52 to 44 by merging certain concepts into one package (such as EXT:version and EXT:workspaces).

Documentation