Developer Experience

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.



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.


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).


Integration of the Composer Autoloader

Introduced in version 7.1

One major area the contributors worked on was a new autoloader for PHP classes that TYPO3 uses on a request. The previous complex logic is still kept for backwards-compatibility but the power and performance improvement that comes with new Composer-based class loader made lots of things easier. The new class loader takes full power of extensions that ship a composer.json and define a PSR-4 class standard. Any TYPO3 installation that is set up with Composer already benefits from the new changes completely. Any other installation that is set up the classic way by extracting a .zip file or tarball archive will use the Composer class loader for the TYPO3 extensions that are required for a minimal running system. For all other classes the still existing TYPO3 class loader does all the work.


Dependency Injection (PSR-11)

Introduced in version 11.0

Developers should also observe the development of Extbase’s Dependency Injection (DI). We plan to deprecate and remove the current implementation in Extbase and use the feature offered by the TYPO3 Core instead. This solution is based on the PSR-11 standard and incorporates Symfony’s industry-proven DI concepts.


Session Handling

Introduced in version 11.0

As part of streamlining the authentication process I mentioned earlier, we reworked some components of the TYPO3 Core responsible for frontend and backend user authentication. In previous versions of TYPO3, the user session handling was part of the user authentication components of the TYPO3 Core. We reworked these in TYPO3 v11.0 and separated the user object, the authentication process, and the session handling.

We created a dedicated session handling API that offers core and extension developers centralized handling of sessions. The new UserSession object contains all session-related data. Developers should use the UserSessionManager to create new sessions.


Fluid Widgets API

Introduced in version 11.0

A particular type of ViewHelpers in Fluid is “widgets”.  Logically they are part of the view, but widgets have their own controller and view. Strictly speaking, the technology violates the design pattern “separation of concern” and causes problems using PSR-7 request objects in Extbase.

Therefore, we decided to drop Fluid ViewHelper widgets, and TYPO3 v11 does not support them anymore. A prominent use-case of a Fluid widget in the TYPO3 Core is the <f:paginate...> ViewHelper. We advise developers to review their extensions and to use the Pagination API instead.


Pagination API for Listing Items

Introduced in version 10.2

Comfortably browsing through lists of items is a common use-case for websites and web applications alike. The TYPO3 core makes it easy for developers to implement such a solution that is also highly flexible and customizable. The new Pagination API lets users browse any kind of data — from database records to arrays and QueryResults. Everything that is “iterable” can be paginated and the TYPO3 core will make use of this useful API even more in the near future.


New dependency injection

Introduced in version 10.0

The aforementioned goal to use robust and established standards and PHP packages throughout the TYPO3 core is also evident in another area of paramount importance: “dependency injection” (DI). This technique comes into play when one object supplies the dependencies of another object. PHP objects that do not contain state are called services and are logically encapsulated in service containers.

By applying Symfony’s Service Containers architecture we take dependency management and dependency injection for PHP classes to a new level. This approach aims to replace the Extbase dependency injection container and object manager which means we can do without both GeneralUtility::makeInstance() to retrieve singletons and static methods like getInstance() in the future.

Developers are encouraged to read the Symfony documentation and to keep an eye on the PSR-11 Initiative and its sub-tasks.