Every year, the Contao Core Developer Team meets twice for a short code sprint of three days. As there are currently four developers from Switzerland, the meeting takes place a bit outside of Zurich... hold on! Many things are different this year.

For example, I'm writing about the first developers meeting in 2021, when in fact I should be writing about the second. Corona, however, turns everything upside down, which means we couldn't meet at the beginning of this year. In my opinion that was a noticeable loss. Contao 4.12 would have had a lot more to offer if we could have met in person. At the same time, this proves how important the those meetings are for Contao. I therefore take this opportunity to point out, as always, that they are sponsored by the Contao Association. Become a Supporter to do your bit.

This year we didn't meet in the Zurich region, but in Colmar, France. The reason for this is relatively simple: In addition to the seven core developers, Moritz Vondano also joined us this time. You might know him from the latest Contao Random broadcasts on Contao TV or from his work on the Twig integration in Contao 4.12. In other words: We just needed some more space and found it (somehow ironically) in the middle of a pretty town in Alsace.

Situation before the meeting

To the delight of a large majority of our users, we have a new LTS version coming! Contao 4.13 LTS will be the next and last Contao 4 version. The foundation will be Symfony 5.4 LTS and the minimum version of PHP will be raised to PHP 7.4.

As with any LTS release, stability and security have absolute priority. Accordingly, there will definitely be no new experimental features (currently Twig is our only experimental integration). But still, the new version will be packed with new features, which I will write a bit more about in a bit.

A few more important words about Contao 5: We have already communicated details about it several times, but I would like to clarify it again. Contao 5 is primarily just a number and there is no reason to worry. Contao remains Contao and we are not reinventing the wheel. We are very aware of our responsibility and know about the great strength of Contao's consistency and predictability.

We have committed to Semantic Versioning compliance with the release of Contao 4. This means that we must always support backwards compatibility down to Contao 4.0. However, Contao 4 is already over six years old (a friendly reminder that we are all getting older) and with each new version that is released, we have to maintain more legacy code. Each additional backwards compatibility layer (BC layer) increases the maintenance burden on the core team and at some point maintaining them just can't be justified anymore. We've reached that point now and it's time to remove some of them for good.

But don't worry, we won't remove support for Contao 3 modules and we won't throw away the Contao Manager or take other measures that will cause you night sweats. There will be some adjustments necessary, but we will make sure that they will be within reason.

So, since we will be certain compatibility layers, Semantic Versioning forces us to increase the frontmost number (the so-called "major version"). And that is exactly what Contao 5 will be for the vast majority of you: Just another number.

So don't panic, everything will be fine!

Insert tags

Insert tags are the love-hate relationship for us in Contao. As a user they are just super handy but the fact that they can be used anytime and anywhere (keyword: context independent) makes us think about potential attack vulnerabilities all the time.

Want a simple example? Let's assume that our page is named after the greatest singer the world has ever seen: Farrokh "Freddie Mercury" Bulsara.

Now we all know the {{page::pageTitle}} insert tag and I'm going to show you how the context in which it is used is important:

• In a normal HTML element, the title is harmless: <title>{{page::pageTitle}}</title> becomes <title>Farrokh "Freddie Mercury" Bulsara</title>.
• In an HTML attribute, however, it destroys the markup: <img alt="{{page::pageTitle}}"></img> becomes <img alt="Farrokh "Freddie Mercury" Bulsara"></img>. However, the correct one would be <img alt="Farrokh &amp;quot;Freddie Mercury&amp;quot; Bulsara"></img>.

Other, typical examples are < and > which are problematic in an HTML context but have no meaning in JSON, for example.

Of course, these are harmless examples, but they show the basic problem. By not knowing the context, we open a Pandora's box of potential attacks.

If you want more information about the problem, you are welcome to read Moritz' comments.

Martin and Moritz spent half the meeting working on improvements to our insert tags concept. Twig will help us massively here and it is therefore also clear that our own PHP templates will have to give way to the much more powerful template language Twig in the long run. Template languages like Twig have the big advantage over native PHP that they are usually parsed and the context is thus known. Corresponding improvements for our Twig implementation have already found their way into the current development branch.

