• event-recap
• TYPO3

Recap of TYPO3 Community Sprint Q4 2024

Published on November 23rd, 2024, 1773 words, 7 minutes to read

Another quarter, another TYPO3 Community Sprint, which I'm, of course, attending!

To start things off nicely, I had no trouble with my train ride like in June. Things went smoothly, and I arrived on time. I was one of the first people at the hotel.

In terms of focus for the sprint, the core team decided to make bug fixing of the LTS release their priority in November, unsurprisingly labeling it "Bug-Fixing November". The goal was to lower Forge issue counts and finish open reviews on Gerrit.

I decided to focus on Backend JavaScript and Backend UX-related issues, which are my forte in the TYPO3 Core. That said, I also refactored ancient things like GIFBUILDER last year.

poly: And you never even used GIFBUILDER before, did you?

As some of you know (from my social media posts), I've been playing a lot of Satisfactory with friends lately. This led to a fun exchange on the first evening of the sprint, being presented with massive factories and many tips and tricks from the game by a definitive veteran (compared to my lousy 50-ish hours of playtime).

This also led to another side project at the sprint, unrelated to TYPO3...and more related to Satisfactory. I also wanted to present my world, but only having my Macbook with me and getting a Windows-only game running would be an act. I remembered Whisky from several of my friends who had tried it before and decided to give it a shot. I was impressed; without much tweaking, Satisfactory was running incredibly well on the High graphics preset. This may influence my next laptop choice if my current Windows machine dies at some point.

Okay, enough trailing off; time for the TYPO3 stuff!

What I worked on

Fix styling of disabled nullable fields

Patch: #87035

An issue came up right on Monday of the sprint: Nullable fields, discernible by that "Set value" checkbox, didn't have proper dark mode styling yet, so I initially fixed that quite simply. With some feedback from other core mergers, we improved the styling to become a good solution for the moment.

When touching that part of the Form Engine, we noticed that the layout of nullable fields needs refactoring. For a to-be-backported bugfix, it's not an option to adjust the markup of fields (because it might break third-party implementations easily), so we'll postpone that for later.

Fix showing of parent items in selectTree filtering

Patch: #87009

A bug report that initially reported the category search not working where the issue wasn't the search (that one worked just fine) but rather the behavior of the "parent showing" logic when filtering for items.

To explain this, the list of nodes in a tree is generally flat to be worked with, and each node contains parent references that help build the tree.

The logic to get the parent in the select-tree implementation was flawed; it only worked for category trees with a single level and I fixed this in this patch.

Children of selectTree filter should be expandable

Patch: #87005

It's not my patch, but it's an excellent addition. This patch aligns the select tree to the behavior of filtering in the page tree, meaning that filtering allows unfolding child items of the searched item, which wasn't possible previously.

My contributions to this patch were refactoring the code to be way simpler than the initial implementation was, removing recursions and a lot of redundant conditions.

Make CKEditor context aware

Patch: #87065

Most of the backend was made dark mode-compatible in the 13.4 LTS release. One part was a bit more tricky because it also required more consideration was the RTE, CKEditor.

This patch doesn't exactly solve the problem because it still leaves entirely the large white area since I only made the CKEditor UI dark mode compatible, not the content area.

Why? As mentioned above, this is quite a tricky topic. How do people look at CKEditor, is it just a rich structural representation, or a full-on WYSIWYG editor that displays content precisely as it is in the front end (or close to it)?

If we make the background dark mode-aware, we could break existing styling for people who do the latter. That's why we're not shipping this now and probably only make this a v14 change.

Show enum values in site settings in debug mode

Patch: #87149

This was a small request: Adjust the new Site Settings module to show values of enum fields as it does in other Form Engine fields in debug mode.

This was relatively straightforward; it just required some work ahead of the actual feature to pass the backend debug setting state into the frontend. After this was done, showing the actual value was as simple as adjusting a single line.

Make system e-mails context aware

Patch: #87147

This came up due to another change: Because the backend login is becoming context-aware (getting dark mode support), the TYPO3 logo SVG was adjusted to contain CSS that changes the text color depending on the user's color preference.

This same logo is used in system e-mails (test e-mails, password resets, form framework). When someone would open the e-mail in some specific web mailing interfaces, you could only see the orange emblem part of the logo because the text would be white on a white background.

I initially opted to fix this by enforcing e-mails to always be styled in light mode only, but I was then told to add dark mode to the system e-mails directly.

It should be straightforward with CSS. Of course not; it's E-Mail. Support for dark mode queries is wildly different between mail services and devices, and the combination of either, yadda-yadda. The best case is a "not-common" hosting web mailer that displays HTML like that and adequately works in the browser context.

This is quite a naive implementation of dark mode, and it'll work for those who reported that problem.

Reminded me once again why I'm not too fond of frontend work about e-mail.

Ignore invalid tree state in page tree drag actions

Patch: #87168

I'm not sure where I noticed this bug or if I heard someone talk about it, but in some particular cases, it was not possible to drag a new or existing page to the very end of an opened branch in the page tree.

I went into a deep-dive debugging through the dragging behavior of the tree implementation. After one hour of debugging all kinds of values, I found the issue: Broken persisted state.

The trees persist the state of opened nodes in the browser's local storage, so they work with the users' expectation of returning to the state where they left the tree. However, if all children of a node have been deleted, the expanded state will still exist in the local storage.

If a node is marked as expanded, you can't drag an element behind it. In combination with the broken state this now causes erratic behavior in the tree.

This could be fixed manually by deleting the local storage entry for the page tree or using the"Collapse all tree items" option. Both of those reset the state.

I opted to build a fix that would check for elements to have children when it tries to set the state from local storage. We no longer need to set the expanded state if no children exist.

poly: That's enough messing around with tree data structures for the next while...

Extend BeforeActionCallEvent functionality

Patch: #87163

I never expected to touch Extbase logic, but here I am. My motivation for this came up when I got a message from my colleague Marcus about some extension things that I then talked about with Torben at the sprint, who previously built the excellent file handling for Extbase into TYPO3 v13 (after people used a somewhat broken "example" for the last 10 years).

This patch extends the BeforeActionCallEvent with the current request, where previously only the arguments were passed into it. It additionally allows setting a response object now, which returns that directly instead of executing the Extbase action. This enables the addition of guard clauses to other extensions' actions or anything else that might need to be changed before an action.

The implementation is done, but before further discussion can happen, I need to write documentation and examples for it as to why this is marked as a Work in Progress still.

So yeah, this was the final sprint for the year, and it was productive, and I had a lot of fun and insightful exchanges with old and new members of the community again.

They are not listed here yet, but once the dates are decided, you can register for Community Sprints here.

The next event I'll be at will be TYPO3 User Group Munich's Christmas party, and unless nothing happens in between, I'll be at Web Camp Venlo in February 2025!