Peter Kröner, Webtechnologie-Erklärbär

Mich erreichen regelmäßig E-Mails, in denen gefragt wird, wie man denn am besten eine vorhandene Webseite auf HTML5 umstellt. Besonders oft geht um Fragen der Validierung und um die neuen semantischen Elemente (<section>, <article> und Konsorten). Schließlich sind diese doch nur so schlecht vom Internet Explorer unterstützt und stellen komische Sachen mit den Überschriften an, die es nicht einfach machen, die Struktur der alten Seite 1:1 zu übertragen. Kurz gesagt lautet die Frage immer wieder: was tun beim Webseiten-Umbau? Ich hole an dieser Stelle immer gen die Hype-Bremse aus dem Schrank und behaupte: man kann es auch einfach sein lassen! Es gibt schließlich keine Verpflichtung zum Mithypen und oft existieren noch nicht mal gute Gründe, eine normale, bisher wunderbar funktionierende HTML 4/XHTML 1-Webseite auf HTML5 umzumodeln.

If it ain't broke, don't fix it

Wenn man eine wunderbar funktionierende Webseite hat, die in XHTML 1 oder HTML 4 geschrieben ist, sollte man sich gut überlegen, ob man diese tatsächlich „auf HTML5 umzustellen“ muss. Handelt es sich bei der fraglichen Seite wirklich um eine Webseite, also um ein paar HTML-Dokumente ohne übermäßigen interaktiven Charakter, gewinnt man durch einen Umbau nicht viel. Zwar mögen XHTML 1 und HTML 4 im Moment hypebedingt ein wenig uncool wirken, aber es ist nicht damit zu rechnen, dass es in den nächsten 20 Jahren keine Unterstützung mehr dafür geben wird.

Moderne Webbrowser haben viele Fehler, aber einen Standard halten alle Surfprogramme gleichermaßen ein: unbedingte Abwärtskompatibilität. Die Frage, ob ein Browser irgendwelche neuen Features unterstützt, ist eigentlich ein Luxusproblem. Der mit Abstand schlimmste Bug in einem Browser wäre, wenn er schon bestehende Inhalte des WWW nicht mehr verarbeiten könnte. Niemand würde einen Browser verwenden wollen, der sich der Verarbeitung älterer HTML-Dokumente verweigert, selbst wenn seine Unterstützung für HTML5 und CSS3 noch so großartig wäre. Und so kommt es, dass moderne Browser selbst älteste HTML-Fossilien (in diesem Falle von 1992) noch einwandfrei darstellen. Mit XHTML 1 und HTML 4 oder älter wird es sich die nächsten Jahre und Jahrzehnte genau so verhalten.

Eine Seite umzubauen, nur damit sie HTML5 verwendet, ist also eine ziemlich komische Idee, denn was bisher gut lief, wird auch weiterhin keinen Ärger machen. Stattdessen kann man sich mit einer HTML5-Umstellung sogar zusätzliche Probleme einhandeln.

Hürden und Fallen

Eine Webseite „auf HTML5 umzustellen“ ist allein schon dehalb keine einfache Aufgabe, weil man sich entscheiden muss, wie weit man gehen möchte. Nimmt man einfach sein altes Dokument und tauscht den Doctype aus, so wird man damit sicher keine großen Probleme haben. Wer aber weiter geht, halst sich relativ schnell eine Ansammlung kleinerer und mittlerer Ärgernisse auf.

So hat man zum Beispiel dem Fakt ins Auge zu sehen, dass HTML5 ein „Living Standard“ und damit unfertig ist. In Folge ergeben sich durchaus auch schon mal größere Änderungen. Bestes Beispiel sind die Änderungen am <time>-Element, als das Element innerhalb weniger Tage erst aus dem Standard entfernt und dann wieder eingebaut wurde. In aller Regel sind Änderungen nicht gar so dramatisch wie bei <time>, so dass man dem „Living Standard“ eigentlich recht gelassen gegenübertreten könnte (vor allem wenn man bedenkt, dass kein Ende dieses Zustandes in Sicht ist). Nur wirklich hilfreich ist der ganze Zirkus beim Seitenbau auch nicht, also warum die Eile damit?

