Contao news

Every year, the Contao Core development team meets twice for a short code sprint of three days. After three meetings in a row, where one core developer was absent each time, this time we were finally able to meet all seven of us together again. As in the spring, we met in Freudenstadt in the beautiful Black Forest.

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 Supporter you can do your part.

Vision and Contao back end

Traditionally, every meeting starts on Sunday evening, and we usually discuss strategic or visionary topics rather than specific problems and their solutions. The extended discussion, which lasted well into the night, ended with the realization that, realistically speaking, the DC_Table will be with us for years to come. Anyone who reads my blog posts regularly knows that we like to discuss what our desired solution for the backend and data storage would look like. API, event sourcing, etc.

We all work on Contao for free and to expect that such fundamental concept changes as these would simply be incorporated into one of the next Contao versions would be a nice story, but also one that is better left in the land of dreams.

In this respect, we have decided to revise the DC_Table again over the next few versions to improve its maintainability and comprehensibility. We also want to incorporate further DX and UX improvements. These include, for example, optimizations at the developer level such as automated operations and global_operations, which are automatically shown or hidden depending on permissions. For the users, we continue to work on gradually converting the old MooTools logic to modern JavaScript with Stimulus and Co. and Andy in particular has again made various small optimizations at this meeting. In the coming versions, for example, look out for better reloading of tree views, opening and closing elements and much more.

Passkeys

The beginning of the end of passwords. At least that's how the many resources on the subject of Passkeys that can be found on the Internet read, and I'd like to invite you to find out a little about it for yourself. Backing the Passkeys are the illustrious names of the members of the FIDO Alliance. In very simple terms, Passkeys are an alternative login option that no longer requires a password. This is expected to increase security and usability for Internet users.

We would certainly also like to jump on this bandwagon and allow registration or login using Passkeys in the future. Anything that makes Contao potentially more secure has a very good chance of being considered for the core. So there was not really much debate about whether we wanted this or not. But of course the technical implementation details gave rise to some discussion, as even the big players who already offer Passkeys were apparently not in agreement on the question of whether or not a Passkey also replaces the username and two-factor authentication. For example, while the Passkey alone is enough to log in to GitHub, Google still requires a username and Amazon and Paypal even require the username and a one-time password. After thorough research, we decided to use the GitHub implementation, as the biometric unlocking of the password manager in which the Passkey is stored is already the second factor and thus replaces the one-time password.

As the technology is just at the beginning, and we only have until the end of the year to introduce new features for Contao 5.3 LTS, the existing login options will probably not change for the time being.

New layout concept

With each new Contao version, Twig is woven deeper and deeper into the core. We get new functions within the templates, more debugging possibilities and an even better integration into the back end. I would like to thank Moritz for all his hard work!

Now that all content elements in Contao 5 have been converted to new controllers and Twig, the question now arises as to the alternative for our fe_page.html5 templates. We don't just want to convert everything 1:1 to Twig, but also use this opportunity - as we did with the content elements - to tidy up and question the status quo. If you take a look at the options in the current page layout, there are various settings that are obsolete. An old CSS framework based on the "Holy Grail" concept, for example, no longer seems particularly up-to-date in the age of Flexbox and CSS Grid.

Here we discussed how we would like to configure page layouts in the future. One result of the discussion is that the sections (or slots) that you can define yourself in the layout today and to which you can then assign articles or front end modules should actually be read from the template itself. Because they have to be in there and with Twig we now have the possibility to invent our own tags with Contao-specific meanings and to read this information from the template. The discussion then moved on to extended page controllers, improved content composition and initial proof-of-concepts.

It almost goes without saying that Moritz is primarily involved in this area. I am curious to see what will be :-)

Improvements to the background workers

In Contao 5.1 we have introduced support for real background workers. This opens up completely new possibilities for us. In the future, for example, we would like to be able to send newsletters in the background. Or that the crawler that rebuilds the search index, for example, can do this in the background. But new features that do not yet exist could also be based on the workers. This also includes a back end search which, in order to function reasonably well, would also have to continuously index content in the background.

There were still various areas that needed to be improved. These include logging for failed messages, but also sensible supervision so that we don't end up having too many workers being started all of a sudden. The latter part in particular was important to us so that we could complete it before the release of 5.3 LTS.

We have also worked out a concept for how these tasks could be displayed and viewed in a standardized job interface in the future. In other words, we would like to generalize the current progress bar of the crawler and display everything that happens in the background in a similar way. Except that several of them could run simultaneously and extensions could also benefit from a corresponding framework.

Since the original pull request for background workers was written by me, it seems that I am now responsible for this area. Accordingly, yours truly has taken on these tasks.

schema.org for all downloads and media content elements

