After a short welcome by Fabian Stein, the online event, which was held as a replacement for the unfortunately canceled TYPO3 Developer Days in Karlsruhe, got underway.

Mathias Schreiber was the first to report on all the new features in the new TYPO3 version 10.

With over 159 features (the reader may wonder why there weren't 160 at this point :-) ), this latest TYPO3 version brings many improvements. Among other things, you can now use the following:

• Resetting the backend password is now possible if you activate the corresponding option.
• TYPO3 Asset Collector: It is now possible to fine-tune how assets are handled - for example, if third party extensions want to reload data that is not needed in the project.
• HTML-based Templated E-Mails: E-Mails can now be created with Fluid.
• Developers can now look forward to even better support for the PSR-14 standard.
• For SEO support, the new TYPO3 comes with the simpler option of "redirects" and "slugs". This makes it much easier to assemble a URL from words and partial words to give search engines the food they need.
• The dashboard already presented elsewhere in this techsummer has been expanded with a few new tiles.

The presentation was marred by poor voice quality, so unfortunately it was not possible to follow the entire presentation. So the only thing left for me to say is to take a closer look at the new TYPO3 version and use it. It is worth it!

TYPO3 Metrics (Ekkehard Gümbel - bitmotion)

In his presentation, Ekkehard Gümbel shows data about TYPO3 and the community to give a picture of how TYPO3 is perceived and which figures help the community to further develop TYPO3. What trends are there in the market? Do you have to follow these trends? Which TYPO3 versions are still in use? These and more are questions that will be answered. Everything else at https://www.t3versions.com/.

The question of how "healthy" the TYPO3 community is can also be investigated. All these are important figures on the basis of which TYPO3 newcomers can think about whether it is really worth getting to grips with TYPO3.

For this purpose, the TYPO3 Metrics Initiative was founded to deal with the various topics of data collection around TYPO3. Ekkehard is still looking for volunteers who are familiar with some of the relevant areas and would like to support him in this project.

If you would like to participate, you can have a look and listen in the Slack channel #TYPO3-Metrics. Don't worry: this is not yet a binding commitment to participate.

TYPO3 Nerding TeaTime

In the afternoon, the presentations became interesting for TYPO3 developers and system administrators. It started with the topic:

Redis in Large TYPO3 Environments (Christoph Zimmermann - redislabs & Daniel Lienert - punkt.de)

After a short introduction, we went straight into the heart of the matter. In contrast to other databases, Redis is completely optimized for speed. This is also reflected in the fact that Redis keeps the database completely in RAM. It's been a long time since I've heard a presentation in which the speaker is concerned about CPU cycles and the database documentation contains the O() notation next to the commands, which indicates the time required to execute the respective command. This optimization in terms of performance is "bought" with the limited environment in which such a database can be used. Users are advised to read the Redis use case examples. As with everything that only takes place in RAM, it is worth ensuring that the values held in RAM are low during setup. Hashes are an idea here, which can be used to load the data to be displayed to users from a slower memory.

After an introduction to Redis, Christoph Zimmermann then presented the possibility of using Redis in a TYPO3 project. His benchmark configuration was a TYPO3 10.4.4, Apache 2.3, php 7.4.3 on a Dell XPS 13. Without black magic and optimization, a tripling of requests could be achieved on the test system with Redis. Of course, you have to check your own setup to see whether the speed gain has such a significant effect.

After Christoph Zimmermann presented Redis, it was then Daniel Lienert's turn to present a real-life example. In a system we developed, we had to implement a very complex and extensive authorization concept, which would not have been possible without Redis, as the response times were simply too long. Daniel used Gatling to simulate realistic user behavior in his benchmark.

As this is a really easy to install "drop-in" replacement, Daniel suggested to simply try Redis in TYPO3 projects. The users of your website in the frontend will thank you for the speed advantage.

Daily Business With a Living Styleguide (Simon Praetorius - sitegeist media solutions)

In the following, Simon Praetorius (sitegeist media solutions) reports on his experiences with the Living Styleguide used at sitegeist.

Everyone knows the problem that a style guide is agreed between the graphics agency and the client at the beginning of a project, but then changes during the course of the project. How do you record all these changes and document them so that everyone involved in the project knows what the current status of the layout is?

Well, it's actually quite simple:

You take: fluid-components (a TYPO3 extension) and then fluid-styleguide. With these two extensions, you can divide your layout into components and partials, which you can then access in the projects. Partials are the smallest unit that a layout can consist of. These partials can then be used in the components, which can be managed with "fluid-components".

Fluid-Styleguide then helps to display the components defined above as a "living" styleguide. The extension makes all individual components visible in one place. This has the advantage that the styleguide always matches what the developers use in the project, as technically the same data is used here.

This has many advantages: The designers can see how the layouts have been implemented and can quickly coordinate with the developers if the developers require a different implementation. For the developers, it has the advantage that the developed layout is always visible in one place. The style guide is also used by the developers to develop the corresponding components in order to think about individual components on a more abstract level. In this way, some components can be standardized, which simplifies development on the one hand and makes the layout in the frontend appear more uniform and coherent on the other. The advantage for the testers is that they can see all the components in one place and can therefore quickly assess whether all the agreed components have been implemented. For the project manager, the Living Styleguide has the advantage that he can see very quickly which components have already been implemented and styled. Last but not least, the customer can also see in one place which content is being used in the project.

A living style guide really picks up speed when it is used to achieve the shortest possible release cycles for the layout. Instead of the usual waterfall model, Dan Mall proposes the "hot potato" process, in which the individual pieces of content are passed from the designer to the developer as quickly as possible like a hot potato and the result is then approved by the customer.

In his presentation, Simon then showed in a live demo how easy it is to implement a new requirement for the customer from the Living Styleguide.

Making the TYPO3 Pagetree Accessible (Michael Telgkamp - mindscreen)

Michael Telgkamp's presentation was about how to make the TYPO3 pagetree more accessible.

Michael is a member of the TYPO3 "Accessibility Initiative" and is committed to making TYPO3 accessible to even more people.

In TYPO3 version 9, the entire TYPO3 pagetree was still a single SVG file that could only be navigated with the mouse. At that time, TYPO3 was not accessible at all.

Michael had the first ideas for making the pagetree accessible back in 2019. He presented his ideas at various TYPO3 events, which led to him being invited to the"TYPO3 Initiative Week". Soon the idea was born to implement the TYPO3 Pagetree with the W3C standards from the WAI-ARIA project.

The ideas presented there stipulate that all content must be directly accessible via the keyboard and must also be available in a specific structure. However, the structure of the TYPO3 page tree at the time was anything but suitable for this. The elements displayed as SVG were not structured as a page tree in the data structure, not all elements were displayed, but only the visible elements were in the DOM element, etc. etc. etc.

The challenge now was to prepare the elements for the browser in such a way that it could react accordingly. To do this, the elements must be enriched. Michael took on this extensive and sometimes quite lengthy process. Once the necessary tags were available in the page tree, "only" the corresponding actions for the browser had to be programmed and the page tree could be used barrier-free.

When all this was done, Michael created the corresponding tests to ensure that the pagetree would continue to be accessible in future TYPO3 versions.