Desweiteren gibt es noch das kleine Problem, dass viele Tools noch im XHTML-Zeitalter leben. Enterprisige Frameworks sprechen in aller Regel nur XHTML und manche Editoren kommen noch nicht mit HTML5-Features wie ausgelassenen End-Tags klar. Selbst eigens entwickelte HTML5-Tools haben noch Kinderkrankheiten – der HTML5-Validator weiß zum Beispiel nicht, dass man das &-Zeichen unter einer ganzen Reihe von Bedingungen gar nicht zu escapen braucht. Auch hier gilt: das ist alles nicht dramatisch und selbst im schlimmsten Fall nur mäßig lästig, aber es hilft eben auch nicht wirklich dabei, eine Webseite zu verbessern.

Etwas kräftiger kann man sich schon mit den neuen semantischen Elementen ins Knie schießen. Diese funktionieren bekanntermaßen in den IE6 bis 8 nur, wenn man sie mit JavaScript bearbeitet, aber ob man wirklich die Struktur der Webseite von JavaScript abhängig machen möchte, sollte man sich gut überlegen. In den meisten Fällen dürfte das kein dramatisches Problem darstellen, nur macht der Hack die bisher bestehende Webseite besser? Eher nicht. Hinzu kommt, dass die neuen Elemente die Überschriftenstruktur beeinflussen. Das ist kein Problem, wenn man eine neue Webseite konzipiert, aber eine bestehende Struktur auf HTML5 zu trimmen ist weder einfach, noch besonders sinnvoll – neben den in die neuen Elemente eingebauten WAI-ARIA-Features unterscheidet eine HTML5-Struktur so gut wie nichts von einer herkömmlichen Div-Suppe.

HTML5 bietet natürlich syntaktisch und semantisch so manches Features, das man gern verwenden würde. Wenn man allerdings den endgültigen Nutzen und den zu betreibenden Aufwand vergleicht, ist es vielleicht eine Überlegung wert, die HTML5-Umstellung auf einen Zeitpunkt zu verschieben, an dem man ohnehin alle Templates umbaut.

Wann soll man denn HTML5 verwenden?

Das liest sich jetzt vielleicht so, als wäre pauschal vom HTML5-Einsatz auf Webseiten abzuraten. Ganz so schlimm ist es sicher nicht, es ist nur recht sinnlos, eine gut funktionierende in HTML 4 oder XHTML 1 geschriebene Webseite des Hypes wegen auf HTML5 umzustellen. Anders sieht es aus, wenn man eine neue Seite baut oder aus anderen Gründen größere Umbaumaßnahmen an etwas Bestehendem durchführt. Wenn ohnehin alle Templates überarbeitet oder gar komplett neu geschrieben werden, ist es natürlich anzuraten, den neuesten Standard zu verwenden (wobei man auch hier nicht verpflichtet ist, jedes mögliche Feature einzusetzen).

HTML5 ist primär ein Spielzeug für Webapp-Programmierer. Die paar neuen Bonbons für herkömmliche Webseiten sind nett, aber nicht nicht so großartig, dass man sich darüber umgehend in Arbeit stürzen müsste. Man kann eine Umstellung auf HTML5 also ruhig auf den Zeitpunkt verschieben, an dem sowieso das nächste Redesign ansteht.

Meine Tipps bis dahin:

1. Locker bleiben! Nur weil das halbe Internet und der Chef meinen, man müsste jetzt unbedingt aktionistisch werden, ist das noch lange nicht richtig. Entspannt Aufwand und Nutzen abzuwägen ist nicht nur in Sachen HTML5 eine empfehlenswerte Grundhaltung.
2. Planen! Hat man es geschafft den Hype für den Moment abzuwehren, kann man natürlich für die Zukunft planen. Irgendwann steht der Wechsel auf HTML5 mit Sicherheit an, also sollte man sich der Sache nicht ganz verschließen. Ausprobieren, Lesen, Planen und Gedanken machen sind nie verkehrt.
3. WAI-ARIA lernen! Die fest in die neuen Elemente eingebauten ARIA-Eigenschaften sind mit das größte Plus von semantischem HTML5. Allerdings kann man diese erstens auch manuell in ältere (X)HTML-Dokumente einbauen und zweitens muss man sich als HTML5-Autor ohnehin damit auskennen. Also: lesen!

Der @yannickoo fragte mich letzte Woche, wie man am besten zwei Browserfenster miteinander kommunizieren lassen kann und da die Antwort auf diese Frage etwas länger als 140 Zeichen ist, gibt es hiermit einen Blogpost zu dem Thema. Dank HTML5 existiert eine Reihe von Technologien, die es ermöglichen via Browser in Echtzeit Nachrichten zu versenden um zu empfangen – manche mit, manche ohne Server-Komponente. Um da für etwas Durchblick zu sorgen, werden im Folgenden Cross-Document-Messaging, Server-Sent Events, Web Sockets und Shared Workers einmal in aller Kompaktheit verglichen.

Cross-Document-Messaging

Mit Cross-Document-Messaging kann man, wie es der Name nahelegt, Nachrichten zwischen zwei Dokumenten in einem Client hin- und hersenden. Wenn man Informationen zwischen mehreren Browserfenstern einer Webapp oder zwischen Frames austauschen möchte, ist Cross-Document-Messaging das Mittel der Wahl. Die Benutzung eigentlich ganz einfach: mit postMessage() kann man Nachrichten an andere window-Objekte senden und diese dort mit dem message-Event empfangen. Dazu braucht man ein Ausgangs-Dokument …

<!doctype html>
<title>Cross-Document-Messaging</title>
<p>
<button id="neu">Neues Fenster aufmachen</button>
<button id="hallo">Hallo senden</button>

<script>
// Das andere Fenster aufmachen
var otherWindow;
document.getElementById('neu').onclick = function(){
    otherWindow = window.open('dokument2.html');
};

// Nachrichten an das andere Fenster (otherWindow) senden
document.getElementById('hallo').onclick = function(){
    if(typeof otherWindow !== 'undefined'){
        otherWindow.postMessage('Hallo!', 'http://localhost');
    }
};

// Nachrichten von anderen Fenstern empfangen
window.onmessage = function(evt){
    alert(evt.data);
};
</script>

… und ein Partner-Dokument für den Austausch. In diesem Fall ist das dokument2.html, das im ersten Dokument per window.open() geöffnet wurde:

<!doctype html>
<title>Cross-Document-Messaging</title>
<button id="hallo">Hallo senden</button>

<script>
// Nachrichten von anderen Fenstern empfangen
window.onmessage = function(evt){
    alert(evt.data);
};

// Nachrichten an das öffnende Fenster (window.opener) senden
document.getElementById('hallo').onclick = function(){
    if(window.opener){
        window.opener.postMessage('Hallo!', 'http://localhost');
    }
};
</script>

Das einige Problem ist, dass man bei der Programmiererung dieser API wissen muss, an wen man sendet – das Ziel sind immer irgendwelche window-Objekte, die dem Script bekannt sein müssen. Wenn aber, wie im obrigen Codebeispiel, Start- und Endpunkte einer Nachrichtenübermittlung bekannt sind (und sie sich alle innerhalb einer Browser-Instanz befinden), kann Cross-Document-Messaging ganz nützlich sein.

• Use Case: Nachrichtenübermittlung zwischen mehreren Dokumenten auf dem Client
• Vorteile: Einfach zu benutzen, gute Browserunterstützung
• Nachteile: Start- und Endpunkte eines Kommunikationskanals müssen bekannt sein
• Browserunterstützung: Alle Browser, die neuer als der IE7 sind (s. caniuse.com)

