Wo stand das Dr. Web Magazin – technisch gesehen – bis gestern? Die Dr. Web zugrunde liegende Technik hat sich im Laufe der Zeit entwickelt, ein “gewachsenes” System. Es funktionierte zwar, war aber nicht gut weiterzuentwickeln und skalierte nicht gut. Ein CMS gab es nicht. Das verlangsamte oder behinderte zahlreiche Arbeitsprozesse. Beispielsweise gab es am Ende jeweils eine Handvoll verschiedener Templates für Header, Footer und so weiter.
Artikelrelationen wurden von Hand gemacht. Änderten sich Web-Adressen, musste man die Relationen von Hand korrigieren. Unix- und Linux-Kenner können sowas mal eben mit sed oder awk erledigen, aber diese Kenntnisse hat nicht jeder. Und umständlicher als “automatisch” ist das immernoch. Ich könnte jetzt noch einige Zeit weiter davon berichten, wie es vorher war. Aber es ist wohl schon jetzt deutlich: “Es musste etwas getan werden”. Das war die Hauptmotivation für den Relaunch.
Auf der Bühne
Wie bereits erwähnt wurde, ist WordPress das neue Herz von Dr. Web. Die Software ist schon seit Jahren hier im Einsatz und deren Stärken und Schwächen sind hinreichend bekannt. Diese positiven und – auch wenn es paradox klingen mag – negativen Erfahrungen mit WordPress haben sich bei der Evaluation der Software jedenfalls als ein viel stärkeres Argument erwiesen als beispielsweise die toll klingenden Eigenschaften und Vorzüge ansonsten unbekannter Systeme (“unbekannt” im Sinne von “ohne praktische Erfahrung im Alltag”). Im simulierten “Alltags-Test” hat nur WordPress überzeugt – obwohl es kein klassisches CMS ist. Manchmal bleibt man eben doch bei dem, was man kennt. Das war, jedenfalls für mich, eine unerwartete, aber interessante Erfahrung.
Interessant war der Import der mehreren tausend statischen HTML-Seiten. Leider hatte sich niemand freiwillig gemeldet, um von Hand 3000 HTML-Dateien auszuschneiden und ins CMS zu kopieren. Ich habe also ein Importskript geschrieben. Anhand des Indexes der internen Suchmaschine konnte sich der Importer über die ganze Website hangeln. Dabei musste das Skript alle HTML-Dateien nochmal einlesen, weil im Index kein HTML gespeichert ist. Mittels HTML-Tidy und XPath hat sich der Importer das interessante HTML gegriffen, es verarbeitet und über die XML-RPC-Schnittstelle ans WordPress geschickt. Die Artikel sollten korrekt getaggt und den bereits vorhandenen Autoren zugeordnet werden. Der Importer musste auch die Bilder der Artikel importieren.
Was ich hier ein wenigen Sätzen beschrieben habe, war ein schier endloser Zyklus aus Entwickeln, Testen, Debuggen, Entwickeln… Immer wieder sind wir auf Dateien gestoßen, bei denen etwas anders war als bei Hunderten davor. Das ist aber normal. Innerhalb von zehn Jahren ändert sich ab und zu etwas. Jedes Mal musste ein neuer Importlauf gemacht werden, weil wir nicht die ersten hundert Artikel anders als die letzten hundert importieren wollten.
Trickreich war auch die Umleitung der alten Adressen auf die neuen. Für den Relaunch benötigten wir über 3700 Weiterleitungen. Die Vorgaben waren, dass diese Weiterleitungen einfach zu administrieren sein sollten (insbesondere ohne Webserver-Neustart) und nur wenig “Overhead” erlaubt war. 3700 Weiterleitungen ins Htaccess zu schreiben, wäre sicher nicht ohne erhebliche Leistungseinbußen möglich gewesen, zumal diese Datei bei jedem HTTP-Request, also bei HTML, Bildern, CSS und so weiter abgearbeitet wird. Statt der 3700 Weiterleitungen haben wir nur eine ins Htaccess geschrieben, welche Anfragen zu ausgewählten Verzeichnissen an ein Umleitungsskript schickt. Dieses Skript wertet die komplette Anfrage aus und sucht dann aus den 3700 Zielen das richtige heraus.
Hinter den Kulissen
Unsichtbar oder transparent für die Besucher arbeiten im Hintergrund von WordPress einige selbstentwickelte PlugIns. Sie kümmern sich um die Verbindung zur Kundenverwaltung, zeigen automatisch Illustrationen für Artikel oder passen WordPress besser an vorhandene Arbeitsabläufe an.
Eine große Arbeitserleichterung ist, dass überall auf der Website WordPress-Templates verwendet werden können. Dabei ist es egal, welche Software das HTML erzeugt. Neben WordPress gibt es noch die nicht von WordPress kontrollierten Teile “Mein Abo”/Kundenverwaltung, die Kontaktformulare, die Suchmaschine (Scope). Möglich wird das durch die kleine Programmbibliothek “WPCOMPAT”, welche einen kleinen Teil WordPress-Funktionen nachbildet und sogar unveränderte WordPress-PlugIns verwenden kann.
Das waren ein paar interessante technische Fakten zum Relaunch. Von Gesamtumfang habe ich circa 50% erwähnt, gemacht wurde noch viel mehr – insbesondere die Infrastruktur für den Betrieb der Website wurde erneuert. Die Liste mit den noch zu erledigenden Aufgaben ist derzeit auch wieder gut gefüllt – da kommt also sicher noch mehr. ™
Weitere Beiträge:
- 5 Ideen wie Sie wiederkehrende Arbeitsschritte & Marketingprozesse gewinnbringend im Internet automatisieren! Ein Gastbeitrag von Robert Nabenhauer.
- Wachstum durch Facebook-Gewinnspiele: Wie Sie über Facebook virale Gewinnspiele & eine schnell wachsende Fangemeinde aufbauen
- Wie Sie aufmerksamkeitsstarke Prelaunch-, Launch- und Relaunch-Szenarien aufbauen und dabei Viralität, Spannung & Kaufkraft erzeugen
- Wie Sie waschechte Iphone-Apps mit PhoneGAP entwickeln, um am lukrativen App-Markt mitzumischen
- Wie Sie Ihr Shop-Sortiment so präsentieren, dass der Kunde in Zukunft mehr findet und eher kauft! Ein Gastbeitrag von Nicolas Schmidt-Voigt.
- 11 faszinierende BuddyPress-Plugins, um kostenlos aus WordPress ein soziales Netzwerk zu zaubern
- Die Vorboten einer neuen Internet-Industrie! Ein exklusiver Rückblick & Blick hinter die Kulissen der Clickbank-Exchange 2011 in New York.
Loading ...
klingt nach einer menge spaß
hehe
wwooohhh, interessanter einblick in die kulissen. wie lange habt ihr im hintergrund für die umstellung, inklusive der tests der möglichen cms-alternativen, gebraucht??? einzig die frage, welche cms-alternativen gegen wordpress verloren haben, würde mich noch mehr interessieren.
Vielen Dank für den Einblick in die Arbeiten des Relaunches.
Ein kleines Problem ist mir aufgefallen, nämlich der alte Newsfeed funktioniert nicht mehr, was aber nicht weiter schlimm ist, weil es ja einen gut ersichtlichen Link auf die neuen Feeds gibt. Was ich aber dennoch anmerken möchte: im HTML ist nach wie vor der alte Feed verlinkt:
[link rel="alternate" type="application/rss+xml" title="News-Feed" href="http://www.drweb.de/rss.xml" /]
Ansonsten gefällt mir die neue Seite ziemlich gut. Weiter so!
Danke für den interessanten Blick hinter die Kulissen. Wie lange dauerte denn der Umstellungsprozeß insgesamt?
ein großes Kompliment von mir!
Das war ein sehr interessanter Einblick! In diesem Artikel steckt das Potential von mindestens 10 weiteren Artikeln. z.B. wäre es interessant zu wissen, wie Ihr die Kundenverwaltung eingebunden habt, was man mit WPCOMPAT alles machen kann, ein Einblick in die selbst geschriebenen Skripte u.v.m. Also, lieber Rene, sollte es mal ein „Sommerloch“ geben, weißt Du, worüber geschrieben werden könnte.
Interessanter Artikel zu den Hintergründen eines so umfangreichen Relaunches. Speziell der Import der rund 3000 statischen Seiten war sicherlich ein Meisterstück.
Kann diese Software ihre Datensätze synchronisieren? Ich brauche eine Lösung, welche alle Datensätze stehts auf meinem Notebook und lokalem PC hat.
Hallo Rene, du sagst, dass ihr nicht wolltet, dass bei jedem Aufruf eine lange Liste von .htaccess-Regeln durchgegagen wird. Allerdings stelle ich mir die vorgeschlagene Lösung auch nicht so einfach vor, da ja erst umgeleitet, dann in php verarbeitet wird.
Hier drei alternative Lösungsversuche:
- Kann man nicht die .htaccess auch auf einer unteren Ebene einbauen, um da die Weiterleitung abzufangen? Im Notfall schätze ich die Verarbeitung durch apache als immer noch schneller und ressourcenschonender ein als mit php.
- mittels wordpress-plugin, neue Regeln für die alten permalinks erstellen. Irgendeiner Regeln müssten die alten Seitenpfade ja auch gefolgt sein, oder?
- Lighttpd installieren. Die Weiterleitungsregeln in lighttpd sind ein wenig perfomanter als die unter apache, u.a., da sie nicht immer wieder neu eingelesen werden.
Ansonsten danke für den Einblick.
@Omar:
zu Htaccess auf unterer Ebene: Wäre auch gegangen, allerdings ist man per Skript doch etwas flexibler. Sicherlich ist die Lösung mit PHP weniger schnell als Dein Vorschlag. Unsere Lösung ist aber IMHO ein besserer Kompromiss aus Flexibilität und Performanz. Am schnellsten wäre es sicherlich gewesen, die Umleitungen weder per Htaccess noch per Skript zu machen, sondern direkt in die Apache-Konfig zu schreiben. Hab ich aber nicht getestet, weil es mir zu umständlich ist, bei jeder Änderung einer Weiterleitung an der Konfiguration des Apache herumzuspielen.
zu WP-Permalink: die Links folgen zwar bestimmten Regeln, aber davon gabs IMHO mehrere. War keine gangbare Lösung, zumal auch nicht alle Links direkt ins WordPress gehen.
zu Lighty: Benutze ich selbst privat und bin eigentlich sehr zufrieden. Lighty parst aber keine Htacces-Dateien, was dann auch schon das KO-Kriterium ist, weil die meisten Website-Betreiber, die ich kenne, diese Art der unbürokratischen Konfigurationsänderung wünschen. Außerdem setzen viele Web-Anwendungen den Apache (wg. Htaccess) voraus und ich habe keine Lust, jedes Mal erstmal Rewrite-Regeln umzuformen, damit Lighty sie versteht. So läuft das nämlich auf http://www.reneschmidt.de, was ich recht umständlich finde. Daher gibts hier kein Lighty.
@Geralt: Nein das ist ein absolut 100% maßgeschneideter Importer für den Einmalgebrauch. Der Import ist jetzt abgeschlossen und die Software wandert dann in die Tonne. Was Du suchst ist rsync, Unison oder Robocopy.
Der RSS-Feed scheint übrigens nicht mehr zu funktionieren seit dem Relaunch.
Nur so als kleiner Hinweis.
Gruß
ProfessorWeb
@ProfessorWeb: Ging mir auch so. Einfach den alten Feed entsorgen und den neuen abonnieren. Schon haut es wieder hin.
das mit dem feed verstehe ich gar nicht. sollte alles längst passen und entsprechend umgeleitet sein. müssen wir nachschauen. was inzwischen auch passiert ist. der sollte jetzt auch gehen. am besten aber den “offiziellen” verwenden.
@ 2 STK
überlegungen gab es viele. richtig ernsthaft getestet wurde nur drupal als kandidat. schon ein bisschen her. ich mochte es nicht, fand es viel zu umständlich, mit einer fast ausserirdischen logik ausgerüstet ^^
wordpress hat unter anderen auch den vorteil, dass viele der autoren damit klarkommen resp, es bereits kennen. kein wunder angesichts der verbreitung.
Prima sache! Vielen Dank für den Einblick.
@Rene:
> Nein das ist ein absolut 100% maßgeschneideter Importer
> für den Einmalgebrauch. Der Import ist jetzt
> abgeschlossen und die Software wandert dann in die
> Tonne.
Spricht irgendwas dagegen, den Importer “as is” zu veröffentlichen? Auch wenn er vermutlich bei keinem zu 100% passt, würde er dem ein oder anderen bei der Aufgabe “HTML-Dateien in WordPress importieren” einige Entwicklungszeit sparen
(zumindest der Teil “ausgelesene Daten zu WordPress schieben” ist immer und überall gleich)
Alle Achtung – beeindruckende Leistung.
Das neue Layout (und Farben) gefällt mir sehr gut.
@Christian Bolz: Die Import-Skripte sind ausgesprochen hässlich, nicht repräsentativ geschrieben und wohl auch Buggy. Nur diesen einen Import sollten sie über die Bühne bekommen, mehr nicht. Die sind weit davon entfernt, nützlich oder interessant für andere zu sein. Ich habe allerdings vor, zu ausgewählten Programmteilen und Techniken Artikel zu schreiben. Z.B. XPath. Mal sehen, was kommt.
@ Sven (#14):
Die bisherigen Feeds für Magazin + Weblog brachten seit dem 2.10. nix Neues mehr. Das Redesign war von daher recht überraschend (positiv) … und überfällig.
Ich nehme an, dass Magazin und Blog jetzt unter einem Feed (wie oben) zusammengefasst sind?
@Rene:
> Die Import-Skripte sind ausgesprochen hässlich, nicht
> repräsentativ geschrieben und wohl auch Buggy. Nur
> diesen einen Import sollten sie über die Bühne bekommen,
> mehr nicht. Die sind weit davon entfernt, nützlich oder
> interessant für andere zu sein.
Ich bin mir ziemlich sicher, dass diverse Open Source-Projekte mit einer ähnlichen “guten” Codebasis angefangen haben. Mir ist sogar mal ein Script mit folgendem Kommentar untergekommen:
# The code is SOOOO bad, I don’t even WANT any copyright.
# Just steal it and stop laughing. :-p
Trotzdem war das Script für mich nütlich – zwar nicht perfekt, aber besser als alles selbst schreiben.
Dasselbe gilt für Deine Scripte – auch wenn sie nicht perfekt und nicht besonders schön sind, können sie trotzdem für jemand nützlich sein.
Ohne die Scripte zu kennen, wage ich zu behaupten, dass man mit 2 Stunden Anpassung den Import einer anderen Seite problemlos über die Bühne bekäme.
Zum Vergleich: Wie lange hast Du gebraucht, um die Scripte zu schreiben?
Mein Vorschlag ist nach wie vor: einfach alles “as is” hochladen. Es gibt garantiert noch mehr Leute, die statische Dateien in WordPress importieren wollen. Bestenfalls entwickelt jemand die Scripte zu einem allgemeinen Importfilter für WordPress weiter. Und auch wenn es ganz blöd läuft, hast Du nur ein paar kB Bandbreite und Webspace verschwendet
Also mein alter Feedlink ist ziemlich tot:
Fragt aber bitte nicht, wo ich den her hatte.
Wow… Ne Menge Datenverwaltung habt ihr da gestemmt. Ich bin beeindruckt
danke für den interessanten einblick. ich bin gerade erst auf den relaunch von dr.web aufmerksam geworden. gelungene sache!
Ich würde da auch mal ein gewisses Interesse an dem Import-Script anmelden. Vielleicht gibt es ja eine Möglichkeit weitere Mitstreiter zu finden und ein Plugin daraus zu bauen?
Ich bin mir SEHR sicher, dass dieses Script für viele WordPress-Hoster und Administratoren sehr interessant wäre!