Contao news

Each 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:

The Contao Core Developer Team

Until the last developers meeting, the Contao Core Developer Team (or "Core Team" for short) consisted of six people. As of today, we are seven and welcome Fritz Michael Gschwantner in our team! Fritz should be well known to most readers, as he's everywhere in the forums using his alter ego nickname "Spooky". Fritz is also part of the documentation core team and thus builds our bridge to the forum as well as the documentation. This is a real gain for Contao and our team - welcome, Fritz!

This time we also invited Richard Henkenjohann to our meeting. Richard has contributed quite a few things to Contao lately (e.g. the new front end preview in Contao 4.9) and we wanted to get to know the young man a little better.

Beside Fritz and Richard, the other six dinosaurs, Andreas, Leo, David, Jim, Martin and myself joined, so that a total of eight people worked nonstop on Contao for three days!

Community

Due to the announced changes within the Contao Association, we did spend quite some time thinking about our community, the way people interact and do business and everything in between. Dries Buytaert, the founder and project lead of Drupal, has analyzed the Drupal community in a highly recommendable blog post and he divides users into so-called "Makers" and "Takers." "Makers" are people who contribute to the project in an unselfish way, e.g. by writing code, writing documentation, organizing events, helping in the forum, and the like. "Takers" are pure users of Contao and its ecosystem.

It is important to understand that this is a neutral analysis. It doesn't mean that "Makers" are good for the project by default and "Takers" are the opposite. An Open Source project wouldn't work having only either of them. It's the mixture of the two that makes the difference.

For us as the core team, it is crucial to have enough "Makers". Because even with Fritz as a reinforcement, it is clear to us that the core team is still primarily responsible for Contao as the software. We can continue to develop Contao, but we cannot keep the ecosystem running by ourselves. That's why we have talked about how we can support our "Makers" even more or how we can create incentives to get more "Makers" on board.

Basically there are no definite results here, but we have intensively worked on possible improvements and found possible solutions. Especially legitimately highlighting our "Makers" is far from easy and kept discussions going on for very long so we burnt the midnight oil.

But you have to understand that this is a matter that is very close to our hearts. We want to have people who volunteer their time and money for Contao to get their well-deserved recognition for it.

Contao 5?

Our last developers meeting was dedicated to Contao 4.9, our latest LTS version. In my blog post about that very meeting, I had already mentioned that stability was the top priority for the LTS release. That's why we deliberately left out certain features or chose one over the other. A good example for this process would be the new migration framework. It seemed enormously important to us to have this in the 4.9 LTS release because our developers would otherwise have to wait another two years, since many Contao users exclusively rely on LTS versions.

This time, however, the situation was completely different. Contao 4.9 LTS is our latest version, it is very stable and we are proud of what we have achieved!

This begs the question of "what now?".

To answer this question, we need to take a step back and look at Contao 4 as a whole.

Contao 4.0 was released in June 2015. Yes, my friends, that was almost half a decade ago! An eternity in our industry.

Almost five years in which Contao has been steadily improving. But as with anything in life, some of the decisions people take proof to have been the wrong ones over time which means you reconsider, deprecate and create alternatives for them again. However, because of our backwards compatibility promise, this means that with every new version our BC layers start to pile up.

We cannot carry on like this forever. There will come a time when we have to make an irreversible cut and get rid of all the baggage we have accumulated. Because those who are not able to forget the past will live in the past at some point. And we don't want to live in the past. We want to remain open to technological progress and have our finger on the pulse of the time. Hence, Contao 5 will be that cut.

But when is the right time and what does this cut even mean?

Contao 4 has long been questioned. Many users showed no understanding for the change to Symfony as a foundation and "Composer" would have had quite a chance as candidate for the ugliest word of the year.

Today, things are different. Contao 4 enjoys increasing popularity. The newly acquired enthusiasm was clearly noticeable during the last Contao Conference. Composer is now available to everybody thanks to our Contao Manager and the Composer Resolver Cloud and its benefits are clearly visible and thus highly appreciated in the community.

Our decisions have proven to be right and we have successfully piloted our ship through the storm and we are on course (yes, I am particularly proud of that!).

There is no way we will slow down this momentum! That's why we think that the time for Contao 5 has not come just yet.