Shared Workers

Web Workers sind Threads für JavaScript. Sie ermöglichen es, komplexe Berechnungen auszuführen, ohne dass das Browser-Interface blockiert. Shared Workers sind eine Sonderform von Web Workers, die einen Hintergrundprozess erzeugen, in den sich mehrere Dokumente einklinken können. Dieser Prozess kann dann natürlich nicht nur für Rechenaufgaben, sondern auch für Kommunikation genutzt werden. Wenn Dokument A eine Nachricht in den Prozess sendet …

<!doctype html>
<title>Shared Worker</title>
<input id="foo" type="button">
<script>

// Shared Worker anlegen (Argumente: Dateiname und Name)
var meinWorker = new SharedWorker('sync.js', 'Sync');

// Nachrichten aus dem Worker empfangen
meinWorker.port.onmessage = function(event){
    alert(event.data);
};

// Button bei Klick Nachricht senden lassen
document.getElementById('foo').onclick = function(){
    meinWorker.port.postMessage('Hallo!');
}

</script>

 … kann diese von dort aus an alle eingeklinkten Dokumente weitergeleitet werden:

// sync.js

// Liste der verbundenen Dokumente
var clients = [];

// Bei eingehender Verbindung den Client in der Liste speichern
self.onconnect = function(event){
    var port = event.ports[0];
    clients.push(port);

    // Eingehende Nachricht alle verbundenen Clients verteilen
    port.onmessage = function(msg){
        for(var i = 0; i < clients.length; i++){
            if(clients[i] && clients[i] !== port){
                clients[i].postMessage(msg.data);
            }
        }
    };

};

Das Ganze funktioniert unabhängig davon, ob sich zwischenzeitlich Dokumente verabschieden oder neu einklinken.

• Use Case: Nachrichtenübermittlung zwischen mehreren Dokumenten auf dem Client, ggf. damit kombinierte Berechnungsaufgaben
• Vorteile: Anzahl der involvierten Dokumente kann jederzeit variiert werden
• Nachteile: Nicht ganz einfach zu programmieren und zu debuggen, mäßige Browserunterstützung
• Browserunterstützung: Chrome, Safari 5+ (inkl. iOS), Opera 10.6+ (s. caniuse.com)

Server-Sent Events

Mit Server-Sent Events kann ein Webserver von sich aus Daten an den Browser senden – und zwar ohne, dass dieser vorher eine Anfrage gestellt haben müsste. Typische Anwendungfälle wären Chats oder Mailclients, bei denen der Server den Browser über neue Nachrichten informieren möchte. Das große Plus von Server-Sent Events ist, dass sich die Umsetzung einer serverseitigen Eventquelle sehr einfach gestaltet; ein simples PHP-Script, das zeilenzweise Text ausgibt, ist alles was man braucht um für Server-Sent Events gerüstet zu sein:

<?php
    header('content-type: text/event-stream');
    echo "data: Dies ist Nachricht Nummer eins";
    echo "\n\n";
    echo "data: Dies ist Nachricht Nummer zwei";

Empfangen lassen sich die Daten über ein einfaches Event:

var source = new EventSource('updates.php');
source.onmessage = function(evt){
    alert(evt.data);
};

Was dieser Technologie fehlt, ist die Möglichkeit, auf gleichem Wege den Server zu kontaktieren.

• Use Case: Nachrichtenübermittlung vom Server zum Client
• Vorteile: Serverseitige Umsetzung trivial
• Nachteile: Kein Rückkanal
• Browserunterstützung: So gut wie überall außer im IE (s. caniuse.com)

Web Sockets

