Seite auswählen

Warum ich 2016 von Drupal zu WordPress gewechselt bin. Es folgt eher eine Erläuterung meines Entscheidungsprozesses als ein faktischer Vergleich zwischen den beiden Systemen Drupal und WordPress.

Anmerkung: Ich hatte diesen Text vergessen und jetzt erst erst wieder entdeckt. So kommt es zu einer um etwa zwei Jahre verspäteten Veröffentlichung.

¯\_(ツ)_/¯

Ich habe mich bereits seit 2007 mit Drupal als Alternative zu WordPress beschäftigt und hatte zeitweise diesen Blog auf Drupal umgestellt, auch wenn das nicht von Dauer war. Deshalb hatte ich auch einige Artikel zu Drupal verfasst. Ende 2007 war es soweit, dass wir unsere Firmenhomepage von statischen HTML Seiten auf ein CMS umstellen wollten (eigentlich sollte das schon lange vorher geschehen, aber wie das so ist … Prioritäten).

Wenn schon CMS, dann aber auch automatisch

Ein mir sehr wichtiger Punkt war die automatische Anzeige unserer Seminare und auch der dazugehörigen Seminartermine. Die damals vorhandenen Event Kalender Plugins für WordPress, die solche Funktionen bereitstellten entsprachen alle nicht unseren Vorstellungen.

Schwerpunktmäßig wurden Termine in hässlichen Monatskalenderseiten angezeigt und auch die Koppelung eines Seminarthemas (Event) mit mehreren mehrtätigen Terminen über das Jahr verteilt ist sogar heute noch in solchen Plugins in der Regel nicht vorgesehen. Offenbar benötigen die meisten Websitebetreiber nur Einzelevents oder Events mit klarem Rhythmus (alle vier Wochen).

Das CCK und Views Modul

Der große Vorteil von Drupal, damals in der Version 4.x gegenüber WordPress Version 2.x war für unseren Bedarf zwei kostenfreie Drupal Module (entspricht den Plugins bei WordPress) für die es keine Entsprechung bei WordPress gab. Einerseits das Content Construction Kit (CCK) und Views.

CCK stellt die mittlerweile auch unter WordPress verfügbaren Custom Post Types und Custom Fields zur Verfügung. Nicht nur das, sondern diese Funktionen ließen sich über eine zwar nicht sonderlich hübsche aber visuelle Benutzeroberfläche im Backend von Drupal einrichten, sprich Zusammenklicken.

Eigene Seminar Content Types in 2008

Da ich nur rudimentäre PHP und Programmierkenntnisse besitze war das natürlich der Bringer.

Ich konnte ein Content Type „Seminarthemen“ erstellen in dem ich unsere Seminarausschreibung unterbrachte und diesem Content Type, dann Custom Fields mit den Seminarterminen anfügen. Daraus ließen sich dann mittels des Views Moduls automatische Listen anfertigen wie z.B. alle Seminarthemen A-Z.

Einer unserer wichtigsten Ziele für die Website, eine Terminübersicht unserer Seminare als Liste, die automatisch immer erst ab dem nächsten kommenden Termin aufgelistet wurde und keine früher im Jahr bereits gelaufene Termine anzeigte, war ebenfalls mit dem Views Modul zu erstellen. Genauso wie eine kurze Liste der nächsten drei kommenden Seminare für die Sidebar.

Das war mit WordPress in 2008 einfach nicht möglich, zumindest mir nicht ohne Unterstützung eines Programmierers und vermutlich einer Menge Geld.

2008 bis 2015: Was passierte dann?

Nachdem ich Anfang 2008 unser Firmenhomepage von statischem HTML auf Drupal umstellen konnte, habe ich jahrelang nicht viel tun müssen, außer jährlich die neuen Seminartermine einzupflegen und regelmäßige Updates zu machen.