We want to continue on the path we have been taking so far. That means we will continue to tackle problem areas one by one, deprecate the "old way" and build better alternatives.

Our new, long-term goal is a common API. It has been discussed time and time again but we simply have to lay the foundation for it first. If you are building a house, you cannot do that without a solid foundation. And it's still a long way to go for us to reach the point where we can start to build the first walls.

Besides improving the technical foundation of Contao, we of course don't want to lose sight of our users. We will keep them in mind and include user features in every new Contao version as well.

In simple terms, we have two major topics for the upcoming Contao versions:

1. We want to move the technical foundation forward, building the prerequisites for an API. (Topic: API)
2. We must not forget about our users and will include features for them with every new version. (Topic: User)

Accordingly, our next version will be Contao 4.10 and changes will be made in the following areas:

Extensible Doctrine Entities (Topic: API)

Jim has been working on Doctrine the whole meeting. Doctrine is the de facto industry standard in the PHP world for communication with the database and for ORM. Due to its importance in the PHP community, there is a large number of existing PHP libraries that may help us building an API based upon Doctrine.

Contao brings its own ORM solution with its "Models". But its implementation is much simpler compared to Doctrine. For example, it does not support many-to-many relationships. But it has one crucial advantage, namely that any column in the database can be added to an already existing model. Doctrine cannot do this, but it is essential for Contao.

Therefore, Jim wants to make sure that Contao can extend Doctrine entities.

Permissions (Topic: API)

Yours truly has dealt exclusively with our authorization system. Though the entire permission system in Contao is very flexible from the user's point of view, it is currently not particularly well implemented from a technical standpoint. The degree of reusability of the existing routines is virtually zero.

This means we need to clear the decks here first before any API requests will be able to use our permission system to check access to resources.

Or to get back to the house building metaphor: The modification of the authorization system is a necessary part of our foundation in order to be able to build walls on it.

Symfony Mailer Integration (Topic: User)

Fritz has worked on the migration from Swiftmailer to Symfony Mailer. Symfony Mailer is the official successor of Swiftmailer. He has also checked the different possibilities of integration in the back end with the ultimate aim to be able to create different e-mail configurations for different purposes (form dispatch, newsletter etc.).

Replacement of the Install Tool (Topic: User)

Another long-term goal is to replace our install tool (contao/installation-bundle) and to integrate it into the Contao Manager or to provide appropriate commands for our friends of the command line. Richard has worked on contao:user:list and contao:user:add commands, which are the cornerstone of the integration into the Contao Manager. The last remaining function in the install tool would be the theme/template SQL import for which we still have to find a solution. We are thinking about an own composer package type contao-theme but nothing is ready yet. Theme vendors are welcome to contribute on GitHub and work on possible solutions.

Extension of the routing settings into the root page (Topic: User)

Andy has been working on the integration of the settings "Folder URL", "URL suffix" and "Prepend Locale" into the root page settings. This will enable us to handle each root page and thus each domain individually. We also decided to separate the language and the language URL prefix. In the future it will still be possible to assign a language from a predefined list to the page tree but you will be free to define the language prefix for the URL yourself. So if you prefer to have everything reachable at /english/foobar.html instead of /en/foobar.html, for example, you will be able to do that in the future. This makes variants conceivable where, for example, the English page tree has no prefix at all and all other languages use a prefix.

Cleanup, minor improvements

Martin made sure that our pageTree and fileTree back end widgets no longer necessarily require a separate database field for manual sorting. Storing the order of selected items is now performed in the same database column as the selection itself. The exception to this is when entire directories are selected in the file picker. Then it will still require a separate column to store the sorting. In order to simplify the handling, Martin also built helper methods in the new ArrayUtil class and while being on it, deprecated and migrated all the old functions from functions.php over to better alternatives.

Dave has been working on improvements to our static code analysis, raising the PHPStan levels and was also working on the integration of Psalm, which should further improve our code quality. Besides that, he has also added the feature to highlight and filter calendar entries.

We have also worked through a double-digit number of bug reports for Contao 4.9.

That's all Folks!

The next developers meeting is scheduled to take place in September 2020.

– Yanick

PS: Leo is the one that reviews the contributions and checks back with all the others if there are discrepancies or questions and who will eventually merge all those Pull Requests.