© inkdrop, 123RF

Beim Linux-Magazin stand nach über zehn Jahren der Umstieg von EZ-Publish auf ein neues CMS an. Die Migration zu WordPress erforderte schon wegen der mit Artikeln, News, Bildern und Videos vollgepackten Webseite ein umsichtiges Vorgehen. Ein Blick über die Schulter der Webentwickler.

Der Webauftritt des Linux-Magazins braucht ein freies Content Management System. Dieser Punkt stand im Jahr 2005 im Pflichtenheft. Das von der Firma EZ-Systems betreute EZ-Publish [1] machte damals das Rennen. Der nun erfolgte Wechsel von EZ-Publish auf das freie WordPress [2] erfolgte aus Altersgründen und praktischen Erwägungen: Der Erfahrungsschatz der hausinternen Webentwickler konzentriert sich auf WordPress, das bei der Computec Media Group [3] weitere Webauftritte steuert.

Aufgabenverteilung

Christian Zamora (“Zam”) und Tobias Hartlehnert waren von Beginn an bei der Planung und Durchführung dabei (Abbildungen 1 und 2). “Der Umzug von Linux-Magazin war nicht unser erstes Projekt, das wir von einem anderen System auf WordPress migriert haben”, berichtet Christian Zamora. “Aber es war das erste mit EZ-Publish als Quelle”, ergänzt Tobias Hartlehnert.

Abbildung 1: Christian Zamora ist Senior Web-Developer und Datenschutzbeauftragter bei Computec.

Abbildung 2: Senior-Entwickler Tobias Hartlehnert hat die Tiefen von Linux-Magazin Online erkundet.

Die grundsätzliche Verteilung der Aufgaben für die Migration von einem System auf das andere schildern die beiden folgendermaßen: Der Server-Administrator erledigt das Anlegen der Entwicklungsumgebung und die Grundinstallationen. Er transferiert auch die bestehenden größere Daten wie Videos und Bilder auf das neue System per Sync-Jobs.

Er muss auch berücksichtigen, dass die alte Seite während der Entwicklung des neuen Systems weiterhin besteht und mit Inhalten befüllt wird. Dies stelle sicher, dass nicht erst bei der Umstellung der komplette Datenbestand transferiert werden müsse. Auch verkürze es den Zeitaufwand und die Downtimes beim Live-Gang deutlich. Beim Linux-Magazin wäre ein anderer Weg auch nicht praktikabel gewesen, er hätte, vor allem wegen der ständig nötigen Anpassungen der Migrationsskripte, wohl Tage gedauert.

Aufgabe der Entwickler war es dann, sich um die Grundlagen wie Migrations-Jobs vom alten System zu WordPress zu kümmern. Die Suche und Implementation von Plugins, die für den Betrieb der neuen Seite notwendig sind, zählt ebenfalls dazu. Die Webdesigner setzen die von der Redaktion abgenommenen Design-Entwürfe in HTML und CSS um.

Differenzen

EZ-Pubish sei im Vergleich zu WordPress zwar ein flexibleres System, daraus allerdings erwachse auch eine wesentlich höhere Komplexität der Datenbankstrukturen, erläutert Tobias Hartlehnert. Bei WordPress baue im Prinzip alles auf vergleichsweise flache Datenobjekte auf: Posts (Beiträge, Medien, Bilder), Taxonomien (Kategorien mit Hierarchie) und Schlagwörter (ohne Hierarchie), die sich mit Posts verknüpfen lassen.

Bei EZ-Publish gäbe es auf Content-Ebene zwar nur das Content Object, jedes Content Object sei aber von einer Content Class definiert, die wiederum beliebig viele Attribute unterschiedlichster Art haben kann. Jedes Content Object – etwa eine News (= Content Class) mit Attributen wie Überschrift, Vorspann, Bilder und dergleichen – müsse daher zuerst im Backend definiert werden, bevor es die Redaktion mit Inhalt füllen und veröffentlichen kann (Abbildung 3).

Abbildung 3: Die Content-Objekte und die Migrationsanmerkungen in EZ-Publish.

