Exponential 6 und Exponential Platform Legacy #

Exponential Platform Legacy (se7enxweb/exponential-platform-legacy) betreibt den Kernel von Exponential 6 und eine Symfony-Plattform auf einer Datenbank, verbunden durch se7enxweb/legacy-bridge. Es ist der schonendste Weg, einer Exponential-6-Site den Symfony-Stack zu geben: Die Inhalte, die Legacy-Administration, die TPL-Templates und die Extensions arbeiten weiter, während Twig-Templates, REST v2 und die Plattform-Administration hinzukommen. Und weil auf der Legacy-Seite nichts entfernt wird, ist der Rückweg kurz.

Übersicht Migration · Checkliste · Das eigene Handbuch des Produkts: Exponential Platform Legacy, Kapitel 11: Migration nach Exponential Platform Legacy

Inhalt #

• 1. Die Release-Linien
• 2. Ist es das richtige Ziel?
• 3. Von Exponential 6 zu Platform Legacy
• 4. Wechsel auf eine neuere Linie
• 5. Von Platform Legacy zurück zu Exponential 6 allein
• 6. Prüfen
• 7. Rückweg
• 8. Risiken
• 9. Checkliste

1. Die Release-Linien #

Ausgelesen aus der composer.json jedes Release-Tags am 2026-10-18 (Übersicht, 1.2):

Warnung v5.0.3 enthält die composer.json der Linie 2.5. Für v5 fordern Sie ~5.0.3.1 an (so macht es auch die README des Produkts: composer create-project se7enxweb/exponential-platform-legacy:~5.0.3.1), niemals ein bloßes ^5.0.

Eine sofort lauffähige Variante der Linie v5 ist se7enxweb/exponential-platform-legacy-starter (1.0.0.0).

2. Ist es das richtige Ziel? #

Was sich für die Site ändert, wenn der Symfony-Stack sie ausliefert:

• Symfony beantwortet die Anfragen; die Legacy-Siteaccesses werden über die Bridge erreicht (legacy_mode: true). Velocity, das Exponential 6 allein ausliefert, ist nicht der Server eines Platform-Legacy-Projekts.
• Die Zugangsdaten der Datenbank stehen nur in der Konfiguration von Symfony; die Bridge reicht sie an den Legacy-Kernel weiter.
• Bild-Aliase kommen aus den YAML-Bildvarianten; Aliase, die nur in image.ini stehen, müssen dort deklariert werden.
• Die Anmeldung an Nicht-Legacy-Siteaccesses übernimmt Symfony. Beide Kernel lesen die Legacy-Passwort-Hashes, aber Plattform-Generationen ab 3.0 akzeptieren nur die Typen 6 und 7 (17.7).
• Datenbank-Engines: Die Plattformseite unterstützt MySQL/MariaDB und PostgreSQL; SQLite wird im Schnellstart von v5 für die Entwicklung angeboten. MongoDB und Oracle, die Exponential 6 unterstützt, sind keine Engines der Plattform: Ziehen Sie eine solche Site zuerst auf MySQL, MariaDB oder PostgreSQL um (Datenbanken).

3. Von Exponential 6 zu Platform Legacy #

Eine Exponential-6-Datenbank ist eine Legacy-Datenbank, die den Schritt 5.4 der alten Kette bereits hinter sich hat; Sie folgen also Kapitel 11.3 des Produkts ohne dessen Legacy-Update-Kette.

Landen Sie zuerst auf der Linie 2.5. Das Handbuch des Produkts: Das Plattformschema von 2.5 „ist das vollständige Legacy-Schema“, es fehlt also nichts, was die Legacy-Site verwendet; steigen Sie danach Linie für Linie auf (4).

