Das Geheimnis von «contao/conflicts»

Vorgeschichte und Standards

Contao 4 ist eine Erfolgsgeschichte, auch wenn das zu Beginn ein Teil der Contao Community nicht so gesehen hat. Der primäre Grund dafür dürfte der Entscheid des Contao Core-Teams, zu 100% auf Composer zu setzen, gewesen sein. Bis zu Version 4 war Contao eine komplette Applikation, die du dir als ZIP-Datei herunterladen, entpacken und auf dem Server aufrufen konntest. Zugegeben, das hatte auch Vorteile, gerade die Installation von Contao gestaltet sich heute etwas komplexer als es anno dazumal war. Der grösste Vorteil von Contao 4 gegenüber seinen Vorgängern ist die Tatsache, dass immer und überall auf Standards gesetzt wird. Es gibt zig Beispiele dafür, wir nennen nur ein paar:

• Contao verfügt mittlerweile über ein äusserst mächtiges Caching-System, das auf den HTTP-Standards basiert, statt des eigenen HTML-Caches, den wir vorher hatten. Das bringt eine Vielzahl an neuen Möglichkeiten, von Load Balancing bis Cache Reverse Proxy'ing wird plötzlich alles möglich.
• Contao nutzt fast überall ICU-Bibliotheken, um sprach- und länderspezifische Probleme zu lösen. Und so kommt es, dass Blogbeiträge mit einem ü im Titel vollautomatisch zu einem ue im Deutschen Alias und zu einem u im Englischen Alias umgewandelt werden können.
• Contao unterstützt Zweifaktor-Authentifizierung auf Basis von TOTP, ebenfalls einem Standard und deswegen funktionieren so viele Apps automatisch mit Contao.
• Contao setzt auf responsive Bilder, das hat es erlaubt, Unterstützung für WEBP oder Lazy-Loading einzuführen.
• Contao nutzt die Standard PHP password_hash Schnittstelle. Ein weiterer Standard, der dafür sorgt, dass du immer den möglichst sichersten Passwort-Hashing-Algorithmus verwendest.
• u. v. m.

Du siehst, Standards hören sich unspektakulär an, sind jedoch für Contao eine enorme Bereicherung. Sie sind vielleicht sogar das ultimative Argument für Contao 4.

Composer ist ebenfalls ein Standard. Composer ist der Paketmanager für PHP-Projekte und nachdem die Einführung des Contao Managers und der Composer Resolver Cloud die Probleme der Bedienung der Kommandoziele und den Mangel an genügend RAM auf dem Server weitestgehend gelöst haben, bleiben nunmehr die Vorteile übrig:

• Dank Composer sind wir in der Lage, alle installierten Pakete abzufragen und sie dadurch in trakked aufzulisten, damit du danach filtern kannst.
• Dank Composer können wir nicht nur die installierten Pakete abfragen, sondern sie auch auf Sicherheitslücken prüfen. Übrigens: Auch da nutzen wir eine standardisierte Schnittstelle.
• Dank Composer können wir vollständige Updates von Installationen via trakked anbieten.

Composer und die Konsequenzen

Der komplette Umstieg auf Composer bringt folgende Konsequenz mit sich:

Contao ist schon lange kein komplettes ZIP-Paket mehr, das du dir irgendwo herunterladen kannst. Jede Installation ist potenziell eine einzigartige Kombination aus Paketen. Nur weil sie dieselbe Contao Version installiert haben und ggf. sogar noch die selben Extensions, heisst das noch längst nicht, dass sie identisch sind. Im Gegenteil, sie sind mit allergrösster Wahrscheinlichkeit unterschiedlich. Das hängt damit zusammen, dass Composer immer versucht, die bestmögliche Paketkombination zu einem gegebenen Zeitpunkt zu finden. Im Normalfall bedeutet das, die neusten Versionen aller erlaubten Pakete, sofern sie denn zusammenpassen. Dabei fliessen auch Plattform-Informationen wie die installierte PHP-Version oder die installierten PHP-Extensions mit ein. Es ist von daher durchaus denkbar, dass Installation A mit PHP 7.4 und Installation B mit PHP 8.1 laufen und somit eine andere Paketkombination erhalten.

Genauso kann ein Update auf die neuste Contao 4-Version heute Vormittag ein anderes Ergebnis geben, als heute Nachmittag. Grund dafür ist, dass inzwischen neue Versionen von Abhängigkeiten veröffentlicht wurden. Dieser Fall ist sogar äusserst wahrscheinlich, weil eine komplette Contao Managed Edition (also eine durch den Contao Manager verwaltbare Contao-Installation) aus ~200 Paketen besteht.

Die ~200 Pakete sind kein Nachteil, sondern im Gegenteil: Das sind ja dann 200 Bibliotheken, die das Contao Core-Team wiederverwenden konnte und deren Logik nicht selber implementiert und das Rad neu erfunden werden musste.

Problem von Abhängigkeiten

Die Tatsache, dass nicht alle Pakete von Contao stammen, bedeutet auch, dass Contao nicht alle Veröffentlichungen der Abhängigkeiten kontrollieren kann und so zu jeder Tages- und Nachtzeit, Veröffentlichungen von Drittanbieter-Paketen stattfinden und somit potenziell ein Problem mit Contao auslösen könnten. Um darauf reagieren zu können, erlaubt Composer, in der eigenen composer.json sogenannte conflicts zu erfassen. Dadurch wird verhindert, dass bestimmte Pakete in gewissen Versionen installiert werden. Das ist allerdings ein manueller Prozess und muss bei jeder Installation wiederholt werden.

Lösung bei Contao

Um dieses Problem zu lösen, hat sich das Contao Core-Team das Paket contao/conflicts ausgedacht. Wie du auf GitHub sehen kannst, besteht dieses Paket ausschliesslich aus einer composer.json, die voller conflict Definitionen steht. Jede Contao Installation, die mit dem Contao Manager verwaltet wird, bekommt automatisch dieses Paket in der Version @dev (also immer der aktuellste Commit im Repository) hinzugefügt. Dadurch hat das Core-Team die Möglichkeit für alle Contao-User an einem zentralen Ort in den Abhängigkeitsauflösungsprozess einzugreifen, sodass im Idealfall die grosse Mehrheit der User von einem Problem gar nichts mitbekommen wird.

Fazit

Die contao/conflicts verhindert die Installation eines Pakets, welches mit deiner Installation inkompatibel ist oder zu bekannten Fehlern führen kann. Ausserdem nimmt es dir die Arbeit ab, einen bekannten Konflikt händisch in die composer.json schreiben zu müssen.