In WordPress seien Erweiterungen an den Datenobjekten auch kein Problem, und ein Vorteil des CMS sei, dass es praktische und fortgeschrittene Plugins dafür gebe. Die Datenbankstruktur dahinter bleibt aber wesentlich überschaubarer als bei EZ-Publish.

“Wir konnten bis auf die Daten von EZ-Publish nichts übernehmen, weil beide CMS-Systeme komplett unterschiedlich funktionieren”, beschreibt Christian Zamora die Lage. Die Inkompatibilität der beiden Systeme bestand beim Aufbau der jeweiligen Tabellenstrukturen in der Datenbank und je nachdem auch noch bei den Bildgrößen.

Umzugshelfer

Für die Dokumentation der Content-Klassen aus EZ-Publish galt es, deren Attribute zu erfassen und auch die generelle Dokumentation zu den Datenstrukturen zu überblicken, um zu wissen, mit welchen SQL-Abfragen die Entwickler an welche Daten herankommen (Abbildung 4). Die Entwickler haben danach für jede Klasse ein Migrationsskript geschrieben, das die Daten möglichst vollautomatisiert vom alten ins neue System übertragen kann.

Abbildung 4: Die Dokumentation der Content-Klassen des alten EZ-Publish-Systems für die Migration.

Den größten Brocken bei der Programmierung stellte die Konvertierung des von EZ-Publish produzierten HTML, das intern als XML gespeichert ist, in WordPress-konformes HTML dar, erläutert Tobias Hartlehnert. Platzierte Elemente, etwa Bilder, gelte es im Quellcode durch spezielle BBcodes (Bulletin Board Code) zu ersetzen, die WordPress dann bei der Anzeige in HTML konvertiere.

Prüfen und umwandeln

Bei dem über die Jahre gewachsenen System seien also ständig Prüfungen, Korrekturen und Erweiterungen nötig gewesen, um alle möglichen Content-Formen korrekt in das neue System übertragen zu können.

Von den Bildern übernahmen die Entwickler jeweils nur das Original, da das neue Layout neue Formate in unterschiedlichen Auflösungen erfordere. Diese Ableger generiere das WordPress-Plugin während des Imports automatisch. Die inzwischen mit dem Bannfluch der Browseranbieter belegten Videos im Flash-Format wandelte Ffmpeg ins MP4-Format um.

Ortsbesichtigung

In einer ersten Bestandsaufnahme ermittelten die Entwickler, welche Bereiche auf der bestehenden Linux-Magazin-Seite es gibt, also beispielsweise Artikel, News, Galerien, besondere Inhalte wie Job-Listen und Tools im Frontend und Backend. “Wir prüften auch, ob alte Tools noch zeitgemäß sind und vor allem sicher”, sagt Christian Zamora.

Zudem galt es auszuloten, auf welche Daten und Bereiche der Webseite man in dem neuen System verzichten könne – also die Identifizierung von Altlasten. Wichtig sei auch gewesen, in welcher Form und Darstellung die Daten übernommen werden müssen, damit sie inhaltlich und für die weitere Arbeitsweise der Redaktion passen.

Formate checken

Geprüft haben die Web-Spezialisten auch die verschiedenen Useraccounts und die Kommentare, die es zu importieren galt. Wie viele Bilder und welche Formate liegen vor? Gibt es separate Videos und in welchem Format sind diese vorhanden? Müssen sie konvertiert werden? Auch dem Aufbau der URL-Formate widmete sich die Entwicklung. In diesem Schritt kommt auch die SEO-Konformität ins Spiel, erklärt Zamora.

Tobias Hartlehnert hat vor dem Schreiben der eigentlichen Migrationsskripte die Attribute aller sich noch in Verwendung befindlichen Content-Klassen analysiert und dokumentiert. Die größten seien dabei die Bilder gewesen (über 30 000), die Advisories (rund 19 000), die News (über 12 000) und die Print-Artikel (über 4000). Die Summe aller Binaries belaufe sich auf mehr als 46 GByte.