1. Frieren Sie ein und sichern Sie die Datenbank und var/<site>/storage. Spielen Sie die Sicherung einmal auf einem Testrechner zurück.
2. Bringen Sie Exponential 6 auf sein neuestes Release (Kapitel 11.6) und prüfen Sie die Versionszeilen (11.2).
3. Stellen Sie unter MySQL die Tabellen auf utf8mb4 um. Der Plattform-Kernel 2.5 legt utf8mb4-Tabellen an, und das Legacy-Override der Distribution spricht utf8mb4 mit dem Server; Kapitel 11.3 des Produkts enthält die Abfrage, die die Anweisungen ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 zum Prüfen und Ausführen ausgibt.
4. Wenden Sie die Update-Dateien des Plattform-Kernels 2.5 an, aus vendor/se7enxweb/ezpublish-kernel/data/update/<engine>/, in der Reihenfolge, die Kapitel 11.3, Schritt 3, des Produkts angibt. Auf einer Exponential-6-Datenbank ist das meiste, was sie tun (das breitere password_hash, ezcontentobject_trash.trashed, die Sequenznamen unter PostgreSQL), bereits vorhanden; Kapitel 10.7 des Produkts erklärt, welche Anweisungen gefahrlos wiederholt werden können. Führen Sie sie auf der Kopie aus und lesen Sie jeden Fehler: Ein „duplicate column“ bedeutet, dass die Änderung bereits vorhanden ist; alles andere stoppt die Migration.
5. Legen Sie die Tabellen an, die der Kernel 2.5 erwartet und die einer reinen Legacy-Datenbank fehlen (zum Beispiel ezcontentclass_attribute_ml, eznotification): Vergleichen Sie Ihre Tabellenliste mit data/mysql/schema.sql des installierten se7enxweb/ezpublish-kernel und legen Sie die fehlenden aus dieser Datei an (Kapitel 16.6.1 enthält den Vergleich).
6. Legen Sie das 2.5-Projekt mit einer ausdrücklich angegebenen Version an und richten Sie es auf die migrierte Datenbank aus, ohne den Installer auszuführen: Das Handbuch des Produkts warnt, dass ezplatform:install / exponential:install die Tabellen, die sie kennen, löschen und neu anlegen.
7. Verschieben Sie den Speicher nach ezpublish_legacy/var/<site>/storage (oder in das Verzeichnis, das Ihr VarDir nennt).
8. Verschieben Sie die Legacy-Konfiguration: settings/override/ nach ezpublish_legacy/settings/override/, die Siteaccess-Verzeichnisse nach ezpublish_legacy/settings/siteaccess/, und entfernen Sie die Verbindungswerte aus [DatabaseSettings].
9. Deklarieren Sie die Siteaccesses in YAML mit denselben Namen; die Legacy-Siteaccesses erhalten legacy_mode: true. Deklarieren Sie jeden Bild-Alias, den die Legacy-Designs verwenden, als Bildvariante.
10. Verschieben Sie Ihre Extensions in das Projekt und aktivieren Sie sie; erzeugen Sie die Autoloads über die Bridge neu (php bin/console ezpublish:legacy:script bin/php/ezpgenerateautoloads.php).
11. Prüfen Sie das Schema mit ezsqldiff.php, zuerst das Referenzschema und dann Ihre Datenbank (Kapitel 11.3, Schritt 10, des Produkts und das Nexus-Handbuch, 12.4 erklären die Reihenfolge der Argumente). DROP-Zeilen für Tabellen, die nur die Plattform hat, sind zu erwarten.
12. Lassen Sie den Legacy-Cron über die Bridge laufen, leeren Sie die Caches beider Seiten, indizieren Sie neu und prüfen Sie (6).

Was nicht umziehen muss: Die Inhalte, die Klassen, die Benutzer, Rollen, Sektionen, Zustände, URL-Aliase und die Daten von Exponential Layouts bleiben in der gemeinsamen Datenbank und werden von der Legacy-Seite wie bisher gelesen.

4. Wechsel auf eine neuere Linie #

Wechseln Sie jeweils um eine Linie, mit Kapitel 10 des Produkts (Upgrade zwischen Release-Linien):

Jeder Linienwechsel ändert auch Projektstruktur und Konfiguration (zum Beispiel app/config zu config/, web/ zu public/ von 2.5 auf 3.x); das Kapitel des Produkts führt diese Änderungen auf.

5. Von Platform Legacy zurück zu Exponential 6 allein #

Die Legacy-Hälfte ist eine vollständige Exponential-6-Installation; zurückzugehen heißt, sie die Site wieder ausliefern zu lassen.

