Vermutlich ist es dem einen oder der anderen bereits aufgefallen: In der letzten Zeit ist auf dieser Website des Öfteren von Backdrop CMS die Rede – dem Content-Management-System, das als Fork bzw. Abzweigung von Drupal entstanden ist. Meinen ersten Beitrag zu Backdrop habe ich 2016 geschrieben. Auf der Suche nach Drupal-8-Alternativen für kleinere Webprojekte war ich dort zu dem Schluss gekommen, dass ich neue Websites dieser Art ohne Bedenken mit Backdrop umsetzen würde. Genau das habe ich dann auch getan, und es hat ganz hervorragend geklappt.
Gleichzeitig habe ich begonnen, mich ernsthafter in der Backdrop-Community zu engagieren: Neben der Mitarbeit in der Issue queue auf Github äußerte sich das beispielsweise in der Hilfe beim Aufbau des Backdrop-Übersetzungsservers, in meinen Vorträgen auf dem DrupalCamp Ruhr und dem DrupalCamp München oder in der Portierung des Footnotes-Moduls.
Apropos Backdrop-Module: Meine anfängliche Skepsis, ob die Kapazitäten zu deren Betreuung und Weiterentwicklung ausreichen würden, hat sich nicht bewahrheitet. Viele der wichtigen 'contributed' Drupal-Module, die nicht ohnehin in den Backdrop-Core integriert wurden, sind als eigenständige Projekte portiert worden und werden zuverlässig betreut.
Von Interesse ist der Stand von Core-Integration und Modul-Landschaft nicht nur für die Umsetzung neuer Webprojekte, sondern auch – und damit komme ich zum Thema dieses Beitrags – für das Upgrade einer Drupal-Website auf Backdrop. Weitaus später als erwartet, doch im Grunde schon bald, im November 2021 [Update: mehrfach verschoben, inzwischen auf Januar 2025], wird Drupal 7 sein 'end-of-life' erreichen und nicht mehr mit Sicherheits-Updates versorgt werden.
So langsam wird es also Zeit, darüber nachzudenken, was mit den eigenen D7-Websites und denen meiner Kunden passieren soll. Ein Upgrade auf Backdrop könnte durchaus eine attraktive Option sein. Wenn die Sache auch wirklich funktioniert, versteht sich! Um herauszufinden, ob und wie gut so ein Upgrade läuft, habe ich kürzlich diese Website (olafski.de) von Drupal 7 auf Backdrop aktualisiert, und davon möchte ich nun berichten.
Upgrade-Planung und Vorbereitung
Zunächst stellt sich die Frage, ob ein Upgrade auf Backdrop (1) überhaupt gewünscht und ob es (2) möglich ist. Den ersten Teil der Frage konnte ich positiv beantworten. Meine Motive: Erfahrungen sammeln und die Vorfreude auf meine eigene Website in einem aktuellen System, mit dem ich gerne arbeite. Auch nicht ganz unerheblich: im Gegensatz zu Drupal kann Backdrop seit einiger Zeit über die Benutzeroberfläche aktualisiert werden; das erleichtert vor allem Sicherheitsupdates um einiges.
Auf den zweiten Aspekt – ob ein Upgrade möglich ist – wollte ich es mal ankommen lassen. Ich kenne meine Website ja ganz gut und war optimistisch, dass sie weder zu speziell noch zu komplex ist. Da es um meine eigene Website ging, hatte ich zudem alle Zeit der Welt, und schließlich hatte ich die Möglichkeit, eventuellen Herausforderungen nach eigenem Ermessen zu begegnen.
1. Upgrade vs. Neuentwicklung + Migration
Ist es sinnvoll, eine Drupal-Website in Backdrop neu zu bauen und die Inhalte zu migrieren, anstatt sie auf Backdrop upzugraden? Bei einer Aktualisierung von Drupal 6 oder D7 auf D8 ist Neuentwicklung plus Migration die Regel, zu der es so recht keine Alternative gibt. Der Ansatz hat auch durchaus Vorteile, so lässt sich die möglicherweise veraltete Architektur einer Website mit recht geringem Aufwand auf einen durchdachten, zeitgemäßen Stand bringen. Im Gegenzug müssen Inhalte migriert werden, und diese Aufgabe kann ziemlich komplex sein, denn bei einer Migration müssen nicht nur Seiten und Beiträge, sondern auch Benutzerkonten, Dateien, URL-Aliase oder etwa Inhaltsreferenzen berücksichtigt werden.
Umgekehrt gilt: Bei einem Upgrade bleibt eine nicht optimale Architektur zunächst erhalten, doch dafür wandern neben der Konfiguration auch die Inhalte, und zwar inkl. der Benutzerkonten usw. von selbst ins neue System. Inhalte und Konfiguration eines Upgrades sollten anschließend genau geprüft werden. Meiner Erfahrung nach ist es dabei notwendig und sinnvoll, zumindest kleinere Anpassungen vorzunehmen. Solange es sich nicht um eine sehr alte oder spezielle Website handelt, würde ich ein Upgrade dennoch für weniger aufwendig einschätzen als eine Neuentwicklung plus Migration.
2. Layout und Design
Ein weiterer Aspekt ist bei der Planung eines Upgrades zu beachten: Layout und Design der Website müssen in fast jedem Fall neu entwickelt werden, denn abgesehen vom Evergreen Bartik gibt kaum ein Drupal-Theme, das auf Backdrop portiert wurde. Hintergrund: Im Gegensatz zu Drupal enthalten Backdrop-Themes kein Layout, d.h. Themes sind nur für das Design zuständig; Layouts werden separat verwaltet. Diese Trennung ist eine tolle Verbesserung, sie macht es aber wenig attraktiv, Layout-lastige Themes wie Omega nach Backdrop zu portieren.
Was die Layout-Frage angeht, hält sich die Arbeit nach einem Upgrade zum Glück in Grenzen: Backdrop stellt ein Layout-System zur Verfügung, das sich wunderbar eignet, ein oder mehrere Bootstrap-4-basierte Raster zur Platzierung von Blöcken und anderen Inhalten zu konfigurieren. Fehlt noch das Design, das z.B. als Sub-Theme des Core-Themes Basis erstellt werden kann und im Idealfall nur die eigenen CSS-Definitionen benötigt.
3. Voraussetzungen für das Upgrade
Die Seite Upgrading from Drupal empfiehlt die Prüfung von vier Bereichen einer Drupal-Website, die auf Backdrop aktualisiert werden soll: Theme, Layouts, Contributed-Module und die Core-Funktionalität. In jedem Bereich geht es darum, die Drupal-Site zu analysieren und zu schauen, ob es bereits Lösungen für Backdrop gibt oder ob die Bereitschaft besteht, ein Backdrop-Pendant selbst zu entwickeln:
Über Theme und Layouts habe ich schon kurz gesprochen. Layouts können direkt in Backdrops Benutzeroberfläche konfiguriert werden; sollten die mitgelieferten Vorlagen nicht ausreichen, können eigene Layout-Templates mit geringem Aufwand selbst geschrieben werden. Ein neues Theme erfordert mehr Arbeit, ist meiner Erfahrung nach jedoch ebenfalls gut machbar; darauf gehe ich weiter unten näher ein.
Für jedes Contributed-Modul, das nicht zum Drupal-Kern gehört, sollte zunächst geprüft werden, ob es bereits auf Backdrop portiert oder in den Backdrop-Core integriert wurde. Bei verbreiteten Modulen ist die Chance recht hoch.
Tipp: Seit einiger Zeit werden Upgrade-Instruktionen zu einzelnen Modulen auf den offiziellen Backdrop-Modulseiten gesammelt. Beispiel: https://backdropcms.org/project/admin_menu. Diese Art der Dokumentation ist noch nicht vollständig, der Fortschritt kann im entsprechenden Github-Issue verfolgt werden.
Sollte ein Modul noch nicht portiert oder integriert worden sein, kann es selbst von Drupal 7 zu Backdrop konvertiert werden. Ein Drupal-Kompabilitätslayer und Tools wie Coder Upgrade erleichtern diese Arbeit.
Wenn ein Modul noch nicht für Backdrop zur Verfügung steht und sich auch nicht einfach umwandeln lässt, würde ich erst einmal prüfen, ob es überhaupt noch benötigt wird. Nicht selten ist der Anwendungfall, der von einem Modul bedient wird, gar nicht mehr wirklich gefragt, oder die Sache lässt sich inzwischen besser lösen. Beim Upgrade dieser Website habe ich z.B. auf das TOC-Modul verzichtet, das auf Grundlage von Platzhaltern ein Inhaltsverzeichnis für Drupal-Seiten erstellt. Bei näherer Betrachtung stellte sich heraus, dass ich diese Funktionalität im Lauf von sechs Jahren auf genau einer Seite eingesetzt hatte. (Nachtrag: Inzwischen durch das Tocbot-Modul ersetzt, das ich für Backdrop portiert habe.) Ebenfalls über Bord geworfen habe ich das Name Field, das eine formalisierte, äußerst flexible Erfassung und Ausgabe von Namen – "title, given (first), middle, family (surname), generational suffix and credentials" – erlaubt. Nette Sache, aber ich brauchte eigentlich nur Vor- und Nachname, also Multifield installiert, ca. 100 Beiträge von Hand aktualisiert und weg mit Name Field.
Sollten dann noch Fragen zu Contrib-Modulen offen sein, würde ich die Backdrop-Community um Rat fragen, z.B. über den Gitter-Chat. Die Leute dort können beispielsweise beantworten, wie die Aussichten in Bezug auf größere Schlüsselmodule wie Organic Groups oder Search API ist, die noch gar nicht oder nur versuchsweise portiert wurden. Und bei kleineren Modulen habe ich es durchaus schon erlebt, dass jemand sie direkt nach einer Chat-Diskussion zu Backdrop konvertiert hat.
Der Core von Backdrop ist im Wesentlichen mit Drupal 7 vergleichbar. Durch die aktive Weiterentwicklung bietet Backdrop sogar mehr Funktionalitäten. Dennoch gibt es einige Features, die aus Backdrop-Core entfernt wurden. Darunter befinden sich eher unbedeutende Module wie Overlay, aber auch umfangreichere wie Blog und Forum oder funktional interessante Dinge wie das Trigger-Modul und der PHP-Filter.
Der PHP-Filter sollte unter Sicherheitsaspekten ohnehin nicht mehr eingesetzt werden, und für Trigger gibt es Ersatz in den Contributed-Modulen. Falls ein Blog oder ein Forum im Einsatz ist, wird es eventuell schon kniffliger. Beide Anwendungen können sehr gut mit eigenen Inhaltstypen, Views und kleinen Zusatzmodulen neu gebaut werden, allerdings stellt sich in diesem Fall die Frage der Inhaltsmigration (vgl. Abschnitt Upgrade vs. Neuentwicklung + Migration).
Nicht zu vergessen: Im Gegensatz zu Drupal unterstützt Backdrop nur noch MySQL-/MariaDB-Datenbanken. Genau so eine Datenbank ist ohnehin meistens im Einsatz. In anderen Fällen lässt sich auf den Backdrop-Fork Silkscreen ausweichen, doch das wäre schon eine spezielle Ausgangslage.
4. Zwischenfazit
Im Allgemeinen ist die Ausgangslage für ein Upgrade von Drupal 7 auf Backdrop sehr gut: Die Backdrop-Kernfunktionalitäten stehen denen von Drupal 7 nicht nach, die wichtigsten Module sind portiert, Layouts und Theme lassen sich mit überschaubarem Aufwand einrichten. Ob diese Einschätzung auf die eigene Website zutrifft, sollte in jedem Fall genau geprüft werden. Praktischerweise frischt eine solche Analyse die Kenntnis über die Architektur der Website auf, die wahrscheinlich schon einige Jahre auf dem Buckel hat. Auf dieser Grundlage fühlte ich mich jedenfalls gut vorbereitet, das Upgrade auf Backdrop konkret anzugehen.
Durchführung des Upgrades
Was das weitere Vorgehen angeht, unterscheidet die offizielle Upgrade-Dokumentation zwischen technischer Vorbereitung der Drupal-Website und dem Upgrade im Rahmen einer Backdrop-Instanz. Beides wird Schritt für Schritt erläutert. Beim Upgrade dieser Website fand ich es gleichwohl nicht immer leicht, der Dokumentation zu folgen. Manche Hinweise empfand ich als uneindeutig, andere Punkte waren mir nicht detailliert genug, und nicht alle Informationen, die mich interessiert hätten, werden überhaupt genannt. Davon abgesehen, sah ich das Upgrade als komplexen Prozess vor mir, der zusammenhängende Zeit und Konzentration erfordert.
Als Handlungsfaden habe ich mir eigene Checklisten erstellt, die vielleicht eine Vorstellung davon vermitteln, wie ein Drupal-zu-Backdrop-Upgrade ablaufen kann:
1. Drupal-Website vorbereiten
- Kopie der D7-Site erstellen (nur für das Upgrade)
- Datenbank sichern
- Contrib-Module (1): nicht benötigte Module deinstallieren
- Contrib (2): Module mit unklaren Status klären
- Contrib (3): weiterzuverwendende Module behalten
- Custom-Module => nicht notwendig
- Core und Module auf neueste Version aktualisieren
- Ausgewählte Core-Module deinstallieren
- Themes aktualisieren => nicht notwendig
- Datenbank sichern
- Views in Datenbank speichern => nicht notwendig
- Frontend-Theme auf Bartik umstellen, Blöcke neu platzieren
- Admin-Theme auf Seven umstellen
- files-Vz. sichern => nicht notwendig / in Live-Site vorhanden
- Code sichern => nicht notwendig / in Live-Site vorhanden
- Datenbank sichern, Name enthält "backdrop-ready"
2. Backdrop-Site erstellen und Upgrade durchführen
- Code herunterladen
- Datenbank anlegen
- files-Vz. von Drupal nach Backdrop kopieren
- Datenbank "backdrop-ready" importieren
- settings.php anpassen
- Contrib-Module herunterladen und entpacken
-
NB: Site nicht installieren, stattdessen:
update.php aufrufen
Das war's! Klingt viel einfacher als erwartet? Gut, hinter manchen Punkten verbirgt sich etwas mehr als ein Schritt, und weiter unten führe ich noch eine Vielzahl an Nacharbeiten auf. Der technisch entscheidende und spannendste Moment war gleichwohl der Aufruf der Datei update.php. Die Seite informierte mich über etwa 190 durchzuführende Datenbank-Aktualisierungen, die dann ohne sichtbare Probleme und in beeindruckender Geschwindigkeit durchgeführt wurden.
Bei einem früheren Versuch sah ich nach Aufruf der update.php einige Fehlermeldungen, die mich dazu bewogen hatten, das Ganze noch mal vorne zu beginnen. Die Meldungen hingen u.a. mit dem geänderten files-Verzeichnis zusammen. Inzwischen geht die Upgrade-Dokumentation in Schritt 3.2 genauer auf den Umgang mit dem files-Verzeichnis ein.
Rein technisch betrachtet, war die Drupal-Website damit in eine Backdrop-Website umgewandelt. Was nun folgt, ist eine Reihe weiterer individueller Checklisten, die in Stichworten andeuten, was nach dem technischen Upgrade noch zu tun war.
3. Inhalte prüfen
- Insert-Bilder in Beiträgen via CKEditor ersetzen
- Insert-Felder löschen
- Inhaltstyp "Lektüre": Multifield installieren und Feld mit Vorname + Nachname ergänzen
- Lektüre-Beiträge aktualisieren (neues Feld)
- Neue oder geänderte Beiträge der Drupal-Website übernehmen
- Fotos mit höherer Auflösung verwenden
Bei den Insert-Bildern und beim neuen Multifield-Feld habe ich mich dazu entschieden, die Inhalte in allen Beiträgen manuell zu prüfen und anzupassen. Das ging schneller als nach einer automatisierten Lösung zu suchen.
4. Konfiguration prüfen und anpassen
- Pfade des Dateisystems konfigurieren
- Nicht mehr benötigte Dateien aus files-Verzeichnis löschen
- Backups einrichten
- Patch wg. Umlauten in URL-Aliasen einspielen
- Bestehende Weiterleitungen prüfen, v.a. sites/default/files vs. files
- Funktion zum automatischen Schließen der Kommentare aktivieren
- Views prüfen und anpassen
- Drupal-Blöcke prüfen und anpassen
- Backdrop-Blöcke prüfen und anpassen
- Layouts prüfen und anpassen
- Hauptmenü anpassen (war in Drupal unnötig kompliziert)
- Bildstile prüfen und ergänzen
- Inhaltstyp "Lektüre": Hide path display aktivieren
- Node-Ansichten: Datum anzeigen via template.php (in Drupal via Display Suite)
- Node-Ansichten: Colorbox einrichten
Im Großen und Ganzen war die Konfiguration unproblematisch. Einige Views enthielten aufgrund kleiner Änderungen der Backdrop-Architektur Fehler, die leicht zu beheben waren. Interessant war dagegen eine Datenbankabfrage, die Duplikate enthielt. Auf der Drupal-Website hatte ich zu deren Vermeidung das Modul Views Distinct eingesetzt, das für Backdrop nicht zur Verfügung steht. So war ich motiviert, das Duplikatsproblem durch eine bessere Konfiguration der Abfrage in der Views-Oberfläche zu lösen. Das hat ganz hervorragend geklappt, und zwar durch das Filtern des betroffenen Feldes nach delta (=0).
5. Neues Theme erstellen
- Drupal-Website: Templates prüfen => nicht vorhanden
- Basis-Subtheme erstellen
- Fonts einbinden
- CSS schreiben
- Tabelle "Lektüre" optimieren
- Bessere Menü-Icons neu erstellen
- Favicon usw. kopieren
Zur Gestaltung von Backdrop-Websites habe ich bisher immer ein Sub-Theme des in Backdrop mitgelieferten Basis-Themes erstellt. (Zur Erinnerung: Das Layout-Raster wird nicht vom Theme, sondern vom Backdrop-internen Layout-System gesteuert.) Basis hat 'out of the box' ein nettes, eher neutrales Erscheinungsbild; über eine eigene skin.css lässt es sich gut anpassen.
Bisher hatte ich keine Schwierigkeiten, Design-Vorgaben unterschiedlichen Charakters auf der Grundlage von Basis umzusetzen. So ging es mir auch bei diesem Projekt. Die grobe Nachbildung des bisher in Omega erstellten Drupal-Themes war vergleichsweise schnell erledigt. Allerdings habe ich mich dazu verleiten lassen, etwas Aufwand in das Finetuning des bisherigen Designs zu stecken.
Leider gibt es noch keine offizielle Dokumentation zum Basis-Theme, doch der Hauptentwickler des Themes, Wes Ruvalcaba, hat eine hilfreiche Basis-Anleitung auf Dropbox Paper veröffentlicht.
6. Sonstiges
- Git einrichten, HTTPS und externen Cronjob einrichten
- Launch
- Weiterleitungen prüfen, ggf. neue anlegen
- Dev-Site erstellen und Drupal-Site archivieren
- Beitrag zum Upgrade schreiben √ (erledigt ;-)
Fazit
Mein erstes Upgrade einer Website von Drupal 7 auf Backdrop hat gut geklappt. Technisch war es im Rückblick nicht besonders schwer, doch es hat, wie erwartet, meine volle Konzentration erfordert. Nebenbei hätte ich das Upgrade sicher nicht erfolgreich durchgeführt. Mit genügend Ruhe, einer genauen Vorbereitung sowie Zeit für Qualitätsprüfung und Nacharbeiten lief es aber prima. Mit dem Ergebnis bin ich mehr als zufrieden, und es macht richtig Spaß, auf meiner eigenen Website mit der Backdrop-Oberfläche zu arbeiten.
Eingangs hatte ich die Frage angesprochen, was angesichts des 'end of life' von Drupal 7 mit den von mir betreuten D7-Websites passieren soll. Ich denke, für die Mehrzahl wird ein Upgrade auf Backdrop tatsächlich eine attraktive Option sein. Meiner Einschätzung nach sind etwa 70% der genannten Websites für ein Upgrade auf Backdrop geeignet.
Falls Sie selbst Drupal-7-Websites betreiben, die über das Jahr 2021 hinaus laufen sollen: In meiner Arbeitsgemeinschaft buerobackbord prüfen wir gerne, ob sich Ihre Website auf Backdrop CMS aktualisieren lässt.