Die Analyse der Datenbankstruktur des bestehenden Systems muss ebenfalls erfolgen, um zu ermitteln, welche Daten in welcher Form nach WordPress zu exportieren waren. Die Entwickler analysierten den bisherigen Tabellenaufbau in der Datenbank und überlegten, wie er sich mit dem neuen CMS zusammenführen lässt, damit WordPress mit den Daten zurechtkommt. Im Detail steckt dahinter auch die Prüfung, ob sich Nutzeraccounts, Artikel und weitere Elemente mit den bestehenden Zuordnungs-IDs transferieren lassen.

Das sei schon sinnvoll, um die bestehende Zuordnung zwischen Kommentaren, Autoren und Artikeln übernehmen zu können. Es diene aber auch der SEO-Anpassung, wenn sich die URL-Struktur beibehalten lässt. Bei den Kommentaren ließ sich das einfach realisieren, es galt dafür nur, einen Iframe von Disqus einzubinden. Da die Migration die URLs der Artikel und News ohnehin übernehmen würde, was schon aus SEO-Gründen sinnvoll ist, funktionierten die Kommentare dann auch auf der neuen Seite, da sie jeweils per URL referenziert sind.

Auswahlverfahren

Die Programmierung der alten Seite hat die Entwickler für das Migrationsvorhaben eher weniger interessiert. “Wir schauen uns an, was im Back- und Frontend passiert, und überlegen uns, wie sich diese Funktionalitäten im Zielsystem umsetzen lassen”, sagt Tobias. Im Fall von WordPress als Umzugsziel stelle sich dann gewöhnlich die Frage: Geht das mit den Standardfunktionen? Und falls die Antwort darauf “nein” laute, stellt sich die Folgefrage: Gibt es dafür bereits ein geeignetes Plugin?

Letzteres sei häufig der Fall, aber die Popularität von WordPress habe für ein enormes Angebot an Plugins gesorgt. Es gäbe oft mehrere Lösungen für die gleiche Aufgabenstellung und es gelte, wenn man nicht auf einer anderen Webseite schon mit einem geeigneten Kandidaten arbeite, zu prüfen, welches geeignet ist.

Grundsätze

“Wir haben drei Grundregeln bei der Entwicklung: Performance, Sicherheit und Verzicht auf so genannte Core-Hacks”, ergänzt Zam. Wenn bislang nicht verwendete Plugins zum Einsatz kommen sollen, achten er und seine Kollegen darauf, ob der Anbieter diese auch weiterhin entwickelt. Auch die Popularität des Plugins und die Bewertungen der anderen Anwender behalten die Spezialisten im Blick. Seien Anpassungen an WordPress oder Plugins nötig, um den gewünschten Betrieb zu gewährleisten, prüfen sie vorrangig, ob das per eigenen Plugins, Hooks und anderen Erweiterungen möglich sei.

Bei spezielle Aufgaben, die Newsletter-Anmeldung bei Mailchimp zählte dazu, seien Eigenentwicklungen nötig gewesen. Fertige Plugins bedürfen aber ebenfalls oft der nötigen Anpassungen, vor allem was Layout und Design betrifft. Es sei dann von Vorteil, wenn das jeweilige Plugin Template-Anpassungen im Child-Theme ermögliche, was leider nicht immer der Fall sei, erläutert Christian Zamora. Ist dies nicht möglich, müsse man Elemente über eigene Hook-Funktionen überschreiben.

Von Print ins Web

Da sich das altehrwürdige Schiff Linux-Magazin schon länger auf seiner Reise befindet, gab es auch einige Wechsel in den Formaten. Das betrifft besonders den Export der redigierten und umbrochenen Artikel aus dem Desktop Publishing System des Verlags. Im Laufe der Jahre haben sich abwechselnd Entwickler darum bemüht, Skripte für den Export aufzusetzen und zu verfeinern.

Der möglichst automatisch und ohne manuelle Korrekturen ablaufende Export war jeweils das Ziel. Dass dabei spezielle Formatierungen, beispielsweise gruppierte Bilder in den Printartikeln, Probleme bereiteten, zählte zu den ständigen Herausforderungen. Den Export aus dem DTP wandelten weitere Skripte in XML- und HTML-Dateien um. Mit diesen Daten mussten die Webentwickler sich befassen.

