Fallstudie: Community-CMS auf Basis Mambo/Joomla 1.5/Joomla 1.0 Legacy-Modus mit Plugins inkrementell in einen zeitgemäßen Zustand überführen

Etwa 1 Million Forenbeiträge, 200.000 Anhänge unterschiedlicher Art, 100.000 Private Nachrichten, 150 Dokumente/Downloads sollten von einem Community-CMS, welches initial als Mambo-CMS installiert, dann auf Joomla 1.5 aktualisiert und aufgrund von Inkompatibilität im Joomla 1.0 Legacy-Modus betrieben wurde, auf einen zeitgemäßen Stand gebracht werden. Das vorgenannte Konstrukt war hierbei etwa 12 Jahre alt und wurde seit mindestens 8 Jahren in keiner Komponente mehr mit Sicherheitsaktualisierungen versorgt.

Indes war der Kunde nicht mehr in der Lage sein Serversystem auf einem aktuellen Stand zu halten, da die alten Softwarekomponenten ihn auf einen sehr spezifischen, alten LAMP-Stack (Linux, Apache, MySQL, PHP) einschränkten. Eine große Menge technischer Schuld, der wir uns in diesem Auftrag annahmen.

Zunächst musste ein vollständiger Abzug der Seite erfolgen. Dieser Abzug sollte in einem mit der alten Laufzeitumgebung vergleichbaren Software-Stand für Testzwecke eingespielt werden. Konkret entfielen die Probleme auf PHP 5.6 (Supportende 12/2018) und MariaDB 10.1 (etwa MySQL 5.5-Equivalent, Supportende 10/2020), der Apache-Webserver war mit Version 2.4 noch vergleichsweise aktuell. Die Laufzeitumgebung war installiert auf einem Debian 9 Serversystem (Supportende 06/2022). Aufgrund des ungleich aktuelleren Softwarestands der Laufzeitumgebung zur eigentlichen Anwendung lag der Verdacht nahe, dass der Kunde mit PHP 5.6 und MySQL 5.5 an das Limit der leicht umzusetzenden Aktualisierungen stieß.

Die Testumgebung wurde bewusst mit Debian 9 aufgesetzt, wir mussten jedoch feststellen, dass aufgrund der schlechten Verfügbarkeit von vorgefertigten PHP 5.6-Softwarepaketen für diese Distribution ein sofortiges Upgrade auf Debian 10, gefolgt von der Installation von MariaDB 10.1 und PHP 5.6 die effektivste und zeiteffizienteste Methode darstellen sollte.

Im Anschluss an die Verifizierung der funktionstüchtigen Testumgebung wurde die Dateien sowie Datenbank des Joomla-CMS importiert und die importierte Applikation auf ihre Funktion getestet. Erfahrungsgemäß ist hier stets mit mehreren, einfachen Anpassungen (meist Einstellungen oder Nachinstallation von PHP-Modulen wie „xml“, „mbstrings“, „mysqli“) zu rechnen.

Mit funktionstüchtiger Testumgebung war es uns nun möglich, eine ganzheitliche und tiefgründige Inventur der Webapplikation durchzuführen, das hieß:

• Templates identifizieren
• Plugins identifizieren
• sämtliche Versionsstände von Templates und Plugins verifizieren
• zu migrierende Daten feststellen
  • Privatnachrichten (Plugin uddeIM)
  • Forenbeiträge und Kategorien (Plugin Kunena)
  • Beiträge im CMS
  • Dokumente/Downloads (Plugin DOCman)
  • Menüs
  • Anhänge aus Beiträgen und Forenbeiträgen
  • Userprofile (Plugin Community Builder)

Nun konnte mit den inkrementellen Updates begonnen werden.

In Schritt 1 musste erörtert werden, wie der 1.0 Legacy-Modus von Joomla deaktiviert werden konnte ohne die Joomla-Installation zu beeinflussen. Der 1.0 Legacy-Modus stellt eine Kompatibilitätsschicht dar, welche es ermöglichte, das alte Mambo oder Joomla 1.0-CMS auf Joomla 1.5 zu aktualisieren und alte Templates sowie Plugins weiterzuverwenden ohne diese tiefgehender anzupassen. Seinerzeit war dies eine beliebte Methode um den Übergang von Mambo oder Joomla 1.0 auf 1.5 zu erleichtern, sollte jedoch immer nur als Provisorium gesehen werden. Schnell zeichnete sich ab, dass das alte Mambo-Template des Kunden keine Joomla 1.5-Kompatibilität bot.

Nun wurden der Reihe nach die Plugins und Joomla-Versionen durchaktualisiert. Es folgt eine sehr vereinfachte Zusammenfassung der Schritte:

• Kunena 1.5 auf 1.6 aktualisiert
• Kunena 1.6 auf 1.7 aktualisiert
• alte Module und Templates entfernt
• 1.0 Legacy-Modus deaktiviert
• Kunena 1.7 auf 2.0 aktualisiert
• Joomla 2.5 Instanz aufgesetzt
• Daten von Joomla 1.5 nach 2.5 migriert
• Kunena 4.0 installiert, Daten migriert
• uddeIM 2.8 installiert, Daten migriert
• uddeIM 2.8 auf 4.0 aktualisiert
• Community Builder 2.0 installiert, Daten migriert
• Joomla 2.5 auf 3.5 aktualisiert
• uddeIM 4.0 J2.5 auf 4.0 J3.0+ aktualisiert
• Joomla 3.5 auf 3.6 aktualisiert
• Joomla 3.6 auf 3.10 aktualisiert
• Community Builder 2.0 auf 2.4 aktualisiert
• uddeIM Privatnachrichten nach Community Builder PMS migriert
• PHP 5.6 auf 7.0 aktualisiert
• Kunena 4.0 auf 5.2 aktualisiert
• PHP 7.0 auf 7.4 aktualisiert
• Community Builder 2.4 auf 2.7 aktualisiert
• Kunena 5.2 auf 6.0 aktualisiert
• Joomla 3.10 auf 4.2 aktualisiert
• Debian 10 auf 11 aktualisiert
• MariaDB 10.1 auf 10.10 aktualisiert
• PHP 7.4 auf 8.0 aktualisiert

Auch das Dokumenten/Download-Management-Tool (DOCman) bedürfte noch einer Migration, jedoch wurde das Plugin im Laufe der Zeit kostenpflichtig. Der Kunde hat hier die Entscheidungsgewalt ob er eine Migration der ca. 150 Dokumente/Downloads in eine aktuelle DOCman-Version (verbunden mit einem 100$/Jahr Abonnement des Plugins in aktueller Variante) wünscht oder auf ein Alternativplugin zurückgreifen möchte. Bei letzterer Variante wäre eine automatisierte Migration der Daten durch ein selbsterstelltes Hilfsplugin aufgrund der geringen Menge an Datensätzen (150) wenig sinnvoll, hier würde dann ein manueller Übertrag in das neue Plugin erfolgen.

An diesem Punkt (etwa 65 Snapshots/Sicherungspunkte später) war die Machbarkeit in der Praxis bestätigt und alle notwenden Informationen gesammelt. Für den Kunden werden diese auf einem Updateplan, ähnlich eines Reparaturplans aufbereitet. Periphere Aufgaben wie die Erstellung eines neuen Templates verbleiben.

Die durch uns erstellte Testinstanz wird nun dem Kunden für grundlegende Akzeptanztests zur Verfügung gestellt und auftretende Probleme beseitigt. Im Anschluss wird ein den gesammelten Erfahrungen und Informationen entsprechendes Update in der Produktion geplant und umgesetzt werden.