Die Unterstützung von Custom Post Types und Fields kam für WordPress mit der Version 3, die erst am 17. Juni 2010 veröffentlich wurde. Auch wenn die Funktion nun vorhanden war, gab es keine graphische Oberfläche für den Umgang mit diesen Funktionen. Es dauerte etwas bis die ersten Plugins hier nachhalfen, aber bis heute gibt es zwar einige Plugins, die einem beim Erstellen und Umgang mit Custom Post Types und Fields unterstützen, aber keine so umfassende und vor allem kostenlose Lösung wie unter Drupal.

Die Umstellung von Drupal 5 auf Drupal 6 hatte ich so lange herausgezögert bis mit dem Erscheinen von Drupal 7 Anfang 2011 der Support von Drupal 6 endete. Insgesamt war durch die Änderungen doch ein wenig Arbeit nötig, um alles wieder wie gewünscht laufen zu lassen.

In 2014 kam ich endlich dazu mit Filemaker eine eigene interne Datenbank auf unserem Rechner für unsere Seminarangebote zu entwickeln, aus der ich nach Eintragen der neuen Seminartermine einen CSV-Export zum Einlesen für die verschiedenen online Seminardatenbanken, die wir nutzen, erstellen konnte. Natürlich wollte ich dies auch für unsere Homepage nutzen und nach ein wenig Recherche fand ich einen Weg die Daten in Drupal zu importieren, so dass die mühsamen manuellen Eintragungen ein Ende hatten.

Fast Forward 2016: Drupal 8 erscheint & Drupal 6 Support endet

Ende 2015 wurde klar, dass mit dem offiziellen Release von Drupal 8 auch der Support von Drupal 6 endet. Hinzu kam, dass das Layout unserer Homepage hoffnungslos veraltet war und wir dringend eine visuelle Renovierung mit neuen Tapeten benötigten.

Zunächst erstellte ich eine lokale Entwicklungumgebung, um das Update auf Drupal 7 zu testen. Auch bei diesem Versionssprung gab es wieder einige grundsätzliche Änderungen, die einiger Nacharbeit bedurften. So mussten einige der Custom Fields in ein neues Format migriert werden. Letztendlich hatte ich das hinbekommen. Testweise versuchte ich mich auch gleich nochmal im Sprung auf Drupal 8, was auch klappte, aber hier stellte ich fest, dass einfach noch zu viele von uns genutzten Module nicht für Drupal 8 verfügbar waren.

Tapetensuche: ein neues Theme muss her

Jetzt wurde es wieder kniffelig. Wir mussten ein Theme finden, dass uns beiden gefällt und dass ich entsprechend anpassen wollte. Die Auswahl an Drupal Themes ist zwar lange nicht so umfangreich wie bei WordPress, aber mittlerweile auch nicht schlecht.

Wir wurden bei dem Glazed Theme von Jurriaan Roelofs fündig. Ich kaufte eine Lizenz und versuchte mich in meiner lokalen Entwicklungsumgebung an der Installation und scheiterte zunächst völlig. Der Entwickler stellt für das Theme ein komplettes angepasstes Drupal Installationspaket zur Verfügung mit dem man eine neue Drupalinstallation mit dem Theme und allen nötigen Einstellungen erhält. Das habe ich dann als Zweites ausprobiert und es funktionierte. Aber ich hatte ja eine vorhandene Drupal Installation und wollte nur das Theme dazu haben. Offenbar beruhten einige Funktionen des Themes auf Modulen, die mir fehlten.

Ich habe dann einfach in dem Installationspaket recherchiert welche zusätzlichen Module dort vorhanden waren und diese dann auch in meiner lokalen Homepageversion installiert. Das half schon und die Seite lief nun mit dem neuen Theme.

Ich muss an dieser Stelle nochmal den Support von Jurriaan Roelofs loben, denn der hat sich wirklich Mühe gegeben mich bei meinen Problemen zu unterstützen und sein Glazed Theme braucht sich nicht vor den beliebten WordPress Themes wie z.B. Divi oder Avada verstecken. Es ist sogar ein Page Builder integriert.

Aber leider stieß ich auf weitere von dem Theme unabhängige Hindernisse.

Hindernisse: Schön, aber schade, wenn sich nichts bearbeiten lässt