“Der größte Brocken, den wir komplett neu entwickeln mussten, war der automatische Import der Artikel und PDFs aus den Print-Ausgaben ins neue System”, erklärt Tobias. “Das System holt sich dabei die vom Desktop Publishing System exportierten Rohdaten (XMLs, Bilder, PDFs) und wandelt sie in WordPress-Artikel und Downloads um. Die Redakteure müssen also ihre für das Magazin erstellen Artikel nicht erneut als Online-Version manuell bauen – es reichen ein paar Klicks mit dem neuen Import-Tool.”

Aufgabe für die Entwickler war es auch, das XML der Artikel zu WordPress gerechtem HTML/BBCode zu transferieren, da WordPress Artikeltexte im HTML-Format speichert, angereichert mit WP-eigenen BBcodes, die bei der Ausgabe wieder zu HTML werden.

Eigengewächse

Zu den Eigenentwicklungen zählen die beiden das »IssueM«-Plugin für die Darstellung der Print-Magazine, das sie als neue Erweiterung programmiert haben. (Update: Tobias und Christian haben »IssueM« nicht programmiert sondern über die Schnittstellen modifiziert) Die WordPress-Suche haben die Entwickler durch eine performante auf Basis der Sphinx-Search-Engine ersetzt, damit die Masse an Artikeln die Suchanfragen nicht unerträglich verlangsamt. Das Newsletter-System mussten sie ebenfalls anpassen, um die verschiedenen Inhaltsquellen anzuzapfen.

Gleiches gilt für das Listing-Tool, das die Listings zu Artikeln zum Download vorhält. Das Tool war komplett neu zu programmieren, um sicher und performant zu funktionieren. Anzupacken galt es auch einige Formulare, etwa jenes, mit dem sich neue Autoren anmelden.

Eine neue Errungenschaft ist auch der Newsletter-Generator. Die Eigenentwicklung kommt mit den Anforderungen an den monatlichen Heft-Vorschau-Newsletter zurecht, der beispielsweise die Integration der Inhalte des aktuellen Hefts erfordert. Auch der tägliche Newsletter lässt sich damit fast vollständig automatisch generieren. Die für den Versand zuständigen Redakteure, die zuvor drei Skripte bedient und den Newsletter dann händisch formatiert haben, wissen den Generator zu schätzen (Abbildung 5).

Abbildung 5: Das Backend von WordPress bietet unter anderem den Menüpunkt Newsletter-Generator.

Performance

Zu den aufwändigen Aufgaben zählen die Entwickler die Umleitungen von URLs, die sich systembedingt geändert haben. Es galt, dafür mehrere Funktionen zu schreiben und zu analysieren, welche alten URLs nicht mehr aufrufbar sind.

Der Umzug des Linux-Magazins stellte für die Webentwicklung aber auch Kontakt mit einem WordPress dar, das mehrere Zehntausend Artikel ausliefern muss. “Wir haben zwar reichlich Erfahrung in Sachen Caching, aber das bedurfte doch auch einiger nachträglicher Anpassungen”, erinnert sich Zam. Es sei zwar ein Cache-Plugin im Einsatz, aber das kann die Menge an Dateien nicht in der geeigneten Form verarbeiten, vor allem bei der Cache-Invalidation. Cronjobs greifen an dem Punkt hilfreich ein.

Umzugstermin

Am Tag der Umstellung laufen zuerst noch mal alle Migrationsjobs, um die neuesten News, Artikel und Blogs in das neue System zu importieren, erklärt Zam. Dann erfolge die Anpassung des DNS-Eintrags mit einem kurzen Aktualisierungsintervall. Die vorbereiteten Server-Konfigurationen gehen live – und das war es.

Zumindest fast, denn das Caching verhält sich bei Live-Traffic anders, an manche Umleitung der URLs war noch mal Hand anzulegen. Das Feintuning und weitere nötigen Korrekturen haben die Entwickler inzwischen ebenfalls erledigt.