• event-recap
• TYPO3

Recap of TYPO3 Community Sprint Q2 2024

Published on June 18th, 2024, 1552 words, 6 minutes to read

Being part of the TYPO3 Core Development team as a Component Merger, it's almost kind of a given that I participate in the quarterly Community Sprints happening at the TYPO3 GmbH headquarters in Düsseldorf, Germany.

Here's a little recap on the things that happened over the week!

Arrival Day

I don't actually want to go to deep on the different days (like in my Surfcamp recap), but this one deserves a special mention. People already might have seen my posts on social media that day, but my travel experience on Sunday was quite something.

To explain, my initial schedule was leaving in Rosenheim at 11:30 and arriving in Düsseldorf at around 18:00. Depending on the trains the average travel time between those two cities is about 6h30min.

My day started quite early because I went to go voting for the European elections as I kinda forgot to get the mail-in vote stuff in time (maybe I also just was too lazy). That all worked fine, and by the time I was home again I suddenly get a phone notification from an app I'd rather not have:

Train ties lifted

For people not in the know, this is something you get when you have a train ticket in DB Navigator that ties you to specific trains. When a train is cancelled and you can't finish your ride, the entire binding is lifted and you can pick whatever train you need to get to your destination. I got this two hours before my journey even started.

Okay, so I picked another train and instead left at 12:30, so I'd arrive Düsseldorf one hour later, no biggie. But I already saw the reason why my previous train was cancelled. Because of the flooding in Bavaria due to the massive rainfall, a part of the tracks between Nuremberg and Würzburg was damaged and trains had to be re-routed.

Fast-forwarding, I arrive in Nuremberg, sitting on the floor of an overcrowded train and as people leave, I finally get a seat. "Ah, so now it's just chilling until Düsseldorf" I thought to myself, just as I hear the train conductor say "We can't leave Nuremberg yet, a signal box right outside here is damaged". This (to no ones suprise) happens every now and then, so I hoped this would be done in an hour max.

Oh, was I wrong. So very wrong.

The signal box repairs took 4 hours. Even worse, at the two hour mark, I received another DB Navigator notification, telling me that my current trip wouldn't be possible either, as my current train now stops in Frankfurt (reason being, as the conductor said, the train is too late already). By this time it's already 19:00, and I'm still 4 hours away from Düsseldorf.

The train ride continued, and after an hour stay from 22:00 to 23:00 in Frankfurt, I boarded my final train and arrived in Düsseldorf at 1:00 in the morning, missing a tram and having to wait for a second one, my check-in time at the hotel was exactly 2:00.

This time it's not even something that fully can be blamed on Deutsche Bahn, but this definitely was the first (and hopefully only) train ride that I took that had more delays than my initial travel time (7 hours of delays for a 6:30h train ride).

What I worked on

Okay, now onto the things that I did over the week!

Unify layout of SelectCheckBox group headers

Patch: #79703

This patch is actually a bit older, I started working on this at the Community Sprint in July 2023. This issue concerns the accordion headers of the SelectCheckBox elements (primarily known in the backend user group edit forms), as they don't really show that they are collapsible. The system basically just assumes that you know. And with the focus of improving accessibility, especially with the GSB coming ever closer, I thought it'd be a good idea to finish this up.

Thanks to Michael Telgkamp for providing me feedback on my implementation and also demonstrating new learnings to me with screen readers right away. That really was insightful and I got more out of this patch than I initially thought!

Properly respect enableClipBoard TSconfig

Patch: #84642

While searching for things to fix, I stumbled upon an issue that mentioned that since the rework of the "Show clipboard" option in TYPO3 12, the documented behaviour of enableClipBoard didn't work anymore.

I investigated this, comparing it against the behaviour of the same option that's present in the list module, and I was wholly confused when that also didn't seem to work properly.

Checking back on the documentation, it first took me a few times of reading to understand what the expected functionality was:

• selectable: the user can select themselves whether they want to see the clipboard or not
• activated: the clipboard is always shown and can't be disabled.
• deactivated: the clipboard is always hidden and can't be enabled.

Having an option with 3 behaviours instead of a bool-ish two state is definitely something, but now having understood what was required, I went through the code and fixed everything according that.

I also stumbled upon the issue at first that the casing of course is important, and writing enableClipboard instead of enableClipBoard gets me nothing.

Anyway, this is now fixed in the next releases of 12 and 13!

Provide backend modules in LiveSearch

Patch: #84654

While reviewing another patch that added something new to the live search in the backend, I kinda thought "Hey, wouldn't it be cool to quickly navigate backend modules using this". Thankfully, I had the developer of the new search, Andreas, sitting right besides me and he made me aware of an older abandoned patch for the modules. That one used an older API and I wasn't able to reuse it, but I made my strides anyway.

And, thanks to the super simple interface to writing search providers for the new search, and quickly reading into how ModuleProvider works, I managed to spin up the new search results in maybe 20 minutes of time.

Of course, there was some more refinement afterwards and more adjustments, but this was really fun and a joy to implement, so props to Andreas for making it this easy to extend the search with new result types!

Don't show dropzone when using Upload button

Patch: #84710

Found another issue in Forge, this time concerning the fact that the dropzone would show in the file list when you press the Upload file button in the module header and when you decide to cancel the file upload the dropzone stays, covering the entire page. So, at first I thought about and quickly implemented the cancel event to hide the dropzone when the file dialog is cancelled. After some discussion with other Backend UX team members, we came to the conclusion that it doesn't even make sense to show the dropzone at all when you click the button. It should only show up if you drag a file into the window. So this patch is a small one-liner, pretty much.

Reviews, reviews and reviews

Well, it's not just me working on my own things, but also others that made their changes. And I reviewed quite a few, including giving feedback and helping to fix small problems here and there!

It also was a pleasure to meet and talk to Sebastian Bergmann (of PHPUnit fame), but in contrary to the others at the sprint, we didn't talk about PHP stuff, and instead I found a follow demoscener and also had a talk about reverse engineering video games!

Outside of the sprint, I also met my longtime friend Liv again (after our last meeting being 8 years ago).

The week was a blast and quite productive as usual, and I can't wait to be back in Düsseldorf again in September!

But first, the next event to attend are the TYPO3 Developer Days in August, see you there!

If you also want to join, there will be two more community sprints this year, to which you can already register over here! I can wholeheartedly recommend this if you want to engage with the heart of the TYPO3 community and work on things together.