Dieser Beitrag beschreibt recht detailliert, wie eine antike HTML-Webseite in eine moderne PHP-Seite umgewandelt wurde. Geschrieben wurde der Text schon 2009 – ich habe ihn leider eben erst auf meiner Festplatte wiedergefunden. Wegen der Länge habe ich den Text auf zwei Beiträge verteilt (hier ist Teil zwei).
Einleitung
Meine Highlander-Seite habe ich zum ersten Mal 1998 gebaut. Damals noch nur für mich, teils als Zeitvertreib und teils zum Ausprobieren des gerade erlernten HTMLs. 2000 habe ich dann diese rudimentäre Seite wieder hervorgekramt, graphisch aufpoliert, inhaltlich stark erweitert und online gestellt. Über die Studienjahre habe ich vor allem inhaltlich an der Seite gearbeitet. 2003 gab es einen Relaunch mit dem jetzigen Design, aber davon abgesehen habe ich die Seite technisch nie überholt. Seit dem Ende meines Studiums hat mir dann leider sogar für die inhaltliche Arbeit die Zeit gefehlt.
Die Seite ist in erster Linie von Hand in HTML geschrieben. Damals wusste ich noch nicht halb so viel darüber wie heute, und viele Selbstverständlichkeiten von heute kannte ich einfach noch nicht. Der Begriff „Quirks Mode“ war mir genauso unbekannt wie das Konzept, dass ein Browser Bugs haben kann (Das waren noch Zeiten… *g*). Und natürlich validiert die Seite auch nicht komplett, obwohl sie erstaunlich nahe dran kommt.
Die Navigation der Seite basiert auf einem Frameset. Damit das trotzdem alles halbwegs benutzbar war, habe ich einige Sachen in JavaScript ergänzt, etwa das Einfügen der Pfad-Navigation und die Hervorhebung des aktuellen Menüpunkts im linken Frame. Die Seite zog vor einigen Jahren auf einen PHP-fähigen Server um, aber ich habe lediglich ein, zwei Sachen in PHP geschrieben, etwa die Benachrichtigung über einen toten Link.
Jahre später: Ich habe mittlerweile beruflich täglich mit Content Management Systemen zu tun und meine private Website habe ich mittels WordPress umgesetzt. Bei der Highlander-Seite wäre ein CMS dringend nötig: Das händische Verlinken neuer Seiten an x verschiedenen Stellen war immer einer der großen Nervfaktoren bei der Arbeit daran. Eigentlich wollte ich die Seite auch schon seit Jahren auf ein CMS portieren, aber jetzt muss ich langsam der Wahrheit ins Auge sehen: Dazu werde ich wohl nie Zeit haben.
Auf der anderen Seite mag ich diese Website. Sie ist optisch mit das beste, was ich bisher entworfen habe, und inhaltlich ist sie kurz davor, komplett zu sein. Deshalb habe ich nun beschlossen, sie einfach nach und nach in kleinen Schritten auf PHP umzustellen und fit für das neue Jahrtausend zu machen. Und da ich sicher nicht der einzige bin, der noch Uralt-Seiten zu pflegen hat, wollte ich die grundlegenden Schritte dabei hier mal festhalten.
Falls ihr an euren eigenen Seiten bastelt, versteht es sich natürlich von selbst, dass ihr vorher ein komplettes Backup machen solltet. 😉
Einrichtung der Arbeitsumgebung
Kurz etwas zur Einrichtung meiner Arbeitsumgebung: Ich habe mir XAMPP für Windows installiert. Mit diesem Software-Paket hat man Apache, PHP und MySQL abgedeckt und kommt der Situation auf dem üblichen Server recht nahe.
Die Dateien meiner Webseite liegen unter „D:\Projekte\ammaletu.de“. Damit der Aufruf über den Apache klappt, muss man den jeweiligen Ordner in der httpd.conf eintragen, etwa so:
<IfModule alias_module>
# ...
Alias /ammaletu.de/ "D:/Projekte/ammaletu.de/"
<Directory "D:/Projekte/ammaletu.de/">
Options FollowSymLinks
AllowOverride FileInfo
Order allow,deny
Allow from all
</Directory>
# ...
</IfModule>
Damit wird die URL http://localhost/ammaletu.de auf den Ordner „D:/Projekte/ammaletu.de/“ gelegt, so dass man die Dateien nicht irgendwo in den Tiefen des XAMPP-Ordners ablegen muss.
Umwandlung von HTML-Dateien zu PHP-Dateien
Das Handling der Seite soll einfacher werden, und der Weg dazu führt nur über PHP und Include-Files. Als erstes gilt es also, alle alten „htm“-Dateien zu „php“-Dateien umzuwandeln. Das könnte man z.B. mit Ant machen oder jeder Menge anderer Tools. Ich nutze dafür gewöhnlich das Bulk Rename Utility. Es gibt keinen Umbenennenungs-Wunsch, den man damit nicht erfüllen kann!
Also, das Tool gestartet und folgendes eingegeben:
RegEx (1) Match: (.*)\.htm Replace: \1.php (X Include Extension) Extension (11) X Remove Selections (12) Filter: *.htm X Files X Subfolders
Und schon hat man alle htm-Dateien zur Auswahl. Gegebenenfalls müsst ihr das für html-Dateien wiederholen, falls ihr beide Endungen benutzt habt. Nun liegt die Website also als PHP-Dateien vor. Natürlich enthalten diese PHP-Dateien keinerlei PHP, aber das stört nicht weiter und wird sich ja bald ändern.
Umbiegen der alten Links
Da sich die Endung der Dateien geändert hat, sind damit natürlich alle alten Links auf Unterseiten kaputt. Und zwar sowohl extern gesetzte Links als auch interne Links.
Zuerst einmal die internen Links: Diese ändere ich per Auto-Ersetzen mittels Ultra Edit. Das funktioniert nicht 100% und erfordert noch etwas manuelles Nachbessern, hilft aber schon mal ein ganzes Stück weiter. Alternativ zu UltraEdit könnt ihr auch einen anderen Editor benutzen, wie z.B. Notepad++.
Folgende Ersetzungen habe ich vorgenommen (mit Regular Expressions):
href="\.\./([^"]*)\.htm" -> href="../\1.php" href="([^/]*)\.htm" -> href="\1.php"
Damit sind schon mal viele interne Verweise umgebogen. Per „Suche in Dateien“ muss ich mir alle anderen Vorkommen von “.htm“ anschauen und ggf. manuell ändern.
Und zu den externen Verweisen: Das lässt sich ganz einfach mit einer .htaccess-Datei im Stammverzeichnis der Seite regeln. Der Inhalt sieht so aus:
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^(.*)\.html?$ $1.php [R=301,L] </IfModule>
Diese Anweisung leitet alle Aufrufe von htm- oder html-Dateien auf die entsprechenden php-Dateien um. Was allerdings auch bedeutet, dass wir in der entstehenden Webseite nicht html- und php-Dateien mischen können. Damit kann ich fürs erste aber leben.
PHP-Header einfügen
Die Dateien werden verschiedene PHP-Angaben im Head brauchen. Dafür füge ich in allen Dateien einen PHP-Block ganz am Anfang ein. Dies geht wieder sehr schön per Auto-Ersetzen mit Ultra Edit, da ich weiß, dass alle Dateien mit dem gleichen DocType anfangen (die eine Frameset-Datei mit dem Frameset-Doctype kann manuell angepasst werden).
Fürs erste sieht der eingefügte Block so aus:
<?php
// load the settings page
require_once("includes/settings.php");
?>
Dafür habe ich mir auf oberster Ebene einen includes-Ordner angelegt, in dem einzubindende PHP-Fragmente abgelegt werden können. Die Einbindung der settings.php ist auch der einzige Punkt, wo es eine Rolle spielt, in welchem Ordner die Datei liegt. In tieferen Ordnern muss der Aufruf natürlich “../includes/settings.php“, “../../includes/settings.php“ etc. lauten. Das muss jetzt leider noch ordnerbasiert eingefügt werden. Zum Glück sind meine 371 Dateien nicht auf zu viele verschiedene Ebenen verstreut.
Jetzt muss die Datei settings.php natürlich noch angelegt werden. Sie erhält als einzige Datei lokal andere Werte als auf dem Server. Wenn ihr die Webseite unter Versionskontrolle (SVN, Git…) gestellt habt, fügt die settings.php der Ignore-Liste hinzu und checkt nur eine settings.example.php ein, um nicht aus Versehen die lokale Version auf den Server zu schieben. Fürs erste enthält die Datei nur die Variable $basePath, welche für den Server leer ist und lokal den Pfad „/ammaletu.de“ enthält.
Alle Dateien UTF-8 codieren
Meine Seite wurde um die Jahrtausendwende natürlich noch in ISO-8859-1 erstellt. Mit „UTF-8″ konnte ich damals nicht viel anfangen, und die Hölle verschiedener Zeichencodierungen war mir damals auch noch halbwegs unbekannt. Mittlerweile würde ich aber freiwillig keine andere Codierung als UTF-8 verwenden, also werden die Dateien konvertiert.
Dabei sind zwei Sachen wichtig. Zum einen sollten die Dateien ohne einen BOM gespeichert werden. In UltraEdit kann man das einstellen, in anderen Editoren sicher auch. Wenn Dateien nämlich mit einem BOM beginnen, wird der von Browsern üblicherweise ausgegeben und kann auch andere Probleme verursachen. Das zweite ist etwas spezifischer für UltraEdit: Wenn die Datei nur ASCII-Zeichen enthält, behandelt UltraEdit sie auch als ASCII-Datei. Fügt man dann einen Umlaut ein, nutzt UltraEdit die Default-Codierung des Systems, und das ist immer noch ISO-8859-1. Also schreibe ich üblicherweise ganz oben in den Kommentar ein UTF-8-Zeichen rein, um das gleich klarzustellen und Probleme zu vermeiden, wenn ich später den ersten Umlaut in einer Datei ergänze.
Per Auto-Ersetzen füge ich also in den Header-Kommentar diese Zeile ein:
// encoding: UTF-8 [Proof: Ω]
Das Umcodieren von ISO-8859-1 zu UTF-8 mache ich nicht mittels UltraEdit, da das etwas umständlich wäre. Im Netz habe ich das Tool Kaboom gefunden, welches genau das kann, was ich brauche. Das Programm hat einen Batch-Modus. Man muss die Dateien zwar einzeln einfügen, da man nicht einen ganzen Unterordner reinziehen kann. Aber das ist immer noch vergleichsweise schnell gemacht. Das Programm erkennt die aktuelle Codierung und kann sie zu UTF-8 umwandeln. Es kann auch den BOM entfernen, falls Dateien einen besitzen. Und es kann sogar die content-type-Angabe im Header der Dateien anpassen.
Update Jan 2013: Rückblickend betrachtet war das etwas umständlich. Wer sich auskennt, kann den gleichen Effekt mit wenigen Zeilen in einem kleinen PHP-Script erreichen (Stichwort utf8_decode).
CSS-Dateien zusammenlegen
Vor acht Jahren waren die Internetverbindungen noch nicht so schnell wie heute, also habe ich mich bemüht, mein Stylesheet klein zu halten. Deswegen gibt es für jede Sektion der Seite ein eigenes Stylesheet, jeweils aber nur zwei bis vier Kilobyte groß. Das macht natürlich heute keinen Sinn mehr und funktioniert so auch nicht ohne weiteres mit meiner neuen header.php. Deshalb kommen jetzt alle Stylesheets in ein gemeinsames Stylesheet. Das ist möglich, da sich die Angaben nicht gegenseitig zu überschreiben versuchen. Wäre das der Fall, müsste man doch mehrere Dateien einbinden und dann ggf. den Namen des zu benutzenden Stylesheets in die header.php ebenfalls als Variable reinreichen.
Das neue Stylesheet ist mit 23 KB nicht zu groß und kann sicher noch weiter optimiert werden. Alle Aufrufe für andere Stylesheets können damit aus den Dateien gelöscht werden.
Weiter geht es in Teil 2!