TechSummer Online Session Day

After a brief welcome from Fabian Stein, the online event—which is taking place as a replacement for the TYPO3 Developer Days in Karlsruhe, which unfortunately had to be canceled—got underway.

First up was Mathias Schreiber, who outlined all the new features in the latest TYPO3 version 10.

With over 159 features (readers might be wondering at this point why there weren’t 160 :-) ), this latest version of TYPO3 brings many improvements. Among other things, the following features are now available:

• You can now reset the “ Backend ” password if you enable the corresponding option.
• TYPO3 Asset Collector: You can now manage assets more precisely—for example, when third-party extensions want to load data that isn’t needed in the project.
• HTML-based Template Emails: Emails can now be created using Fluid.
• Developers can now look forward to even better support for the PSR-14 standard.
• To support SEO, the new TYPO3 includes simpler options for “redirects” and “slugs.” This makes it much easier to construct a URL from words and word fragments to provide search engines with the information they need.
• The dashboard, which was already introduced elsewhere in this Techsummer, has been expanded to include several new tiles.

The presentation was marred by poor audio quality, so unfortunately it wasn’t possible to follow everything. All that’s left for me to do is encourage you to take a closer look at the new TYPO3 version and give it a try. It’s worth it!

TYPO3 Metrics (Ekkehard Gümbel - bitmotion)

In his presentation, Ekkehard Gümbel will share data about TYPO3 and the community to provide insight into how TYPO3 is perceived and which metrics help the community further develop TYPO3. What trends are emerging in the market? Is it necessary to follow these trends? Which TYPO3 versions are still in use? These and other questions will be addressed. For more information, visit https://www.t3versions.com/.

The question of how “healthy” the TYPO3 community is can also be explored. All of these are important metrics that newcomers to TYPO3 can use to decide whether it’s really worth getting involved with TYPO3.

To this end, the TYPO3 Metrics Initiative was founded to address various aspects of data collection related to TYPO3. Ekkehard is still looking for volunteers who are knowledgeable in some of the relevant areas and would like to support him in this endeavor.

Anyone interested in getting involved can check out the #TYPO3-Metrics Slack channel to see and hear what’s going on. Don’t worry: this doesn’t mean you’re committing to participate just yet.

TYPO3 Nerding TeaTime

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

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

After a brief introduction, the presentation dove right into the nitty-gritty of the subject. Unlike other databases, Redis is fully optimized for speed. This is reflected, among other things, in the fact that Redis stores the entire database in RAM. It’s been a long time since I’ve heard a presentation where the speaker discussed CPU cycles and where the database documentation included O() notation alongside the commands—notation that indicates the computational cost of executing each command. This optimization for performance comes at the cost of a limited environment in which such a database can be deployed. Users are advised to read the Redis use case examples. As with anything that runs exclusively in RAM, it’s worth ensuring during setup that the amount of data held in RAM is kept to a minimum. Hashes are one approach that can be used to load the data to be displayed to users from slower storage.

After an introduction to Redis, Christoph Zimmermann then presented the possibility of using Redis in a TYPO3 project. His benchmark configuration was TYPO3 10.4.4, Apache 2.3, and PHP 7.4.3 on a Dell XPS 13. Without any “black magic” or optimization, the test system was able to triple the number of requests handled with Redis. Of course, you’ll need to test this in your own setup to see if the speed gain is just as significant.

After Christoph Zimmermann introduced Redis, it was Daniel Lienert’s turn to present a real-world example. In a system we developed, we had to implement a very complex and extensive authorization scheme, which would have been impossible without Redis because the response times were simply too long. Daniel used Gatling in his benchmark to simulate realistic user behavior.

Since this is a truly easy-to-install “drop-in” replacement, Daniel suggested simply giving Redis a try in TYPO3 projects. The users of your website’s frontend will thank you for the speed boost.

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

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

Everyone is familiar with the problem: at the start of a project, a style guide is agreed upon between the design agency and the client, but it then changes as the project progresses. How do you track 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:

Take: fluid-components (a TYPO3 extension) and then fluid-styleguide. With these two extensions, you can break down your layout into components and partials that you can then access in your projects. Partials are the smallest units that make up a layout. You can then use these partials in the components, which you can manage with “fluid-components.”

Fluid-Styleguide then helps present the components defined above as a “living” style guide. The extension makes all individual components visible in one place. This has the advantage that the style guide always matches what the developers are using in the project, since, technically speaking, it draws on the same data.

This has many advantages: Designers can see how the layouts have been implemented and can quickly coordinate with developers if the developers need a different implementation. For developers, the advantage is that the developed layout is always visible in one place. The style guide also helps developers create the corresponding components here, allowing them to reconsider individual components at a more abstract level. This makes it possible to standardize certain components, which not only simplifies development but also makes the front-end layout appear more consistent and cohesive. For testers, the advantage is that they can see all components in one place, allowing them to quickly assess whether all agreed-upon components have been implemented. For the project manager, the Living Style Guide offers the advantage of being able to quickly see which components have already been fully implemented and styled. Last but not least, the client can also see at a glance which content is being used in the project.

A Living Style Guide really gains momentum when it’s used to achieve the shortest possible release cycles for the layout as well. Instead of the usual waterfall model, Dan Mall proposes the “Hot Potato” process, in which individual pieces of content are passed from the designer to the developer as quickly as possible—like a hot potato—so the client can then approve the result.

In his presentation, Simon then demonstrated in a live demo how easy it is to implement a new client requirement using the Living Style Guide.

Making the TYPO3 Pagetree Accessible (Michael Telgkamp - mindscreen)

Michael Telgkamp’s presentation focused on how to make the TYPO3 Pagetree more accessible.

Michael is a member of the TYPO3 “Accessibility Initiative,” where he is actively working to make 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 at all accessible in this regard.

Michael had his first ideas for making the Pagetree accessible as early as 2019. He presented his ideas at various TYPO3 events, which led to his invitation to “TYPO3 Initiative Week.” Soon, the idea was born to implement the TYPO3 Pagetree using 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 organized in a specific structure. However, the TYPO3 Pagetree’s structure at the time was anything but suitable for this. The elements, rendered as SVG, were not organized as a page tree in the data structure; not all elements were displayed—only the visible ones were present in the DOM element—and so on and so forth.

The challenge was to prepare the elements for the browser in such a way that it could respond to them appropriately. To do this, the elements had to be enriched. Michael took on this extensive and, at times, quite tedious process. Once the necessary tags were in place in the Pagetree, “all that remained” was to program the corresponding actions for the browser, and the Pagetree was ready for accessible use.

Once all that was done, Michael created the necessary tests to ensure that the Pagetree would remain accessible in future versions of TYPO3 as well.