Teil 5: Migration von PHP 4

mysqli und andere Erweiterungen

Neue Funktionen sind für die Migration glücklicherweise nicht problematisch. Bei bekannten Erweiterungen ist die wichtigste Neuerung die mysqli-Erweiterung für die MySQL-Abfrage. Die ältere MySQL-Erweiterung wird allerdings nach wie vor mitgeliefert. Bei einer umfangreichen Migration kann allerdings daran gedacht werden, auch hier den Wechsel zu forcieren.

Neue Versionen

Auch innerhalb der verschiedenen neuen PHP-Versionen gibt es einige signifikante Unterschiede, die bei der Migration zu beachten sind. Die offizielle PHP-Dokumentation liefert glücklicherweise für jeden Versionswechsel ausführliche Infos im Anhang, zum Beispiel .

In PHP 5.3 sind es eher neue Funktionalitäten wie Namespaces in der Objektorientierung, die bei neuen Projekten verwendet werden können. Direkter Migrationsaufwand ist hier kaum einmal gegeben. Der Wechsel auf PHP 6 verspricht keine größeren Hürden zu setzen, wenn die Migration auf PHP 5 bereits sauber gelaufen ist.

Die wichtigste Funktion von PHP 6 ist die vollständige Unicode-Unterstützung. Sie wird allerdings an- und abschaltbar sein, das heißt, nicht jedes Projekt muss sie verwenden. Insgesamt wird bei der Migration der Einfluss der Sprache selbst deutlich geringer. Andere Paradigmen wie Sicherheit, Softwarearchitektur und der Einsatz von Frameworks erfordern eher Anpassungen an moderne Gegebenheiten.

Migration oder Rewrite?

Sollten Sie noch eine Anwendung migrieren müssen, die eine veraltete Zugriffsmethode auf Formularwerte verwendet, wird die Migration naturgemäß recht aufwendig. Allerdings bleibt Ihnen dann meist die Umstellung in der Objektorientierung erspart, da recht alte Anwendungen in PHP selten mit OOP entwickelt wurden.

Dennoch sind die Umbrüche natürlich so gravierend, dass neben einer reinen Migration auch über einen kompletten Rewrite nachgedacht werden sollte. Dabei wird der alte Code komplett entsorgt und nur die Funktionalität dient als Schablone für eine in ihrer Architektur komplett neue Anwendung.

Für einen solch drastischen Schritt spricht einiges: Sie haben so die Möglichkeit, neue Funktionalitäten einzubauen - sind sowieso neue Funktionen geplant, ist das ein weiteres Argument. Oftmals fehlt bei der Altanwendung auch ausreichende Dokumentation und der Code ist schlecht dokumentiert. Das heißt, die Migration wird oft so aufwendig, dass für einen Rewrite nur wenig oder gar kein Mehraufwand einzuplanen ist.

Ein Beispiel ist die enge Integration von PHP-Code mit HTML. Möchte man hier einen Schnitt machen und beides beispielsweise durch ein Template-System trennen oder gar auf den MVC-Ansatz eines Frameworks setzen, wird aus der Migration ganz automatisch ein Rewrite. Auch Sicherheitserwägungen können ein Argument sein. Fünf bis acht Jahre alter Code ist kaum mit Schutz vor XSS und SQL Injection im Hinterkopf entwickelt worden.

Bei der Migration muss zwar sowieso der komplette Quellcode durchforstet werden, aber oftmals ist es schwer, Migrationshürden und Sicherheitslücken in einem Durchgang gleichzeitig im Blick zu haben. Bei neueren, gut strukturierten und dokumentierten PHP 4-Anwendungen sind die nötigen Migrationsschritte oft deutlich weniger schmerzhaft. Die entscheidende Frage ist hier, ob bisher viel oder wenig Objektorientierung verwendet wurde.

Auf die gefährlichen Punkte wie das Übergeben von Objekten als Referenz statt als Wert muss man zwar immer achten, aber mehr Objektorientierung erfordert mehr Handarbeit bei Konstruktor, Sichtbarkeit und Co. Diese Handarbeit ist allerdings - da sie den Aufbau der Anwendung nicht betrifft - reines Abarbeiten und daher zwar nicht spannend aber auch nicht extrem aufwendig.

Fazit

Nichtstun ist die einzige Option, die Sie mit alten PHP-4-Anwendungen nicht haben. Nicht nur der nun endgültig auslaufende Support ist das Problem. Je länger man eine Anwendung vor sich hin laufen lässt, ohne damit zu arbeiten, desto schwieriger wird es, noch Änderungen vorzunehmen. Und spätestens mit PHP 6 fällt für PHP 4 dann endgültig der Vorhang.