Furthermore, it will be possible to make system-wide settings for allowed insert tags similar to HTML tags and attributes. This way you can prevent your back end editors from adding unallowed data or modules (e.g. using the {{insert_module::xx}} inserttag) anywhere in the page content.

Nothing that a normal user would see directly, but an incredible investment of time and brainpower that will make Contao safer for all of us!

Symfony Security

Andy and yours truly have been working on the back end permissions again. Still with the long-term goal of finally not having them in onload_callbacks, but as separate, reusable security voters. This is a mandatory requirement towards an API implementation.

We are definitely making progress here. Back end permissions will be checked via Symfony's security system in the future. This also requires a slightly differently configured Access Decision Manager than the one Symfony comes with by default. This is now configured correctly for Contao and there are already approaches to automatically check any DCA operations via security voter. There is still a long way to go to get rid of all checkPermissions callbacks, but we are working on it. Whether we will be able to do all this for the 4.13 LTS remains to be seen.

David has taken care of our general Symfony security integration and is working on getting rid of the deprecations. As it looks right now, we won't be able to switch to the new security system without having to do significant BC breaks. Accordingly, this will only find its way into our beloved CMS with Contao 5 and Symfony 6, but his work should make the integration much easier.

Getting rid of our install tool

As always, we were not only concerned with Contao itself, but also with the ecosystem. Martin and Andy worked out a concept for the configuration of extensions through the Contao Manager. As of today, it is conceivable that we can reuse the ConfigTree of bundles. However, we are not yet sure how to integrate it in the Manager in the most user-friendly way. Also, we probably won't just offer all installed bundles for configuration, since a large percentage won't be relevant for most users.

Andy has also been working on the integration of contao:migrate to perform database migrations directly in the Contao Manager. The existing SQL import for themes will be moved from the install tool to the back end in a first step.

Native rel="canoncial" support

Rather by accident, we have developed what we think is a pretty great concept for rel="canonical" links. Thanks to the new concept of a ResponseContext in Contao 4.12, we now have the foundation to replace global arrays like $GLOBALS['TL_HEAD'] etc. step by step.

I have taken on the task of integrating our concept and so Contao 4.13 will have some fancy new features:

• Native rel="canonical" support will be optionally activatable via root page, so existing pages will be unaffected (there it is again, the backwards compatibility).
• Each page will point to itself by default, with the ability to configure which query parameters to keep.
• Developers can facilitate the configuration, for example by adding dynamic parameters themselves.
• It is also possible to use any manually chosen URL.
• Our crawler will also follow rel="canonical" links in the future.
• Our search index will ignore pages that have a rel="canonical" link that does not point to itself.

The Maker Bundle

Jim had already worked on the Maker Bundle during the last developer meeting and it seems that it can finally find its way into Contao! A great help for many developers. Please help Jim and make sure it does the things you want it to do.

Miscellaneous / Bugs

There are of course, as always, many other more or less minor improvements and more complex bugs that we have been working on solving:

• David is working on a way to include a different front end module depending on the loaded root page. It should simplify layouting with multiple languages and make sure that the {{insert_module::*}} insert tag loses popularity.
• Moritz and Martin have finally found a solution for the Doctrine server_version (at 4 am).
• Andy worked on adding PHP 8 attribute to replace our @Hook, @Callback etc. annotations.
• Fritz and Andy have worked on a solution that will allow old content elements that are not yet built as new fragments to affect the caching information of the whole page. It will be possible in the future that Contao will automatically read the start and stop time of elements and reduce the configured cache time of the page if needed.
• Fritz has taken care of the problem that our upload form field does not delete the uploaded file in case of an error. The problem would have been fixed relatively quickly, but then backwards compatibility came up again and one or two hours of effort turned into more.
• Martin provided us with a new Template content element. It will allow to simply output an arbitrary template at an arbitrary place with arbitrary data. So you don't have to create an empty HTML content element with your own template anymore.
• Fritz and Andy are working on a solution to allow page types without routes (e.g. for 404 or 403 page types)
• Leo had (as usual) the honor to do some annoying cleanup work. For example, in the future there will be a HtmlDecoder service instead of static methods on the StringUtil and much more.

At the whole meeting there were about 30 pull requests, of which there are some that consist of changes to more than 60 files and about 4'000 characters.

That's all folks!

I'm looking forward to seeing you all hopefully soon in real life!

– Yanick