You too can become a hero and support this Blog at GitHub Sponsors or Patreon.

More about support

TYPO3 v11 LTS is full of great features. I did already cover changes regarding extbase in the post "Extbase in TYPO3 v10 and v11". Now it is time to look at improvements in other parts of TYPO3. Small things, that are not enough to fill a whole article but still so convenient, that they deserve to be mentioned. Little treats here and there.

One notable exception will be the TCA, that is likely to receive its own post.

That being said, I got the feeling that this list is already pretty long without extbase and the TCA, so let's jump right into it.

PHP 8

TYPO3 v11 supports PHP 8 (patch, Feature RST)! That means we can use all the shiny features that come with the new major PHP version. There are plenty of web resources of what is most shiny, so I am not going to repeat all this here, but provide some links to very good blog posts about the most interesting features:

It might take a while until all 3rd party extensions will also run on PHP 8. For new projects or major updates it will be absolutely worth it to evaluate the effort to make all extension code PHP 8 compatible. Watch out for specific rectors that can help you achieve this!

Alright, let's turn to more TYPO3 specific things.

Top

Flexform Data Processor

Sometimes we just can't get around using a flexform. For those cases the core now provides a data processor that converts the XML structure into an array. It will use pi_flexform as the default database field to convert, as the table tt_content is the most common use case, and we usually put the flexform structure of plugins or content elements into the field pi_flexform.

As all data processors we can use it in our FLUIDTEMPLATE TypoScript objects:

10 = FLUIDTENPLATE
10 {
  dataProcessing {
    10 = TYPO3\CMS\Frontend\DataProcessing\FlexFormProcessor
    10 {
        fieldName = custom_flexform_field
        as = customData
    }
  }
}

If we do not specify a variable name with as, the default variable name will be flexformData.

The data processor was added with this patch (Feature RST).

Top

Namespace Imports in ext_localconf.php files

We have all done it by accident. But with TYPO3 v11 it is finally valid, legal and explicitly supported to import PHP namespaces in the extension configuration files ext_localconf.php and ext_tables.php!

While the latter has only a few leftover use cases, the former is needed for lots of things, for example to register plugins. From now on such a registration can look like this:

<?php

use Vendor\MyExtension\Controller\DummyController;
use TYPO3\CMS\Extbase\Utility\ExtensionUtility;

defined('TYPO3') or die();

ExtensionUtility::configurePlugin(
    'dummy_plugin',
    'dummy',
    [DummyController::class => 'index,foo']
);

Since the core collects and concatenates all ext_localconf.php and ext_tables.php files, each file's content had to be wrapped in the global PHP namespace with namespace { }.

And that's it, that's the patch (Important.rst).

Despite this being a cool improvement, icon registration does not profit from it, because it vanishes from ext_localconf.php. Let's look at this next.

Top

Icon registration during Build Time

Extensions no longer need to register icons in their ext_localconf.php files. Instead a dedicated icon registration file can be created at Configuration/Icons.php.

Here is how the icon registration structure looks in the new file:

<?php
return [
    'iconIdentifier1' => [
        'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider::class,
        'source' => 'EXT:my_ext/Resources/Public/Icons/my-icon-1.svg'
    ],
    'iconIdentifier2' => [
        'provider' => \TYPO3\CMS\Core\Imaging\IconProvider\BitmapIconProvider::class,
        'source' => 'EXT:my_extension/Resources/Public/Icons/my-icon-1.png'
    ],
];

The new icon registration files are picked up by a service provider during system build time. This means they can be cached more efficiently which should lead to an overall performance gain. Additionally, the ext_localconf.php files are less cluttered, which improves the maintainability. Overall a very nice change.

As usual, we can have a look at the corresponding patch and Feature RST.

The post TYPO3 Icon-API has also been updated.

Top

Auto-detection of PSR-14 Event Classes

A neat little improvement to PSR-14 event listener registration was added with this patch (Feature RST). We no longer need to specify the event class we are listening to when registering our listeners in the Services.yaml.

Given the following event listener:

namespace Vendor\MyExtension\Notification;

class VeryImportantListener
{
    public function __invoke(SomeEvent $event): void
    {
        $this->notifyVIPs($event)
    }
}

To register this listener we can omit the event part because it is fetched automatically by class reflection during container compilation time. This means the registration is down to:

Vendor\MyExtension\Notification\VeryImportantListener:
    tags:
      - name: event.listener

To find out more about PSR-14 events (and what this all means) head over to my (already updated) article PSR-14 Events in TYPO3.

Top

Collection of DTOs in Extbase

With this patch (Feature RST) the extbase property mapper was taught to handle collections of non-persistent objects. As long as we provide a setter method with proper annotations, the objects in the collection will be created now:

class CartData
{
    /** @var ObjectStorage<ItemData>  */
    protected ObjectStorage $items;

    /** @param ObjectStorage<ItemData> */
    public function setCollection(ObjectStorage $items): void
    {
        $this->items = $items;
    }
}

The usual use case would be collections of DTOs. You can read more about this in my updated post "DTOs in extbase".

Top

JSON View can resolve properties recursively

The JSON view can be used to render the JSON representation of an extbase domain object. For relations to other objects a manual configuration of each level was necessary. While this might not be the most common use case, it is now possible to tell the view to render a certain property recursively (patch, Feature RST):

$configuration = [
    'directories' => [
        '_descendAll' => [
            '_recursive' => ['directories']
        ],
    ]
];

Granted, it is a rather small thing, but nice to have for sure.

If you want to read more about the JSON view, head over to the article "Create APIs with the JSON view".

Top

As always, thanks for reading and supporting this blog! Also a big THANK YOU to all contributors who made the above improvements possible.

Stay tuned for an update about TCA related changes.

Cheers!