Migrationsgeschichte: FastpublishCMS → WebEdition

Historisch

Dieses Kapitel beschreibt den abgeschlossenen Migrationsprozess von 2020–2025. Dokumentiert von Florian Henze (M.Sc.), erstellt ab 10.12.2020, letzte Aktualisierung 30.09.2025.

Einleitung

Nach der erfolgreichen Fertigstellung des Redesigns des öffentlichen Bereichs von sachpool.de, dem Aufbau des CMS und der Grundlagen des Login-Bereichs war der nächste Schritt die Übernahme von Funktionen und Tools des etablierten Portals der-sachpool.net.

Die Migration des bewährten, internen Bereichs mit seinen Tools, Inhalten, Dokumenten und Funktionen auf die neue Plattform sachpool.de erforderte:

• Refactoring aller PHP-Module von PHP 5.x auf PHP 7.3+
• Ablösung des FastpublishCMS durch WebEdition
• Entwicklung neuer Schnittstellen (Authentifizierung, Linking, Modulkapselung)
• Anpassung an zeitgemäßere technische Grundlagen und Designs

Das Ausmaß der Portierungsaufgabe war zunächst deutlich unterschätzt worden. Ein gewachsenes System mit individuellen Anpassungen auf hunderten Skripten, in einem seit 2006 nicht mehr weiterentwickelten CMS, ohne Dokumentation, basierend auf veralteten Standards – ist keineswegs trivial zu portieren.

Problemstellung

Das gewachsene System (15 Jahre FastpublishCMS) hatte folgende Hauptprobleme:

• Sicherheitslücken im FastpublishCMS: Remote File Inclusion, Privilege Escalation (CVE vuldb.com/de/?id.40016, CVE vuldb.com/de/?id.30545)
• Keine Dokumentation mehr für das alte CMS verfügbar
• Urheberrechtlich geschützter Quellcode – keine Portierung des CMS-Kerns möglich
• Starke Kopplung aller Module an FastpublishCMS-Interna
• PHP 5 mysql-Befehlssatz in PHP 7 nicht mehr vorhanden
• Unzählige Teilmodule höchstspezifisch auf die alte Plattform entwickelt, teilweise mit spezifischen Authentifizierungseigenheiten einzelner Versicherungspartner
• Viele Anforderungen nur als einzeilige Arbeitsanweisungen dokumentiert, ohne strukturierte Aufschlüsselung (Rechtezuweisungen, Referenzen, Dynamische Parameter)

Ausgangssituation

Der öffentliche Bereich von sachpool.de wurde von Webentwickler Ramón Dollase aufgebaut und legte alle Grundlagen für weitere Module auf der WebEdition-Plattform.

Die technische Analyse, PHP-Migration und Portierung der internen Funktionen wurde an Florian Henze (M.Sc.) übergeben. Zunächst nur für die Vertragsauskunft beauftragt, zeigte sich die hohe Kopplung und Reichweite ausstehender Aufgaben schnell als erheblich komplexer als ursprünglich skizziert.

WebEdition als Zielplattform

sachpool.de basiert auf WebEdition – einem Open-Source-Webapplication-Framework aus Deutschland, das sich in kontinuierlicher Weiterentwicklung befindet und hochangepasste Webapplikationen erlaubt.

Ausschlaggebende Vorteile für die Migration:

• Komplexes Backend-Dateimanagement – Assets behalten bei Verschiebung ihre Verweise (dynamisches Linking)
• Klassen→Objekt-Relationen – zentrale Pflege von Ansprechpartnern, Versicherungen, Listen etc. mit komplexen Verknüpfungen und Abhängigkeiten
• Nutzer- und Rechteverwaltung – Kundenmanagement-Modul für den internen Bereich, konfigurierbar nach Rollen und Referenzen
• Templateengine – verbindet Frontend-Auszeichnungssprachen mit PHP-Backend und eigener Entwicklung; hervorragende Basis für modulare Architektur
• Backend-Datenbankzugriff – konfigurierbar nach Backend-Nutzern und Rechte-Management

WebEdition bietet damit hervorragende Voraussetzungen für eine wachsende Plattform nach stark modularem Charakter.

Datenanbindung (Extranetportal-Datenbank)

Die Datenbanktabellen des Extranetportals (der-sachpool.net) und die WebEdition-internen Datenbanken wurden in derselben Datenbankinstanz zusammengeführt. Das Extranetportal wird von Sachpool-Seite regelmäßig in das WebEdition-Projekt gespiegelt.

Diese gemeinsame Instanz ist entscheidend, weil:

• Der direkte Austausch und Zugriff zwischen beiden Kontexten so möglich ist
• Für die Authentifizierung der Abgleich bestimmter Kontexte und Referenzen unbedingt erforderlich ist (Kundendaten ↔ Vermittler-Nummer, Makler-Zugehörigkeit etc.)

Bisherige Zugriffsarten:

• WebEdition-interne Datenbanken: durch Framework/Backend direkt, nicht frei konfigurierbar
• Extranetportal-Skripte: direkter Zugriff über den PHP5-mysql-Befehlssatz – in PHP 7 komplett entfernt, daher nicht mehr ausführbar ohne Refactoring

Einbettung der Kontexte