While I'm on the subject of my tasks, I'll briefly add that from Contao 5.3 LTS, the content elements "Download" or "Downloads" and all video player elements will automatically output schema.org data for all files. This option is also available for all extensions that will access the virtual file system introduced in 4.13 and continuously improved since then. Outputting the correct schema.org data for your own elements will be a matter of a few lines of code in the future. Contao will do the rest for you.

Symfony Translations

Since Contao 4 it is possible to use Symfony Translations in extensions. However, it was still not possible to overwrite translations provided in Contao style (contao/languages) using the Symfony Translator. Fritz has taken care of this problem, so that ideally we will be able to do everything via the Translator in the future and get away from accessing superglobals.

Content URL Generator

The standard concept of Symfony Routing is that you know the route names and their required parameters. Let's imagine there is a route called blog_post and it would look like this: /blog-posts/{alias}. Then you would use the Symfony URL generator like this: $urlGenerator->generate('blog_post', ['alias' => 'super-alias']). The result would then be /blog-posts/super-alias.

However, Contao or a content management system works a little differently. Routes are dynamic, and we don't actually know what the URL to a page looks like, for example, which should ideally be able to be influenced by the editor. Accordingly, we have been wishing for some time for a way to generate a URL to a "content" via a central interface. In our case, "content" does not just mean a page, but any entity. The URL to a news item, a calendar entry, a FAQ entry, etc. So the goal should be that I, as a Contao developer, could do something like this: $contaoContentUrlGenerator->generate($newsModel). Contao would then know itself what the $newsModel is and what the URL for this model should look like.

Andy has been working on a proof-of-concept and because I'm sure some readers still can't imagine what exactly this is supposed to do for us, I'll just leave you with a picture of the mockup and you can let your imagination run wild.

DNS migration

A problem often mentioned by developers is the URL restriction of page trees and working on different test systems or locally, where different domains are used everywhere. While the productive domain may be domain.com, on a test system it is dev.domain.com and locally domain.wip or similar.

This means that every time you want to import the database locally, e.g. from the productive system, in order to carry out tests or work on new features, you have to go to the site settings and change the productive domains in all root pages to the appropriate local domains.

There have already been suggestions for this in the past, but at this meeting we were able to agree on a solution which Fritz has been working on.

Cross-domain login

Dave has been working on cross-domain logins for the front end preview. So imagine you have different domains for the German and the French page trees. For example, contao-zeitung.de and contao-gazette.fr. Now you log in to contao-zeitung.de/contao to publish a new article. The front end preview works great as long as we are talking about contao-zeitung.de/preview.php/mein-artikel. You can show the hidden elements and review the article in the preview before you publish it. But if you now want to translate this article and also preview it in the front end, this will not be possible without logging in again. Simply because the URL would then be contao-gazette.fr/preview.php/mon-article and cookies (i.e. your back end login) are only valid for one domain at a time for security reasons.

One solution would be to generate valid tokens once when clicking on the front end preview and then log in the back end user dynamically so that they do not even notice this. This would make the usability of this workflow considerably easier.

Nested content elements

Leo and Martin have continued their work on the nested content elements from the last developers meeting. There's not much new to say about this, which is actually a shame because it makes the section on this topic so short in this blog post. But believe me, this feature is quite a lot of work and requires a lot of brainpower. This is not least due to the fact that this feature also affects the DC_Table.

Various improvements and bug fixes

The developer meetings also always offer the opportunity to discuss more complex bugs and find appropriate fixes. Once again, there were too many to mention individually. But here is a small excerpt:

• News, FAQ, calendar entries and newsletter detail views will also be displayed in the sitemap.xml in the future, when a member is logged in, which should improve the indexing of protected pages. Thanks Dave!
• The picker now also works correctly with dynamic ptable - thanks Martin!
• Own routes can be registered more easily in the Managed Edition in the future - thanks Andy!
• A performance improvement for non-existent language files, thanks Fritz!
• Own download content elements can be implemented much easier in the future thanks to a new AbstractDownloadContentElementController
• A complex bug with repeating events has finally been fixed - thanks Martin!

I would also like to thank Maren, who brought us some delicious cake! That was very thoughtful, and we really appreciate it, thank you very much, Maren!

Apart from that, I would like to say a few more words: Another year will soon be over. We have an exciting year ahead of us. Many of you will probably be working with Contao 5 for the first time with the release of Contao 5.3 LTS. The end of the year is always a good opportunity for a bit of self-reflection. Maybe also about the business model of your own company. If you regularly follow this developer meeting blog post series and rely on Contao in your everyday work life to support yourselves and still don't financially participate in Contao, I would like to recommend that you reconsider your budget plans for 2024.

That's all folks! Enjoy the upcoming Advent season, take a step back from time to time, organize one or the other Contao regulars' table and give your loved ones a hug.

– Yanick