Das am meisten gehypte Kommunikationstool auf dem HTML5-Bereich sind Web Sockets. Hierbei handelt es sich um eine Browser-API und ein komplett eigenes Netzwerkprotokoll, über das ein Browser und ein Server in beide Richtungen Daten schieben können. Für extrem interaktive Anwendungen wie z.B. Spiele sind Web Sockets damit das Mittel der Wahl. Problematisch ist nur die Server-Komponente, denn ein Programm, das auf dem Server Verbindungen und Daten annimmt und versendet, muss erst mal programmiert werden. Es gibt zwar schon fertige Module für Java, Python und Node, doch wer in anderen Technologie-Ökosystemen lebt, wird unter Umständen seinen eigenen Server programmieren müssen. Hat man das getan, kann mit über eine einfache Senden-Event-Kombo Daten austauschen:

// Verbindung aufbauen
var socket = new WebSocket('ws://server.de:12010/updates');

// Bei erfolgter Verbindung eine Nachricht senden
socket.onopen = function(){
    socket.send('Hallo!');
}

// Nachrichten empfangen
socket.onmessage = function(evt){
    alert(evt.data);
}

Der Haken an der Sache ist, dass in freier Wildbahn eine unüberschaubare Anzahl an Protokollversion von Web Sockets unterwegs sind und ein Client oder ein Server müssten all diese unterschiedlichen Protokolle sprechen. Da das nicht leistbar ist (neue Protokollversionen erscheinen beinahe im Wochentakt), ist der einzig gangbare Weg die Verwendung einer Abstraktionsschicht, die sich um das Protokoll-Chaos kümmert und gegebenenfalls einen Fallback verwendet, ohne dass man sich als Programmierer um diese Details kümmern muss. Socket.IO ist eine solche Schicht, mit der sich spielend leicht ein (in diesem Fall auf Node.js basierender) Server …

// Auf Port 1337 auf neue Verbindungen warten
var io = require('socket.io').listen(1337);

// Wenn eine Verbindung zustande kommt ...
io.sockets.on('connection', function(socket){

    // ... Nachrichten senden ...
    socket.send({
        hello: 'world'
    });

    // ... und empfangen!
    socket.on('message', function(data){
        console.log(data);
    });
});

… und ein Client zusammenbauen lassen:

<script src="http://localhost:1337/socket.io.js"></script>
<script>

// Verbindung aufbauen
var socket = io.connect('http://localhost:1337');

// Eine Nachricht empfangen ...
socket.on('message', function(data){
    alert(data);

    // ... und beantworten
    socket.send({
        world: 'hello'
    });

});

</script>

Je nachdem was die gerade anstehende Browser-Server-Kombination hergibt, verwendet Socket.IO entweder Web Sockets, Flash Sockets oder herkämmliches Polling, um eine so gute Echtzeit-Kommunikation zu gewährleisten, wie es möglich ist. Als Entwickler kann man daher einfach sein Gehirn abschalten und programmieren als gäbe es gar kein Problem mit Web Sockets.

• Use Case: Bidirektionale Nachrichtenübermittlung zwischen Server zum Client
• Vorteile: Bidirektionale Echtzeit-Nachrichtenübermittlung!
• Nachteile: Serverseitige Umsetzung aufwändig bis unmöglich (es sei denn man verwendet Socket.IO o.Ä.)
• Browserunterstützung (Web Sockets): Überall außer in IE < 10 und dem Android-Browser (s. caniuse.com)
• Browserunterstützung (Socket.IO): Überall, selbst IE6.

Fazit

Für die Kommunikation innerhalb einer Browser-Instanz hat man die Wahl zwischen Cross Document Messaging und Shared Workers. Letztere braucht man nur, wenn die Anzahl der verbundenen Dokumente sich jederzeit ändern können soll. Andernfalls hat man mit Cross Document Messaging eine sehr einfach zu benutzende API mit guter Browserunterstützung an der Hand, die für die Kommunikation zwischen Fenstern oder Frames wie gemalt ist.