Database-Layer

Als erster Schritt wurde WebEdition dazu gebracht, die Datenbankverbindung als Standard-mysqli-Objekt zur Verfügung zu stellen:

$db = new DB_WE();
$result = $db->query($query);
$row = mysqli_fetch_assoc($result);

Damit konnten portierte Skripte direkt auf die Datenbank zugreifen, ohne eigene Verbindungskonfiguration, ohne zusätzliche Abhängigkeiten und ohne separate Kontexte oder Mehrfachverbindungen. (Mehr Details → PHP 5 → 7 Migration)

Kundenmanagement / Authentication

Das WebEdition-Kundenmanagement übernahm die primäre Authentifizierung und den Login des internen Bereichs. Entscheidend: Verbindung der WebEdition-Kundendaten mit den Feldern aus dem Extranetportal:

• PERS_ID – interne Personen-ID
• OWNER / PORTAL_ID – Makler-Zugehörigkeit
• UEBERMAKLER, SIEHT_UNTERVERMITTLER – Hierarchie-Referenzen

Über den eigentlichen Login hinaus sind Zugänge zu Dokumenten, Funktionen und Bereichen an diese Felder gekoppelt. Eine Abstraktionsschicht macht beide Kontexte kompatibel. → Siehe Authentifizierungslayer

Vorrecherche der-sachpool.net

Outdated Codebase

• Tabellen-Layouts, veraltete HTML-Standards (HTML 4.01 Transitional)
• Browser-Workarounds für Browser mit <0,1% Marktanteil
• PHP 5 mysql-Befehlssatz (in PHP 7 entfernt)
• Hartkodierte Pfade in hunderten Skripten
• Mehrfachdeklarationen von Funktionen
• @-Operatoren zur Fehlerunterdrückung statt eigener Fehlerbehandlung
• Ausgabe höchstspezifisch auf internen FastpublishCMS-Seitenkontext bezogen

Probleme mit FastpublishCMS

• Seit 2006 keine Weiterentwicklung
• Sicherheitslücken: Remote File Inclusion, Privilege Escalation (K.O.-Kriterium)
• Keine verfügbare Dokumentation mehr
• Quellcode urheberrechtlich geschützt – keine Modifikation oder Portierung des CMS-Kerns erlaubt

Kopplung und Abhängigkeiten

Die meisten Seiten und Skripte erzeugten ihren Output nur im FastpublishCMS-Seitenkontext und waren tief mit dem CMS verzahnt. Daraus ergab sich die Notwendigkeit für:

• Link-Modul – dynamisches Linking außerhalb des CMS
• Authentifizierungslayer – Ablösung vom FastpublishCMS-Login
• Modulkapselung/Anwendungsfenster – kontextfreier Betrieb portierter Module

Skript-Output-Kontexte

Die Abhängigkeit vom FastpublishCMS-Seitenkontext führte zu weiteren Problemen bei der Übernahme alter Skripte, unabhängig von der PHP-Migration:

• Der alte Seitenkontext ist auf der neuen Plattform nicht mehr verfügbar
• Ausgaben bestimmter Teilbereiche müssen zu einem DOM-vollständigen Kontext gewrappt werden (für JavaScript-Kompatibilität und Vermeidung von Seiteneffekten)
• HTML 4.01 Transitional enthält Deklarationen die mit dem neuen HTML5-Standard inkompatibel sind
• Zeichensatz: Bisher ISO-8859-1 und teils ANSI/CP-1252 verwendet – das neue Portal ist vollständig UTF-8. Zeichensätze wurden gemischt und müssen konsolidiert werden
• <head>- und <body>-Bereiche wurden teils nicht respektiert und Seitenkontexte gemischt

Alle Skripte wurden auf UTF-8 portiert, utf8_encode() entfällt.

→ PHP-spezifische Migrationsdetails: PHP 5 → 7 Migration

Bugs WebEdition 8.0 → 8.0.6

Der Template-Parser von WebEdition 8.0 hatte Bugs bei IfWebEdition/IfNotWebEdition, die dazu führten, dass Inhalte nicht korrekt ausgeklammert wurden. Änderungen am Master-Template waren häufig nur mit großem Timeout oder gar nicht speicherbar. Update auf 8.0.6 hat dies behoben.

Außerdem: ifVarNot war als deprecated markiert und führte zu exzessiven Warnungen im Fehlerlog → Umstellung auf einheitliche ifNot...-Nomenklatur.

Lessons Learned: Prototyp Vertragsauskunft

Als erster Prototyp für das Migrationsvorgehen zeigte die Vertragsauskunft:

• Kapselung des alten Seitenkontexts in einem Anwendungsfenster möglich ✓
• Datenbankabfragen aus portiertem Code funktionieren ✓
• drucken2.php hat zentrale Rolle bei URL-Generierung – stark FastpublishCMS-abhängig, muss durch das Link-Modul ersetzt werden
• Eine vollständige Weiterentwicklung war erst nach Fertigstellung der Grundmodule sinnvoll (Authentifizierungslayer, Link-Modul, Modulkapselung)

Alle Grundprinzipien der Migration wurden anhand der Vertragsauskunft entwickelt und erprobt. → Detailbericht: Portierung Vertragsauskunft