Ich stellte plötzlich fest, dass ich keinerlei Inhalte mehr bearbeiten konnte. Immer wenn ich auf „Inhalte editieren“ ging, wurde mir ein Fehler im Views Modul angezeigt. Nach langen Herumtesten und Recherchieren konnte ich das Problem so weit eingrenzen, dass es wohl mit der Migration der Custom Fields zu tun hatte. Ich befürchtete, dass ich das Problem schon mit dem Update auf Drupal 7 herbeigeführt und nur nicht bemerkt hatte.

Schnell ein Backup wieder eingespielt und siehe da, nach dem Update von Drupal 6 auf 7 funktionierte alles einwandfrei. Aber was nun? Ich prüfte und werkelte noch ein wenig an den migrierten Custom Fields herum, aber war mir nicht sicher wo das Problem lag.

The Return of WordPress

Ich hatte fast zeitgleich die kleine WordPress Homepage meiner Mutter von einem Hosting Dienst auf meinen Server umgezogen und dabei mit Hilfe des sehr funktionalen Divi Themes auch optisch aufgehübscht. Bei meiner Recherche und in einem Gespräch mit Frank wurde ich auf das unter wp-types.com vertriebene Pluginset „Toolset“ aufmerksam wurde. Toolset bietet mit den enthaltenen Plugins „Toolset Types“ und „Toolset Views“ im Grunde fast die gleiche Funktionalität wie es die Module „CCK“ und „Views“ es unter Drupal tun.

Insofern hatte ich mir schon vorher die Frage gestellt, ob ich mit unserer Firmenhomepage nicht doch auf WordPress wechseln sollte. Die Vorteile wären aus meiner Sicht:

  • Ich kenne mich mit WordPress gut aus.
  • Ich betreibe oder pflege mehrere WordPress Seiten und müsste mich dann nicht um zwei verschiedene Systeme kümmern.
  • Ich kann mich tiefer in WordPress einarbeiten, da ich keine zusätzliche Zeit für die Pflege und den Umgang mit Drupal benötige.
  • Mit der Überarbeitung unserer Homepage, sollte ein Blog dazukommen. Das geht zwar auch mit Drupal, ist aber einfacher mit WordPress einzurichten.
  • Die Verfügbarkeit an Informationen ist zu WordPress aufgrund der hohen Verbreitung gewaltig, obwohl ich bisher bei Drupal auch stets fündig geworden bin.

Ich hatte mich aber aufgrund des zu erwartenden Aufwandes bei einem Systemwechsel von Drupal zu WordPress gegen die Umstellung entschieden. In Drupal war alles eingerichtet und es müsste nur ein Update erledigt werden und ein neues Theme implementiert werden.

Stop: Umdrehen, alles neu!

Nachdem ich mit meinem Versuch genau dies umzusetzen schon einiges an Zeit investiert hatte, nicht erfolgreich war und gerade auch etwas ratlos wie ich meine Probleme mit Drupal lösen könnte, kam ich zu der Erkenntnis, dass eine Neubewertung der Situation nötig ist.

Ich konnte nicht sicher sein wie viel weitere Zeit ich in die Lösung meiner Drupal und Themeprobleme stecken müsste. Ich entschied, dass ich nun doch den Wechsel auf WordPress angehen würde. Vielleicht hätte ich weniger Zeit für meinen Drupalweg benötigt, aber das konnte ich im Voraus nicht abschätzen und so sicherte ich die o.g. Vorteile für mich.

Ich habe natürlich auch auf dem Weg der Umstellung einige Hürden nehmen müssen, aber ich bin bald fertig und denke, dass es die richtige Entscheidung war.

Fazit: WordPress ist Klasse … Drupal aber auch

Auch wenn ich ein wenig wehmütig auf Drupal zurückblicke, denn es ist ein tolles CMS, dass mir viel möglich gemacht hat und auch die deutsche Community ist stets sehr hilfsbereit gewesen.

Insofern will ich definitiv nicht die Botschaft verkünden, dass WordPress besser als Drupal wäre. Überhaupt ist aus meiner Sicht ein solcher Vergleich und global gefälltes Urteil totaler Unsinn. Wie immer kommt es auf die Umstände an!