Zum Inhalt springen
Der Guide für ein smartes Leben.
4, 5 oder 6?

Migration von PHP 4

Altanwendungen gehören zu den Stressfaktoren im Leben eines Entwicklers. Was Sie bei PHP-4-Karteileichen beachten müssen und welche Migrationsschritte bald auf Sie zukommen.

Autoren: Redaktion pcmagazin und Tobias Hauser • 22.4.2009 • ca. 2:55 Min

Migration von PHP 4
Migration von PHP 4
© Archiv

Der Support für PHP 4 ist offiziell seit Ende 2007 eingestellt, die Zahl der Webserver mit PHP-4-Unterstützung ist aber immer noch sehr groß. Deswegen gibt es auch noch einige Aktualisierungen des 4.4-Branches. Auch viele Hoster bieten noch auf Wunsch PHP 4. Dennoch bedeutet das Ende von garan...

Der Support für PHP 4 ist offiziell seit Ende 2007 eingestellt, die Zahl der Webserver mit PHP-4-Unterstützung ist aber immer noch sehr groß. Deswegen gibt es auch noch einige Aktualisierungen des 4.4-Branches. Auch viele Hoster bieten noch auf Wunsch PHP 4. Dennoch bedeutet das Ende von garantierten Aktualisierungen und Sicherheitsupdates natürlich ein Problem.

Die aktuelle Version 4.4.9 vom August 2008 ist offiziell als letztes Update klassifiziert - nach acht Jahren Laufzeit seit Mai 2000. Außerdem lockt die PHP-5-Welt mit vielversprechenden Funktionen im Bereich Objektorientierung und auch in Sachen Performance hat sich was getan. Und der letzte Vorteil ist auch erfreulich: Wer auf PHP 5 aktualisiert, hat schon die halbe Miete bei der 6er-Migration.

Migrationsstrategie

Die Vorteile und auf Dauer auch die Unabwendbarkeit der Migration von Altanwendungen liegt also auf der Hand. Bleibt die Frage, welche Probleme auftreten können und wie man die Migration am besten angeht. Der erste Schritt ist eine Analyse der Altanwendung. Dabei hilft eine Möglichkeit zum Versionswechsel auf dem Webserver.

Beim Hoster gibt es einige, die Parallelbetrieb der beiden PHP-Versionen erlauben. Allerdings wird das teilweise sehr unterschiedlich realisiert. Nicht so praktisch ist es, wenn PHP 4 und PHP 5 unterschiedliche Dateiendungen besitzen. In diesem Fall ändern sich bei einer Migration die URLs. Das bedeutet nicht nur Arbeit für den Entwickler sondern auch für Suchmaschinen entsprechende Probleme.

Flexibler ist man, wenn eine Testumgebung zur Verfügung steht. Manche Hoster erlauben das Wählen der PHP-Variante auf Verzeichnisebene. Manche arbeiten hier mit einer Verwaltungsoberfläche, andere mit einer .htaccess-Datei. Die einfachste Alternative für den Anfang ist eine lokale Testumgebung. Für die Testumgebung gibt es übrigens auch gute Wechseloptionen.

Das Installationspaket XAMPP () bietet beispielsweise für Windows einen PHP-Versionswechsel per Eingabe. Sie finden ihn im Programmmenü (meist apachefriends).

Lassen Sie sich von den Fehlermeldungen nach dem Versionswechsel nicht entmutigen. Auf den nächsten Seiten erfahren Sie die Prüfkriterien für Ihren Code, um einen aktuellen Status zu erhalten und auch alte Karteileichen zu identifizieren.

PHP-4-Karteileichen

Ein erster Blick sollte der PHP-4-Version gelten, die der alte Code hat. Besonders problematisch sind die ganz alten Versionen. Die problematischste Eigenheit ist dabei der Zugriff auf Formularelemente. In PHP 4.0 und 4.1 konnte man noch per Name als Variablenname auf Formularfelder zugreifen.

Dies wurde dann ab PHP 4.2 aus Sicherheitsgründen mit der Konfigurationseinstellung register_globals aus der php.ini standardmäßig unterbunden. Sie sind zwar auch heute noch in PHP 5 aktivierbar, aber natürlich in keiner Weise sinnvoll und auch bei Hostern nicht aktiviert.

Das heißt, hier sollte ein Update auf jeden Fall ansetzen und diese übrig gebliebenen Katastrophen durch $_GET, $_POST und Co. ersetzen. Mit PHP 6 werden die alten Zöpfe dann nämlich komplett abgeschnitten und register_globals verschwindet.

Ebenfalls vom Aussterben bedroht ist die Zwischenlösung mit den langen Arrays wie beispielsweise $HTTP_GET_VARS. Sie lassen sich über die php.ini-Konfiguration register_long_arrays ausschalten. Die entsprechenden Beschlüsse, diese Funktionen zu entfernen, stammen schon aus dem Jahr 2005 ().

Zwar sind viele Ergebnisse des schon legendären Treffens der PHP-Kernentwickler mittlerweile überholt - so muss man für die Integration von Namespaces nicht mehr bis PHP 6 warten, sondern diese werden in PHP 5.3 eingebaut -, aber dass diese alten Zöpfe abgeschnitten werden, ist sicher.

Nicht ganz so problematisch wie der Zugriff auf Formulardaten ist das Einbinden von PHP an sich. Hier gibt es noch einige ältere Varianten, wie die Short-Open-Tags:

<?
//Code
?>

Diese werden über eine php.ini-Konfigurationseinstellung short_open_tag ausgeschaltet. Hier scheint es auch grundsätzlich empfehlenswert, die alte Variante zu entfernen. Dabei ist der einzige größere Verlust die Kurzschreibweise zur direkten Ausgabe von Werten:

<?='Wert' ?>

Diese Variante fällt mit ausgeschaltetem short_open_tag ebenfalls weg. Dies ist vor allem in Anwendungen ein Verlust, wo der PHP-Code sehr eng mit dem HTML-Code verbunden ist. Hier steckt meist hinter dem Auftauchen der Short-Open-Tags auch gleichzeitig ein Architekturproblem. Dies allerdings im Rahmen einer Migration zu beseitigen, ist schwierig.