Wenn ein Server mitspielen soll, hat man die Wahl zwischen Server-Sent Events und Web Sockets. Der Hauptunterschied ist, dass Web Sockets einen Rückkanal zum Server bieten und eine eigens programmierte, nicht ganz triviale Serverkomponente benötigt wird. Da sich dieses Problem gemeinsam mit dem Protokoll-Chaos via Socket.IO (das es nicht nur für Node.js gibt, siehe „In other languages“) bequem aus der Welt schaffen lässt, gibt es eigentlich keinen Grund, heutzutage auf Echtzeit-Features in Webapps zu verzichten.

[Update] Web Storage: In einem Kommentar hat Rodney Rehm eine Kommunikationsmethode via Web Storage vorgestellt. Das Ganze geht zwar ein bisschen in Richtung mißbräuchliche Zweckentfremdung (Web Storage ist eigentlich als Speichertechnologie gedacht), hat aber auch Vorteile. Die Technik funktioniert im IE ab Version 8, ist recht einfach zu benutzen und der Absender einer Nachricht braucht keine Kenntnis der angefunkten Endpunkte.

MODx bezeichnet sich bekanntlich als Content Management Framework und kann daher von Haus aus erst mal (fast) gar nichts. Es bietet dem Entwickler nur Tools an, mit denen er selbst etwas bauen kann – zum Beispiel das vollwertige Blogsystem, das in Zukunft bei mir Wordpress ablösen wird. In meinem Fall geht das sogar ganz ohne Extrawürste: einfach die üblichen Module installieren und einrichten, fertig!

Blog-Bausteine

Die MODx-Docs bieten ein offizielles Blog-Tutorial, das im Prinzip alles enthält was man wissen muss. Deshalb hier nur in Kurzfassung die wichtigsten Bausteine:

• getResources ist ein generelles Ressourcen-Aufliste-Snippet für die Anzeige von mehreren Artikeln auf einmal
• getPage teilt den Output von getResources in Seiten auf und liefert eine schöne Paginierungs-Leiste
• Quip implementiert ein Kommentarsystem mit allen Schikanen (Moderationsschleife, Kommentarvorschau, E-Mail-Abo)
• Simplesearch sorgt für die Suchfunktion

Sobald man sich diese vier Snippets via Paketverwaltung installiert hat, sind alle grundsätzlichen Basics für ein Blog vorhanden. Newsfeeds lassen sich mit Bordmitteln bauen. Tools für Tagclouds, Archive, Breadcrumb-Navis usw. gibt es auch, finden aber in meinem Fall keine Anwendung. Dazu kommen noch ein paar Hilfmittel, die nicht blogspezifisch, aber für jede MODx-Seite nützlich sind:

• FormIt für den Formularbau (in meinem Fall nur ein einfaches Kontaktformular)
• Wayfinder erstellt Navigationen
• If macht die Konstruktion flexibler Templates etwas einfacher

Mit all diesen Snippets (jeweils durch 3 Klicks im Backend zu installieren und mit 3-10 Zeilen Code einzubauen) hat man nun alles, was man für ein Blog braucht, doch das allein reicht ja nicht: wir wollen ein Blog haben, das sich so wordpress-nah wie möglich verhält. Dazu brauchen wir noch eine weitere Komponente.

Wordpressifizierung

Wordpress-Blogposts sind ein einfacher Haufen von Artikeln, MODx-Seiten hingegen sind immer hierarchisch aufgebaut. Das lässt sich auch nicht ändern, aber zumindest für sowohl den CMS-Redakteur als auch für die Welt da draußen verbergen. Autofolders sorgt dafür, dass Artikel, die im Ordner „Weblog“ abgelegt werden, automatisch in Unterordner sortiert werden, die dann zum Beispiel nach Jahr und Monat organisiert sind

Wie genau diese Unter-Einordnung ausfällt, kann man konfigurieren – Turbo-Blogger können auch nach Wochen, selten publizierende Gesellen auch nur nach Jahren sortieren lassen. Für den Frontend-Output weist man dann einfach getResources an, nicht die Ordner, sondern ihren Inhalt auszugeben – fertig! „Richtige“ hierarchiefreie Systeme zur Artikelverwaltung sind dem Vernehmen nach in er Entwicklung, interessieren mich persönlich allerdings nicht so sehr. Für meine Zwecke reicht Autofolders.