1. Sichern Sie die gemeinsame Datenbank und den Speicher.
2. Entscheiden Sie, was mit reinen Symfony-Inhalten geschieht. RichText-Felder, Exponential Layouts oder andere reine Plattformdaten haben keine eigene Darstellung auf der Legacy-Seite: Listen Sie die verwendeten Feldtypen auf und prüfen Sie sie anhand von Kapitel 16.6.3.
3. Bei einer v5-Datenbank machen Sie die Umbenennungen in ibexa_* rückgängig (oder lassen die Übersetzer-Extension aktiv) (Kapitel 16.6.4, Schritt 2).
4. Prüfen Sie das Schema mit ezsqldiff.php gegen Exponential 6 (Referenz zuerst) und ergänzen Sie die fehlenden Tabellen und Spalten; wenden Sie danach die aktuellen Dateien aus update/database/<engine>/6.0/ so an, wie Kapitel 11.6 es beschreibt.
5. Installieren Sie Exponential 6 (empfohlen ist ein Git-Klon mit Historie, Kapitel 3), kopieren Sie ezpublish_legacy/settings/override/, settings/siteaccess/, die Extensions und den Speicher hinein und tragen Sie die Datenbankverbindung wieder in settings/override/site.ini.append.php ein.
6. Liefern Sie sie aus mit Velocity oder Apache/nginx mit PHP-FPM (Kapitel 8); die Adressen der Legacy-Siteaccesses bleiben gleich; Adressen, die über Symfony-Routen ausgeliefert wurden (REST v2, reine Twig-Seiten), brauchen Weiterleitungen oder einen Ersatz.
7. Passwörter: Benutzer, die sich auf der Symfony-Seite angemeldet haben, haben Hashes vom Typ 7, die Exponential 6 lesen kann.

6. Prüfen #

• Anzahl der Objekte pro Klasse und Sprache, der Benutzer und der URL-Aliase vorher und nachher.
• Die Startseite, eine Seite pro Klasse, beide Administrationen: In jeder ein Element bearbeiten und veröffentlichen.
• Eine Bildvariante, ein Upload, die Suche, die Legacy-Cronjob-Teile von Hand ausgeführt.
• var/log von Symfony und ezpublish_legacy/var/log/error.log sind frei von Fehlern.
• Das Handbuch des Produkts enthält die Befehle pro Linie (Kapitel 10.8).

7. Rückweg #

Die Update-Dateien der Plattform ändern Zeilen und fügen Tabellen hinzu, lassen sich aber nicht durch eine weitere SQL-Datei rückgängig machen. Der Rückweg ist die Sicherung aus Schritt 1 plus die alte Exponential-6-Installation, die unangetastet bleibt, bis die neue eine Weile im Produktivbetrieb gelaufen ist.

8. Risiken #

9. Checkliste #

• To do: Linie gewählt (auf 2.5 landen, später aufsteigen); Version ausdrücklich angegeben.
• To do: Exponential 6 auf seinem neuesten Release; Sicherung einmal zurückgespielt.
• To do: MySQL-Tabellen auf utf8mb4; Update-Dateien des Kernels 2.5 angewendet und ihre Fehler gelesen.
• To do: Fehlende 2.5-Tabellen angelegt; ezsqldiff.php (Referenz zuerst) zeigt keine fehlende Tabelle oder Spalte.
• To do: Projekt angelegt, Installer nicht auf den Daten ausgeführt; Speicher verschoben.
• To do: Legacy-Einstellungen verschoben, Verbindungswerte entfernt; Siteaccesses in YAML mit legacy_mode.
• To do: Bild-Aliase als Varianten deklariert; Extensions verschoben und Autoloads neu erzeugt.
• To do: Caches auf beiden Seiten geleert, Suche neu indiziert, Cron über die Bridge.
• To do: Frontend und beide Administrationen geprüft; Plan für den Rückweg abgestimmt.

Diese Seite ist Teil der Exponential-Dokumentation und freie Dokumentation unter der GNU Free Documentation License 1.3 oder einer späteren Version (die Lizenz dieser Dokumentation).