Upcoming Elections in the TYPO3 Association 2020
In 2020 we will have regular elections for Board and BCSS of the TYPO3 Association.
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”).
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.
It should be noted that the user interface of the new System Maintenance Area is still under development and will likely receive further optimization, before its perfection in TYPO3 v9 LTS.
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!
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.
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.
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.
Nobody can deny that editors are the primary users of the TYPO3 backend. Therefore, constant improvements of the user interface especially for this target audience is an important factor for the success of TYPO3.
Besides some small modifications to make the life of editors easier, two notable improvements are as follows.
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.
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 different device preset now.
The first version of a new TYPO3 version branch always comes with breaking changes. This allows us to introduce new technologies and groundbreaking features. 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.
Lessons learned from the v8 development and sprint releases (where we allowed for more than 130 breaking changes), we have better deprecations for all PHP functions in place and database changes between v9 sprint releases will come with convenient upgrade wizards.
These measures aim to pave the upgrade path for existing TYPO3 projects. Extensions developed and maintained by members of the terrific TYPO3 community should have less issues adapting to minor versions in the future.
If you are an extension developer, give it a try and let us know how easy it was to make your code TYPO3 v9 compatible (but be warned: there will be a few breaking changes until v9 LTS).
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).
Existing installations can be upgraded easily by using the upgrade wizards. Integrators find the appropriate functions in the new System Maintenance Area of TYPO3 v9.
If you're upgrading from a composer-based installation, you need to require each necessary system extension for your system separately now instead of "typo3/cms" - just use "composer require typo3/cms-core", "composer require typo3/cms-fluid-styled-content", "composer require typo3/cms-scheduler" etc.
Make sure, the underlying infrastructure meets the minimum requirements. The current PHP minimum requirement is PHP 7.2. This requirement might be lowered to PHP 7.1 or even PHP 7.0 for future sprint releases, as a final decision is still pending.
TYPO3 version 9.0 is just the first step of presumably five sprint releases on the road to the next long term support release TYPO3 v9 LTS.
We are working hard on proper URL routing for frontend requests and we also plan to introduce a new way of handling redirects by the TYPO3 core. If everything goes as planned, these two exciting features (and likely some more) will be ready in TYPO3 version 9.1 (January 2018).
Read more about our plans for the next months and TYPO3 v9 LTS release, which is scheduled for early October 2018, in the TYPO3 Roadmap.
In 2020 we will have regular elections for Board and BCSS of the TYPO3 Association.
TYPO3 v10.2 is out now — the last sprint release of the year. A lot of functionality was developed during the TYPO3 Initiative Week (T3INIT19) and...
Academic institutions are invited to set up their organization as part of a network of institutions that can verify TYPO3 skills according to the...