Wordpress-URLs enden traditionell mit einem Slash, MODx-URLs mit einer dem jeweiligen Content-Typen angemessenen Dateierweiterung. Das lässt sich aber System → Inhaltstypen umstellen. Damit sich die flache Hierarchie der Blogposts auch in der URL wiederspiegelt, habe ich noch die Alias-Pfade in den Systemeinstellungen deaktiviert. Somit verwendet MODx jetzt die exakt gleichen URLs wie Wordpress, so dass am Ende bei der Umstellung nicht mal 301-Redirects angelegt werden müssen.

Was braucht man noch so? RSS-Feeds sind wie erwähnt mit Bordmitteln zu bauen, Spamschutz ebenfalls, ein Rechtesystem für Gastautoren hat MODx sowieso und einen Kommentarfeed kann man aus den diversen Einzelteilen von Quip und RSS-Bordmitteln schnell zusammenstöpseln. Im Wesentlichen fehlt nur noch der Inhalt, inbesondere natürlich die alten Posts und Kommentare aus Wordpress.

Herausforderung Datenmigration

Die Migration des alten Blog-Contents ist nicht ganz einfach. Natürlich verwenden MODx und Wordpress komplett unterschiedliche Datenbankstrukturen, doch auch der Inhalt des Einen ist nicht unbedingt kompatibel zum Anderen. Die Spezial-Tags von Wordpress wie z.B. Caption kennt MODx nicht, während Wordpress in seinen Datenbanken gar kein richtiges HTML speichert, sondern u.A. <p>-Tags erst bei der Ausgabe einbaut. Das alles unter einen Hut zu kriegen, ist nicht ganz trivial, aber nicht unmöglich.

Das Design nervt, alle Inhalte außer dem Blog passen nicht mehr, die Technik im Hintergrund fällt auseinander und generell ist man nur noch genervt: es wird Zeit die eigene Webseite zu überarbeiten. Genau das ist seit Monaten mein Nebenher-Projekt Nummer 1 und so langsam ist die Zielgerade in Sicht. Diese Überarbeitung enthält einen CMS-Wechsel – nach einem halben Jahrzehnt auf Wordpress-Basis wird in Zukunft MODx Revolution Verwendung finden. Und da ich mehrfach um die Darlegung meiner Gründe für den Wechsel sowie einen Erfahrungsbereicht gebeten wurde, gibt es jetzt diesen Artikel (und alle die da ggf. noch folgen mögen).

Ziele der Überarbeitung

Bevor es aber um die CMS-Frage geht, sind dies die Gründe für die Überarbeitung an sich:

1. Ich bin kein Webdesigner und Frontendentwickler mehr, sondern in erster Linie HTML5-Erklärbär. Das sollte die Seite eigentlich schon irgendwie wiederspiegeln, auch jenseits des Blogs.
2. Design und Technik der Seite wie sie jetzt ist, sind zu kompliziert. Das hat teilweise historische Gründe und liegt zum Teil an Wordpress. Weniger bewegliche Teile, die kaputt gehen können, sind das Ziel.
3. Hosting-Umzug. Ausgewachsene Männer haben sich nicht mit 10-Euro-PHP-Hosting von der Stange zufrieden zu geben, sondern haben eine flexiblere, selbstbestimmte Server-Umgebung verdient.
4. Der angesprochene CMS-Wechsel.

Argumente gegen Wordpress

Warum aber nun das CMS wechseln? Als ich vor ziemlich genau 5 Jahren das systematische Bloggen begann, war Wordpress eine naheliegende, schlanke Lösung, die für meine Zwecke wie geschaffen war. Wordpess ist leicht zu installieren und es ist eine große Leistung der Entwickler, dass man auch fast ohne Kenntnisse von PHP oder WP-Interna das System gut den eigenen Bedürfnissen anpassen kann. Außerdem habe ich damals mit Wordpress-Webwork so manchen Euro verdienen können. Seither hat sich so manches geändert:

1. Mit der wachsenden Webtechnik-Fachkenntnis meiner Seite wurde der große Pluspunkt von Wordpress (absolute DAU-Kompatibiblität) zum Fluch. Mit dem Wissen um OOP und ORM macht der wuchernde Funktionsdschungel von Wordpress keinen Spaß mehr und auch die Docs verwirren mich zunehmend mehr, als dass sie mich erhellen. Zu viele Funktionen machen ungefähr das gleiche. Das ist gut, wenn man nur schnell zu irgendeinem Ergebnis kommen möchte, aber wenn man den Anspruch hat, es gut und richtig zu machen, ist es schwierig.
2. Andererseits müssen viele elementare Funktionen wie z.B. Caching in Wordpress via Plugin nachgerüstet werden. Das erhöht den Anteil der beweglichen Teile im System und das kann ich nicht gebrauchen.
3. Auch die Ergebnis einiger Wordpress Kern-Funktionen genügen meinen Ansprüchen nicht mehr. Ohne große Hackerei ist es nicht möglich elementare Grundprinzipien wie unobstrusive JavaScript einzuhalten? Das darf einfach nicht sein.
4. Ich finde es unerträglich, wenn ein CMS versucht zu verhindern, dass der Entwickler die Ausgabe von HTML und Inhalt den eigenen Wünschen anpasst. Wordpress hat das früher nicht gemacht, jetzt schon. Ich habe keinen Anlass, mir das bieten zu lassen.
5. Ich mache kein Wordpress-Webwork mehr. Mein einziges verbliebenes WP-Projekt war mein Blog und sobald das nicht mehr der Fall ist, kann ich einen ganzen CMS-Kosmos aus meinem Kopf und meinem Feedreader verbannen. Die gewonnene Zeit und Hirnkapazität lässt sich dann in andere Dinge stecken.

Warum MODx?

MODx ist als CMS recht flexibel. Es gibt einem nichts vor, sondern stellt nur die Bausteine zur Verfügung, um schnell zum Ziel zu kommen. Das macht mir zunächst einmal die Migration sehr leicht, denn da wo ich keine Lust auf Veränderungen habe (z.B. Permalinks und Seitenstruktur), lasse ich MODx einfach Wordpress emulieren. Hingegen erlaubt mir die Flexibilität, zukünftige Radikalumbauten leichter abzuwickeln. Und obwohl MODx weniger eingebaute Features hat als Wordpress, brauche ich weniger Plugins, um zum gleichen Funktionsumfang zu kommen. Dieses Wordpress-Blog hier verwendet im Moment 26 Plugins, das von MODx nur 8. Der Rest lässt sich durch Filter-Tags oder andere einzeilige Codeschnipsel umsetzen. Weniger bewegliche Teile! Das was MODx fehlt, fehlt mir nicht: auf Trackbacks und komplizierte Media-Verwaltung kann ich verzichten.

Andererseits ist MODx ein sehr mächtiges Content Management System, mit dem man auch mehrere Seiten auf einmal betreiben kann. Da ich mittlerweile auch mehr als eine Seite im Netz habe, bietet es sich an, alles in Zukunft unter einen Hut zu bringen. Weniger bewegliche Teile, alles zentral gesteuert.

Lohnt sich denn die Mühe? Ja, denn verglichen mit einem neuen Wordpress-Theme, bei dem man jedes Stück HTML den eigenen Wünschen anpasst, ist der Bau eines neuen MODx-Designs nebst Migration nicht wirklich mühsamer. Umfassende Blog-Funktionalität lässt sich MODx innerhalb von wenigen Minuten beibringen und auch das Übertragen der Daten ist mittels 200 Zeilen Migrations- und Legacy-Beseitungs-Script schnell gemacht. Wie genau das geht, erklärt dann gerne in folgenden Teilen … wenn denn Interesse besteht.