by Yanick Witschi
Every year, the Contao Core development team meets twice for a short code sprint of three days. This time we met in Kassel, Germany. Obligatory note: The developer meetings are crucial for the further development of Contao and therefore, as always, I call attention to the fact that the Contao Association funds these meetings. As a Supporter you can do your part.
After already enriching our last meeting, Sebastian Zoglowek followed our call again this time and worked with us on Contao 5.6. Thank you, dear Sebastian, for voluntarily putting yourself through this once again!
At the last meeting, we focused on the backend. Contao now features a system-wide backend search, a context menu, an improved "Edit Multiple" function, a Template Studio (which I still find absolutely mind-blowing – what an achievement!), and numerous accessibility-related improvements.
At every meeting, the same question arises: "What’s next?" And, as always, the amount of work is enormous, while the available time is too short. So, we sit down and discuss what we aim to achieve in the next two or three versions. We always try to balance technically necessary tasks with user features. In the last version, we focused almost exclusively on user features, so this time, we needed to shift more focus toward the technical foundation.
According to our (non-binding) current roadmap, Contao 6 is planned for next year. As with Contao 5, the primary goal will be to remove the newly accumulated stack of backward compatibility issues and streamline the system. We do not yet know whether we will actually release Contao 6 next year – time will tell. However, we expect that the transition from Contao 5 to Contao 6 will be smooth. The new major version follows Semantic Versioning, and those who have followed this blog series and Contao for a while will have become accustomed to the versioning scheme. Continuity is one of our greatest strengths – and will remain so.
Of course, Contao 6 prompted discussions: "What can we finally get rid of?", "What will accompany us for a little longer?", "What security concerns do we have?", "What do we want, and what do our users want?", "What can or must we impose on users because there is no alternative?", etc.
We decided that we would like to finally get rid of input encoding in the near future. The prerequisite for this is clear: Twig.
Our "html5" templates do not encode by default, automatically creating significant potential for XSS vulnerabilities. Twig – or virtually any template language – reverses this and encodes output by default.
We already transitioned content elements to Twig in Contao 5. The next step is frontend modules.
This problem could have been solved relatively easily. We could have simply provided all mod_*.html5 templates as Twig templates as well. However, there is another issue: most core frontend modules are still old modules that are not proper controllers, do not use dependency injection, are full of hooks, and contain legacy code. Additionally, many frontend modules have questionable configuration options that may have made sense at some point but no longer do. Or modules like "Random Image," which are completely incompatible with HTTP caching, etc. – aged software.
Thus, we quickly moved away from merely creating new templates for existing modules. That would be ineffective and a poor investment of time. So, what path do we take? Exactly – we simply build new ones and leave the existing ones untouched. At some point, when the time is right, we remove the old ones. This allows for gradual migration, maintains backward compatibility, and is the same approach we took with content elements.
But why build frontend modules at all? Many of them already exist as content elements in Twig: Images, Links, HTML, etc.
Many extensions offer their elements as both content elements and frontend modules. But why? Simply so they can be embedded in both articles and the page layout.
But why this distinction? An HTML sitemap, for example, is usually displayed only once on a page. Why is it a frontend module instead of a content element? And who says a navigation menu must only be placed in the layout and not directly on a page? Ah, right – that's why there's the "Module" content element, which allows embedding a frontend module on a page.
For this reason, we decided to stop building new frontend modules and eventually phase them out. Instead, content elements can now be embedded directly into the page layout. These will be created within the theme, just as frontend modules currently are. Eventually, only content elements will remain, and users will decide where to use them – permissions will handle the rest.
This will be possible starting with Contao 5.6, a task I have been working on.
Dave has already converted the two-factor frontend module into a new Twig-based content element, and Fritz has started rewriting the login module because…
In the last version, Fritz introduced Passkeys for the Contao backend. Naturally, this functionality should also be available in the frontend. Implementing this is significantly more complex because, while there is only one backend, the frontend includes different site trees, dynamic URLs, and potentially more than just one frontend module. frontend module? No, of course not. Passkeys will only be available in the frontend as a new Twig-based content element. Whether you embed it in the page layout or within an article on a page is up to you. Welcome to the new world!
Speaking of page layouts, they also contain numerous outdated settings. Ultimately, fe_page.html5 determines what is displayed where. Remember the "Holy Grail" layout? That also needs to be replaced with a more modern, Twig-based version.
Moritz has been working on this, and starting with Contao 5.6, users will be able to choose between the current page layout variant and the new one. Custom sections will no longer be created virtually; instead, Contao will recognize which slots are available in the selected Twig template, allowing content elements (and, for now, frontend modules) to be placed accordingly. We introduced support for Twig slots in a previous Contao version – I also wrote about it in the review of last year's developer meeting. Bye, bye, error sources.
Now to a truly tedious topic but also an effort we, as a team, can be proud of. Did you know that Contao now contains about 5,500 automated tests with nearly 40,000 assertions (comparisons of expected vs. actual values)?
Until now, our test suite still ran on PHPUnit 9. This had to change, as outdated software eventually stops receiving maintenance, and the longer we delay the update, the more complex and time-consuming it becomes. New functions and tests are constantly being added.
The tricky part of the update: PHPUnit underwent a significant slimming-down process. Many functions we relied on were rewritten or, in the worst case, removed entirely.
It takes a developer to truly understand the effort involved, but in the end, Andy, Moritz, Martin, and I tackled this mammoth project together. It easily cost us 20 hours of work. After over 150 commits and 300+ modified files, we finally did it!
The entire test suite now runs on PHPUnit 11.5 and is fully operational. Along the way, we improved and rewrote many tests and even got rid of the Symfony PHPUnit-Bridge.
This is an example of a task no end-user will ever see, yet it is vital to the project. Who knows if we would have ever completed this transition without the developer meeting? Your sponsorship of the Contao Association, which funds these meetings, is truly essential!
During recent Contao Calls, there were frequent discussions about the "Overwrite Metadata" function for download content elements being impractical. Often, metadata is maintained within the file, but for specific output locations, a different title or caption might be needed – not a complete override as it currently functions.
Thus, in Contao 5.6, metadata will now be merged. If something is overridden, that value is used; otherwise, the file’s metadata is referenced. If, for instance, a caption is to be explicitly removed, a new {{empty}} insert tag will be available.
A feature developers will appreciate: Thanks to Martin, it will soon be possible to load and reset DCAs multiple times within the same request. To my knowledge, this was the last barrier preventing us from simulating DCA actions. It should now be possible, for example, to mimic a call to /contao?do=news&id=123&table=tl_content&act=edit, loading the appropriate DCA configuration without needing the actual URL request.
Creating accessible navigation is no simple task – many factors must be considered, such as keyboard navigation, translated ARIA labels, focus traps on mobile devices, skip links, and more.
Sebastian and Leo have worked on improving backend navigation accessibility in past Contao versions, and Leo has made additional improvements for Contao 5.6, allowing users to jump directly to content in the backend.
Sebastian is also working on adding corresponding templates and JavaScript solutions to the core for front-end accessibility, providing more out-of-the-box solutions for certain use cases.
DC_Folder, providing a crucial foundation for potentially developing an alternative file manager in the future.This year, the project team surprised us with a "care package." Not only did it contain sweets, but it also showcased the creativity within our team. I am attaching some pictures to the blog post. A heartfelt thank you to Marcus and everyone else who contributed – we truly appreciated it!
Additionally, I would like to remind everyone about the Contao Conference on September 25-26, 2025, in Düsseldorf. I hope as many of you as possible will make your way to the Rhine and celebrate our achievements with us!
That's all, folks!
– Yanick
Yanick is Contao's caching and resolver hero and is partly responsible for making your coffee break a lot shorter since the switch to Composer 2. He was co-founder and the first president of the predecessor of the Contao Association. As a core developer, he puts a lot of heart and soul into Contao. At terminal42, he regularly takes off with clients. He also loves cooking, basketball, tennis, politics, the African continent and astrophysics.
Comments
Comment by Marcus Lelle |
Thank you, Yanick, for your well-founded and eloquent report on the developer meeting. Same procedure as every year. It's always a pleasure to read your lines and kind of look over your should during this work.
I really appreciate that Contao's approach to new challenges is not revolutionary but rather evolutionary.
As always, the care package came from the bottom of our hearts. Here's to another one in the fall. See you in Düsseldorf in any case.
Add a comment