Skip to content

My highlights in TYPO3 v10

TYPO3 has improved a lot with the last versions. Version 9 was a real milestone in my view, especially with the routing feature.
As today is the release of TYPO3 v10 LTS, I would like to present some personal highlights for integrators.

I recommend that you read the well-written What's New Slides of the individual TYPO3 v10 Sprint Releases as well. You can find further details about a change in the Changelog (and soon in the TYPO3 documentation).

The new dashboard

Those of you who follow the development around TYPO3 will already have noticed that version 10 introduces a new backend module: The dashboard can provide important information about your TYPO3 installation. You can create several dashboards for each user, with individual widgets.

Several default widgets exist in the TYPO3 core. And every third-party extension can provide its own widgets.

So a start has been made. But the number of widgets still needs to be increased to create real added value. The dashboard definitely has a lot of potential.

An example of a helpful widget would be an overview of pages whose contents have not been edited for a long time. An editor could use it to keep his/her pages more up-to-date.

In the coming months, many intrigued developers will publish their custom widgets in the TER. Let's hope that there will be more than just weather widgets. :)

The TYPO3 Form Framework

A lot has happened in EXT:form. I will only mention a selection of changes here – please pay special attention to the changes marked as Breaking in the TYPO3 Changelog!

One of these breaking changes is the renamed option translationFile. From now on, it is spelled translationFiles (plural). Why's that? Until now, you had to change this option to the YAML array notation yourself in order to add custom XLF translation files. Now, this notation is the new default and the included language files have an array index of 10.

I have updated my extensions form_examples and form_distribution accordingly. There's a compatible branch for each TYPO3 version (they are linked e.g. in the README file).

Configure multiple e-mail recipients

A functionality often asked for by integrators: you can now store multiple recipients in both e-mail finishers.

Migration is necessary for existing form definitions. This migration can be performed automatically if you open and save the form in the backend module. You can find examples of the new spelling in the changelog.

Overview of parsed YAML configuration

While TYPO3 provides the TypoScript Object Browser to inspect the applied TypoScript setup, nothing comparable existed for YAML configurations.

You can now open SYSTEM>Configuration to find the new submodule 'Form: YAML Configuration'. It allows you to check if your form configuration is properly loaded and applied.

Access single form values in templates

Until now, it was not possible to render a single value directly in form templates. You had to traverse through all values and use conditions to render a specific identifier, which was cumbersome. This could have looked like this in the SummaryPage.html:

<!-- previous rendering of individual form values -->
<table class="table">
    <formvh:renderAllFormValues renderable="{page.rootForm}" as="formValue">
        <tr>
            <f:if condition="{formValue.value}">
                <f:then>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'name'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'subject'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'email'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                    <f:if condition="{0: formValue.element.identifier} == {0: 'message'}">
                        <td>{formvh:translateElementProperty(element: formValue.element, property: 'label')}</td>
                        <td>{formValue.processedValue}</td>
                    </f:if>
                </f:then>
                <f:else>
                    -
                </f:else>
            </f:if>
        </tr>
    </formvh:renderAllFormValues>
</table>

In TYPO3 v10, a new viewhelper <formvh:renderFormValue> for single form values has been added. An example from the Changelog entry:

<p>The following message was just sent by <b><formvh:renderFormValue renderable="{page.rootForm.elements.name}" as="formValue">{formValue.processedValue}</formvh:renderFormValue><b>:</p>

<blockquote>
   <formvh:renderFormValue renderable="{page.rootForm.elements.message}" as="formValue">
      {formValue.processedValue}
   </formvh:renderFormValue>
</blockquote>

Furthermore, you can now debug the available form elements in the template. This will render them as an array:

<f:debug>{page.rootForm.elements}</f:debug>

Restructuring of the YAML setup

When the new Form Framework was introduced, it probably wasn't just me: the YAML configuration took getting used to. Form definition, form configuration, form manager, form editor - the whole terminology had to be learned first. Also, I found the three YAML files in EXT:form (BaseSetup.yaml, FormEditorSetup.yaml and FormEngineSetup.yaml) quite confusing. Inheritances and mixins were not beneficial for readability.

In the new TYPO3 version, the YAML configuration has been completely reworked:

This new structure seems much more understandable at first glance. I am curious how this will affect the daily work with the Form Framework.

The Site Management

The Site Management which was implemented in TYPO3 v9 has been further extended. Among other things, a config.yaml with a default configuration is now automatically created for each page where you activate the is_siteroot property.

The Website title (sitetitle), which could previously be defined in the TypoScript template, can now also be set in the page configuration. You can even set individual titles per frontend language!

Routing improvements (speaking URLs)

If you change URL segments in pages afterward, this was not applied to subpages in TYPO3 v9 – they kept the old path. This was meant to prevent that many pages are suddenly no longer available under their former URL and users get a Page not found message.

In TYPO3 v10, the behaviour was improved: now the URL segments of all subpages are updated as well. At the same time, redirects for all these pages are created in the Redirects backend module. The editor will receive a notification with this information afterward. It allows him/her to revert these changes, if necessary.

You can configure this new behaviour in your Site Configuration (example in the Changelog).

The Frontend Login plugin (felogin)

The core extension for the frontend login was built with the old PiBase library up to TYPO3 v9. Accordingly, the frontend template still used the outdated, marker-based templating.

With TYPO3 v10, EXT:felogin is finally implemented with Extbase. Existing TYPO3 installations can continue to use the old PiBase version, as this plugin is still included in the extension. For new installations, the new feature toggle is activated to use the Extbase version.

I maintain several websites with a frontend login and sincerely am looking forward to building login templates with Fluid.

The new AssetCollector

A new, very interesting concept was introduced in TYPO3 v10: the AssetCollector. It allows you to add JavaScript and CSS in Fluid templates (or in PHP). This can be helpful if you need additional code for certain content elements that you don't want to include on all subpages.

When rendering the page, the AssetCollector will render identical assets only once. You must set the identifier attribute in the viewhelper for this purpose.

You can include both inline code or external files:

<f:asset.css identifier="specialElement" href="EXT:sitepackage/Resources/Public/Css/special-element.css" />

<f:asset.css identifier="specialWrapper">
   .wrapper--modifier { max-width: 1200px; }
</f:asset.css>

<f:asset.script identifier="specialElement" src="EXT:sitepackage/Resources/Public/JavaScript/special-element.js" />

<f:asset.script identifier="annoyingAlert">
   alert('Hello!!!11');
</f:asset.script>

You can also control where the asset should be rendered: if you set the optional attribute priority, the Asset is set in the <head>. Otherwise, it will be added in the <body>.

Small improvements

  • The Extension Manager again provides a shortcut to the respective documentation.
  • In the context menu of the page tree, you can now toggle the 'Hide in menu' property (can be found in 'More options…').
  • The TypoScript condition PIDupinRootline was previously missing within the Symfony expression language. It is now available in TYPO3 v10 (example in the Changelog).
  • TYPO3 now supports browser-native Lazy Loading of images. It is activated by default in fluid_styled_content. You can configure the value of this new image attribute with TypoScript.
Back to news list