Yii 1.1 war um 2010 eines der beliebtesten PHP-Frameworks in Deutschland. Schnell, gut dokumentiert, mit Gii ließen sich in einem Nachmittag komplette Verwaltungsoberflächen erzeugen. Entsprechend viele Anwendungen aus dieser Zeit laufen heute noch: Warenwirtschaft, Kundenportale, Branchenlösungen, die ein Dienstleister einmal gebaut und dann jahrelang erweitert hat.
Viele dieser Anwendungen laufen auch nach wie vor stabil. Trotzdem wird die Frage, was aus ihnen werden soll, mit jedem Jahr unangenehmer. Bevor Sie dafür Geld in die Hand nehmen, sollten Sie die folgenden Punkte klären.
Wie dringend ist es bei Ihnen?
Yii 2 erschien 2014. Seitdem bekommt Yii 1.1 nur noch Wartung: Sicherheitskorrekturen und Anpassungen, damit es auf neueren PHP-Versionen läuft. Die letzten 1.1-Versionen kommen mit PHP 8 zurecht, das Framework selbst ist also nicht zwingend das akute Problem. Darauf, dass für jede künftige PHP-Version noch ein Patch kommt, würde ich allerdings keine Planung bauen.
Wie eng es bei Ihnen ist, hängt an drei Dingen, die Sie selbst prüfen können:
- Welche Yii-Version steckt im Projekt? Die Version liefert
YiiBase::getVersion(), alternativ steht sie im Framework-Ordner. Viele Anwendungen laufen auf einer 1.1-Version, die nie aktualisiert wurde, und damit auch nicht auf PHP 8. - Welche Erweiterungen liegen unter
protected/extensions? In Yii-1-Projekten wurden Erweiterungen oft als Kopie ins Projekt gelegt, ohne Composer. Diese Kopien bekommen keine Updates, und viele davon werden seit Jahren nicht mehr gepflegt. - Auf welcher PHP-Version läuft der Server heute, und bis wann bietet Ihr Hoster sie noch an?
Wenn alle drei Antworten unangenehm ausfallen, haben Sie weniger Zeit, als es sich anfühlt. Was eine PHP-Version ohne Sicherheitskorrekturen konkret bedeutet, steht in PHP End of Life: das Sicherheitsrisiko.
Ist Yii 2 der naheliegende nächste Schritt?
Naheliegend ja, einfach nein. Die offizielle Upgrade-Anleitung von Yii sagt selbst, dass Yii 2 eine komplette Neuentwicklung ist. Namespaces, Yii::$app statt Yii::app(), ein anderes ActiveRecord, andere Widgets, andere Konfiguration. Code aus Yii 1 lässt sich nicht hochziehen, er muss neu geschrieben werden.
Das heißt auch: Der Umstieg auf Yii 2 kostet ähnlich viel wie der Umstieg auf Laravel oder Symfony. Den Vorteil vertrauter Konventionen gibt es, er ist aber kleiner, als der gemeinsame Name vermuten lässt. Und mit Yii 3 steht der nächste Architekturwechsel bereits im Raum.
Welche Wege gibt es?
Yii 1.1 aktuell halten und abwarten. Framework auf die letzte 1.1-Version heben, PHP 8 herstellen, Erweiterungen prüfen, die Anwendung ansonsten unangetastet lassen.
Woran es scheitert: Es funktioniert genau so lange, wie niemand neue Funktionen braucht. Jede größere Erweiterung wird in einem Framework gebaut, das niemand mehr lernt, und der Zeitpunkt für den Umstieg verschiebt sich nur. Als Überbrückung für ein, zwei Jahre ist das trotzdem oft die richtige Wahl, wie in PHP-Migration Schritt für Schritt beschrieben.
Schrittweiser Umzug zu Yii 2. Alte und neue Anwendung laufen nebeneinander, Bereich für Bereich zieht um.
Woran es scheitert: Sie zahlen den Preis eines Neubaus und landen in einem Framework, dessen Zukunft wieder einen Bruch enthält. Sinnvoll ist das vor allem, wenn Ihr Team bereits Yii-2-Erfahrung hat.
Schrittweiser Umzug zu Laravel oder Symfony. Dasselbe Vorgehen mit einem Ziel, für das es in Deutschland deutlich mehr Entwickler gibt. Der Ablauf ist in Alte PHP-Anwendung auf Laravel umstellen und Legacy-Code in eine Symfony-Anwendung integrieren beschrieben.
Woran es scheitert: Gii hat in vielen Yii-1-Anwendungen Hunderte fast gleicher CRUD-Controller und Views erzeugt, die über die Jahre jeweils ein bisschen angepasst wurden. Wer die einzeln nachbaut, braucht ewig. Wer sie pauschal durch einen generischen Admin ersetzt, verliert die kleinen Abweichungen, auf die sich die Nutzer verlassen. Die Unterschiede müssen vorher erfasst werden.
Für die meisten Firmen, mit denen ich spreche, ist der dritte Weg der vernünftigste. Wer bereits ein Team mit Yii-2-Wissen hat, sollte das anders gewichten.
Was macht Yii 1 beim Nebeneinanderbetrieb schwierig?
Das Grundprinzip, zwei Anwendungen hinter einem Webserver, der die Anfragen verteilt, steht in Das Strangler-Fig-Pattern. Yii 1 hat ein paar Eigenheiten, die man vor der ersten Etappe kennen sollte.
Das Routing. Viele Yii-1-Anwendungen arbeiten nicht mit sprechenden Pfaden, sondern mit Adressen wie index.php?r=rechnung/view&id=42. Die Route steckt dann im Parameter r, und der Webserver muss nach diesem Parameter verteilen statt nach dem Pfad. Das geht, ist aber fehleranfälliger als eine Regel nach Pfad, und Lesezeichen, Links in alten Mails und externe Schnittstellen verwenden genau diese Adressen. Sie müssen weiter funktionieren.
Die Anmeldung. Yii 1 speichert den angemeldeten Benutzer in der Session unter einem Präfix, das aus Klassenname und Anwendungs-ID berechnet wird. Ist in der Konfiguration keine feste ID gesetzt, leitet Yii sie aus dem Installationspfad und dem Anwendungsnamen ab. Ein Umzug in ein anderes Verzeichnis meldet dann alle Nutzer ab, und die neue Anwendung muss dieses Präfix kennen, um die Sitzung überhaupt zu finden. Kein großes Problem, wenn man es weiß, ein halber Tag Fehlersuche, wenn nicht.
Die Passwörter. Yii 1 schreibt kein Verfahren vor, geprüft wird in der eigenen UserIdentity-Klasse. Ältere Anwendungen nutzen dort oft MD5 oder SHA1. Ab Version 1.1.14 gab es CPasswordHelper, der bcrypt verwendet, und diese Hashes kann password_verify() in jeder modernen Anwendung direkt prüfen. Ein Blick in UserIdentity zeigt also schnell, ob die Passwörter einfach mitkommen oder beim nächsten Login neu gespeichert werden müssen. Mehr dazu in Passwort-Hashing in PHP.
Die Rechteverwaltung. Wer die eingebaute rollenbasierte Rechteverwaltung von Yii 1 nutzt, hat seine Rollen in Tabellen wie AuthItem und AuthAssignment. In diesen Tabellen können sogenannte Business Rules stehen: PHP-Code als Text in der Datenbank, den Yii zur Laufzeit per eval() ausführt. Diese Regeln tauchen in keiner Code-Suche auf, und sie entscheiden darüber, wer was sehen darf. Sie müssen vor dem Umzug ausgelesen und in normalen Code übersetzt werden. Wie man so etwas sicher überführt, steht in Veraltete Authentifizierung sicher modernisieren.
Die Models. CActiveRecord-Klassen enthalten neben den Beziehungen oft Validierungsregeln mit Szenarien, beforeSave-Logik und Scopes, die an vielen Stellen still mitwirken. Speichert die neue Anwendung einen Datensatz, läuft nichts davon. Vor jedem Umzug wird deshalb in Tests festgehalten, was beim Speichern tatsächlich passiert, siehe Tests in Legacy-Code einführen, wo keine sind.
Weiß bei Ihnen noch jemand, wie die Anwendung funktioniert?
Bei Yii-1-Anwendungen ist das die häufigste Lücke. Sie wurden oft von einer Agentur oder einem einzelnen Entwickler gebaut, der heute mit anderen Werkzeugen arbeitet oder gar nicht mehr erreichbar ist. Dokumentation gibt es selten, und die Konfiguration in protected/config/main.php ist über die Jahre zu einer Datei gewachsen, die niemand mehr ganz überblickt.
Dann hilft es wenig, sofort über Zielframeworks zu diskutieren. Zuerst muss auf den Tisch, was da ist: Version, Erweiterungen, Anzahl und Zustand der Controller, wie Anmeldung und Rechte gebaut sind, welche Cronjobs und Konsolenbefehle laufen. Mit dieser Liste lässt sich die Entscheidung in einem Gespräch treffen. Ohne sie wird jede Schätzung, auch meine, ein Ratespiel.
