Contao news

Read the official Contao announcements.

Recap of the second Contao Core Developers Meeting 2020

by Yanick Witschi – Current issues

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. The meetings are supported by the Contao Association and are very important to us. Consider becoming a member and supporting us, too!

I have decided to gather the most important information after every meeting and share it with the entire community. This time, the following topics have kept us on our toes:

Special Times

These are truly special times we are living in at the moment. I refrain from commenting on the situation in this blog post. I think it goes without saying that the Core Developer Team is affected by the current circumstances, too, and our minds are not always 100% where they ideally should be.

Despite the adverse circumstances, we have still managed to make it to the second Core Developers Meeting 2020.

PHP 8

The new major version of PHP will be released by the end of the year and with it come many new features and improvements. Establishing compatibility with PHP 8 is a quite high priority for us. However, this is easier said than done, because a Contao Managed Edition consists of over 150 individual packages by now. For many of them, we will benefit from the fact that the PHP community will sort of do the work for us, but we will still have to contribute to many of them ourselves. We are also talking about a new major version and thus changes that are not backwards compatible. Martin and Leo have worked hard on this topic and have started to upgrade our test suite to PHP 8 and to collect a rather long list of todos until we are finally there.

Important: We have decided not to introduce PHP 8 compatibility for Contao 4.4. Contao 4.4 must also be able to run on PHP 5.6 and having compatibility across two major versions of PHP would be much more difficult and costly to achieve. According to our release plan, Contao 4.4 will be entering "security" phase approximately at the same time PHP 8 is going to be released and can still be operated safely with two PHP versions (7.3 or 7.4) until it reaches EOL. In our opinion this is sufficient. The additional effort required would bear no relation to the maintenance effort required by the Core Developer Team.

So if you want to use PHP 8 in the future, an update to the current 4.9 LTS or the 4.10 or 4.11 (depending on which one will be the currently active version by the time) is a required step.

"php": ">=7.2"

Those who actively follow the larger projects in the PHP world may have noticed that some projects have decided to change the definition of their PHP minimum requirement from e.g. ^7.2 to >=7.2 and thus to remove the so-called "upper bound". Both Symfony and PHPUnit have done this recently.

We have discussed the pros and cons at length and have come to the conclusion that we will not follow this path for the time being. Contao as a product cannot be compared to frameworks like Symfony or PHPUnit. Moreover, you can still install dependencies independently of the PHP version using the Composer flag --ignore-platform-reqs , should you want to test higher PHP versions. In Composer 2.0 (which, by the way, is already in the RC phase and ships with massive performance improvements to which we have also contributed substantially), you will also be able to ignore a specific platform dependency only using --ignore-platform-req=php.

Security

David has been working on further security improvements for Contao. This includes, for example, that our backup codes for two-factor authentication will be stored in hashed format in the database in the future. This will cause them to be visible in clear text only during initial creation. We have looked at several larger providers and found some, where the backup codes can be viewed over and over again and therefore must have been stored in clear text. However, we believe the hashed version is more secure, so this will become standard as of Contao 4.11.

Furthermore, David also worked on the enhancement of our Content Security Policy (CSP). He looked at whether and how we could improve the integration in Contao so that we can further increase the security level provided by Contao out of the box.

When you dig deep, you will unfortunately find security vulnerabilities from time to time. Martin faced just this fate, which is why he has been busy fixing a security breach. The corresponding security releases have already been announced separately and the Composer Resolver Cloud will be ready for you with significantly increased capacity.

Routing

Andy had already reworked the entire routing in Contao 4.10. For those of you who have not read the previous blog posts: Routing refers to the process of finding the correct target page based on the HTTP request. Now he is busy using this foundation and building the first walls on top of it. The goal is for us developers that we will soon be able to directly generate URLs for a specific model. Also, the plan is still that page types should be able to define their own URL placeholders, so that finally URLs such as https://domain.com/news/<year>/<month>/<alias>.html will be possible.

Furthermore, it will soon be possible to define whole locale IDs according to the ICU standard, so that our two- or five-digit language codes are no longer the only option. A locale ID may contain not only the language, but also additional information like decimal separators, currencies and more.

Dynamic sitemap.xml

In Contao 4.9 we have introduced a real web crawler. It searches the whole website for links and continues to follow them recursively, just like the crawlers of Google, Bing and Co. do. Pages that cannot be found via the navigation or other links can be linked to these webcrawlers using the sitemap.xml. Previously, these were generated and stored in the share directory when users applied changes in the back end. In the root page you could choose whether a sitemap should be created and what it should be called. The problem with this is that protected pages would have to appear in the sitemap.xml so that our new web crawler is able to find them. For external crawlers like Google, Bing and Co. these are not relevant.

I took care of this issue. Now it is no longer necessary to activate the sitemap explicitly nor to give it any name. Contao automatically generates a /sitemap.xml URL for every domain and is concerned with the correct delivery of the sitemap. Everything is performed dynamically and thus paves the way for the solution of this problem.

I also made sure developers can use a new event instead of the probably familiar getSearchablePage hook, and we are now using the invalidation logic of our caching framework which has the nice side effect that sitemaps no longer have to be generated in the back end and thus performance improvements can be expected here.

API

We have not lost sight of the goal of having a general-purpose API.

Leo has been working on our test suite to improve our framework for functional testing. This is a prerequisite for us to be able to test the existing back end permissions before we start converting our existing ones to make sure, we do not break things.

Jim continued working on the being able to generate Doctrine entities (or basically any PHP classes).

All this does not sound super exciting, but it is a lot of work on our foundation, without which a general-purpose API can never become reality. Besides, these topics have already been discussed in the previous blog posts.

Miscellaneous

Fritz has not been mentioned before, but of course he was also very busy. Thanks to him there will soon be a new rgxp validation available in the DCA which validates for URLs starting with http:// or https://. Furthermore, he supplied us with a new way to conveniently use our own regular expressions without the need for a save_callback or addCustomRegexp hook.

Besides that he has been working on how we can use alternative accordion scripts without the need for jQuery or MooTools.

Jim's "maker-bundle" is also making good progress. We expect this to be the next bundle to be released with the other core bundles and thus will be maintained in our monorepository. The "maker-bundle" will extend the one of Symfony and provide Contao-specific templates.

In the plenary session we also discussed the next steps to get rid of the install tool. The last big issue here, is the management of themes. The creation of administrators and the database migrations have already been introduced on the command line in the previous two Contao versions, so that the Contao Manager is able to take over this work in the future. Here we have discussed a few different approaches and agreed on a basic direction, but there was not enough time to start implementing things.

Bugfixes

As always, we also dealt with bug reports that are a bit more time-consuming, or the solution of which need to be discussed in more depth. We were able to work through some of them. Fritz, for example, took care of the picker which kept "forgetting" previously selected elements during editing.

That's all folks!

The next Developers Meeting will probably take place in February 2021, but who knows what will happen next year.

Use the 1.5kg of celebral matter that is located between your ears, always wear a smile, be considerate to one another and stay healthy!

– Yanick

Show all news

Comments

Add a comment

Please add 5 and 6.