17. Migrationsreferenz #

Dieses Kapitel ist der Referenzanhang zu den drei vorangehenden Migrationskapiteln. Es enthält die Tabellen, auf die diese Kapitel verweisen, statt sie zu wiederholen: jede Tabelle des Kernel-Schemas von Exponential 6.0 mit ihrem Zweck und ihrem Namen in eZ Platform und Ibexa; jeden Kernel-Datentyp mit den Spalten, in denen er seinen Wert speichert, und dem passenden Feldtyp; die INI-Einstellungen, die ein YAML-Gegenstück haben; Template-Konstrukte neben ihren Twig-Entsprechungen; die Legacy-PHP-Klassen neben den Diensten der Public API; Passwort-Hash-Typen, URL-Alias-Tabellen und Speicherpfade für Bilder; jedes Upgrade-, Reparatur- und Konvertierungsskript der Installation; eine Liste von Datenprüfungen, die vor dem Verschieben von Inhalten auszuführen sind; und ein Glossar der Namen, die sich zwischen den Generationen geändert haben. Die alten Produktnamen (eZ Publish 4.x und 5.x, eZ Platform, Ibexa DXP) erscheinen nur dort, wo sie das System bezeichnen, von dem eine Website kommt oder zu dem sie wechselt.

Inhalt · Zurück: 16. Migration von eZ Platform und Ibexa

Inhalt dieses Kapitels #

• 17.1 Wie die Tabellen geprüft wurden
• 17.2 Referenz des Datenbankschemas
• 17.3 Datentypen und Feldtypen
• 17.4 Einstellungen: INI und YAML
• 17.5 Templates: TPL und Twig
• 17.6 PHP-API: Legacy-Klassen und Dienste der Public API
• 17.7 Passwörter, URL-Aliase und Bildspeicherung
• 17.8 Datenprüfungen vor der Migration
• 17.9 Werkzeuge für Migration und Upgrade
• 17.10 Glossar umbenannter Begriffe
• Quellen

So verwenden Sie es: Beginnen Sie mit dem Kapitel Ihres Weges (14 für 4.x, 15 für den 5.x-Stack, 16 für eZ Platform und Ibexa) und kommen Sie hierher, wenn ein Schritt einen Namen braucht. Führen Sie vor jedem Umzug die Prüfungen aus 17.8 auf einer Kopie der Datenbank aus: Sie finden die Daten, die die andere Seite ablehnen wird, solange sie noch günstig zu beheben sind. Bei einem Umzug auf die Plattform entscheidet die Datentyptabelle in 17.3, was konvertiert werden muss; bei einem Umzug zu Exponential zeigen Ihnen die Spalten „Ibexa 4.6“ und „Ibexa 5“ in 17.2, welche Ihrer Tabellen Exponential liest und welche es ignoriert.

17.1 Wie die Tabellen geprüft wurden #

Jeder Name in diesem Kapitel wurde an Code oder Daten überprüft, und zwar an einer dieser Stellen:

Die Referenzdatenbank (SQLite) wurde nur lesend geöffnet und ausschließlich mit SELECT-Anweisungen abgefragt. Alles, was sich an keiner dieser Stellen überprüfen ließ, ist mit (hier nicht geprüft) gekennzeichnet.

Ibexa DXP 4.6 verwendet noch die Legacy-Tabellennamen (ezcontentobject, ezuser ...) und die Legacy-Bezeichner der Feldtypen (ezstring, ezimage ...). Die Ibexa-5-Datenbank benennt beides um: Tabellen werden zu ibexa_*, wobei einige Spalten umbenannt werden, und Feldtypen werden zu ibexa_*. Wo sie sich unterscheiden, sind unten beide Spalten angegeben.

17.2 Referenz des Datenbankschemas #

Das Kernel-Schema von Exponential 6.0 umfasst 128 Tabellen: share/db_schema.dba, kernel/sql/mysql/kernel_schema.sql und kernel/sql/postgresql/kernel_schema.sql führen dieselben 128 auf. kernel/sql/sqlite/schema.sql hat drei weitere, die zu Extensions gehören, für SQLite aber vorab angelegt werden: ezgmaplocation (ezgmaplocation), ezstarrating und ezstarrating_data (ezstarrating). Die Cluster-Tabellen (ezdfsfile, ezdfsfile_cache) stehen in der separaten Datei kernel/sql/mysql/cluster_dfs_schema.sql.

Legende für die letzten beiden Spalten: der Name der Tabelle im Schema des Legacy-Speichers von Ibexa DXP 4.6 und in der Ibexa-5-Referenzdatenbank; „gleich“ bedeutet derselbe Name; „—“ bedeutet, dass die Tabelle dort nicht existiert.

Inhalts-Repository #

Datentyp-Speicher #

Benutzer, Rollen und Sitzungen #

URLs und Suche #

Workflows, Benachrichtigungen und Zusammenarbeit #

Shop #

Weitere Kernel-Funktionen #

Tabellen, die es nur auf der Symfony-Plattform gibt #

Extensions bringen ihre eigenen Tabellen mit, die auf beiden Seiten ihre Namen behalten, wenn die Extension ein Gegenstück auf der Plattform hat: eztags, eztags_keyword und eztags_attribute_link (eztags und das Netgen Tags Bundle) sind unter diesen Namen in der Ibexa-5-Referenzdatenbank vorhanden, ebenso sckenhancedselection (enhancedselection2). Die Tabellen ezm_block und ezm_pool von ezflow (extension/ezflow/sql/) haben kein Gegenstück; siehe den Page-Feldtyp in 17.3.

17.3 Datentypen und Feldtypen #

Der Kernel registriert 35 Datentypen (settings/content.ini [DataTypeSettings] AvailableDataTypes[]). Jeder ist in kernel/classes/datatypes/<name>/<name>type.php implementiert, und der unten angegebene data_type_string ist die Konstante DATA_TYPE_STRING dieser Klasse. Die Speicherspalten sind die von ezcontentobject_attribute. Der Sortierschlüssel ist das, was sortKeyType() zurückgibt: int füllt sort_key_int, string füllt sort_key_string, und false füllt keine von beiden (kernel/classes/ezcontentobjectattribute.php).

Der Bezeichner für Ibexa 4.6 ist der Alias in der fieldtypes.yml von ibexa/core (oder im genannten Bundle); „Null“ bedeutet, dass 4.6 den Bezeichner mit dem Null-Feldtyp registriert, der den gespeicherten Wert lädt, ohne ihn zu verstehen. Der Bezeichner für Ibexa 5 ist derjenige aus der Feldtyp-Referenz oder, wo vermerkt, derjenige, der in der Referenzdatenbank gespeichert ist.

In dieser Installation gefundene Datentypen aus Extensions:

Hinweise zu den Konvertierungen, die der Hersteller dokumentiert #

• XmlText zu RichText. Die Migrationsseite des Herstellers führt XmlText als durch RichText ersetzt und auf der Plattform nicht unterstützt; Inhalte werden mit ezxmltext:convert-to-richtext aus ezsystems/ezplatform-xmltext-fieldtype konvertiert (Optionen --dry-run, --export-dir, --export-dir-filter, --image-content-types, --concurrency). RichText validiert strenger als XmlText, führen Sie daher zuerst den Probelauf aus. In diesem Repository gibt es keinen solchen Konverter, in keiner Richtung; Exponential rendert die DocBook-Elemente ezembed, para und literallayout, wenn sie in importiertem ezxmltext vorkommen (kernel/classes/datatypes/ezxmltext/handlers/output/ezxhtmlxmloutput.php), wodurch solcher Text lesbar bleibt, aber nicht konvertiert wird. Die Zuordnung der Elemente für eine eigene Konvertierung steht in 15.8 und 16.6.3.

• Benutzerdefinierte Tags. Die Attributtypen benutzerdefinierter Tags des Online-Editors (extension/ezoe/design/standard/templates/ezoe/customattributes/) entsprechen, wie vom Hersteller dokumentiert, folgenden Attributtypen benutzerdefinierter Tags in RichText:

  ezoe-Attributtyp	RichText-Typ	Hinweis des Herstellers
  link	link	unterstützt
  number, int	number
  checkbox	boolean
  select	choice
  text	string
  textarea, email, hidden, color, htmlsize, csssize, csssize4, cssborder	string	„als Behelfslösung verwenden“

  Die Tags selbst werden in settings/content.ini [CustomTagSettings] AvailableCustomTags[] deklariert (standardmäßig factbox, quote, strike, sub, sup) sowie in der content.ini.append.php von Extensions.

• Page (ezflow). Ersetzt durch den Page-Feldtyp der kommerziellen Editionen; die Open-Source-Plattform hat kein Ziel. Der Befehl ezflow:migrate des Herstellers gehört zu diesen Editionen.

• Sternebewertung (ezsrrating). Vom Hersteller als nicht unterstützt geführt: Implementieren Sie sie, oder entfernen Sie sie aus jeder Klasse.

• Eigene Datentypen. Schreiben Sie sie als Feldtypen neu, oder registrieren Sie den Null-Feldtyp für ihren Bezeichner, damit die gespeicherten Werte ohne Fehler geladen werden. Ibexa 4.6 tut dies bereits für die oben mit Null gekennzeichneten Bezeichner.

17.4 Einstellungen: INI und YAML #

Aufgeführt sind nur Paare, für die sich zeigen lässt, dass sie dasselbe beschreiben. Die YAML-Schlüssel wurden an der generierten Konfigurationsreferenz und an den ibexa.yaml-Dateien der Ibexa-5-Referenzinstallation überprüft; die Paare für Datenbank und Dateien sind außerdem diejenigen, die die Legacy-Bridge automatisch zuordnet (doc/eng-us/specifications/6.0/legacy-bridge-bundle.md). <scope> ist ein Siteaccess, eine Siteaccess-Gruppe oder default, unterhalb von ibexa.system.

Siteaccesses, Sprachen und Design #

Datenbank, Dateien und Clustering #

Benutzer, Sitzungen, URLs, Caches und Suche #

Zu den Einstellungen ohne Gegenstück auf der Plattform gehören site.ini [UserSettings] HashType und UpdateHash (die Plattform speichert den Hash-Typ pro Benutzer, siehe 17.7), [TemplateSettings] (Kompilierung von Templates), [SiteAccessSettings] RequireUserLogin sowie sämtliche Einstellungen für Shop, Workflows und Benachrichtigungen.

17.5 Templates: TPL und Twig #

Die folgenden TPL-Konstrukte sind in lib/eztemplate/classes/eztemplateautoload.php (Sprachfunktionen) und kernel/common/eztemplateautoload.php (Operatoren und Funktionen des Kernels) definiert. Die Twig-Namen sind die von Ibexa 4.6 und 5, wie sie in den Templates der Referenzinstallation verwendet werden; eZ Platform verwendete dieselben Namen mit dem Präfix ez_ (ez_render_field, ez_path ...), die Ibexa 4.6 weiterhin akzeptiert.

override.ini und content_view drücken dieselbe Regel in zwei Formen aus:

# settings/siteaccess/site/override.ini.append.php
[full_article]
Source=node/view/full.tpl
MatchFile=full/article.tpl
Subdir=templates
Match[class_identifier]=article

ibexa:
    system:
        site_group:
            content_view:
                full:
                    article:
                        template: '@ibexadesign/full/article.html.twig'
                        match:
                            Identifier\ContentType: article

Die Legacy-Match-Schlüssel für Knotenansichten werden in kernel/classes/eznodeviewfunctions.php gesetzt (unter anderem class_identifier, node, parent_node, section, section_identifier, depth, url_alias, state_identifier, parent_class_identifier, remote_id, node_remote_id). Die Matcher der Plattform mit derselben Bedeutung (Klassen in Ibexa\Core\MVC\Symfony\Matcher\ContentBased, Ibexa 4.6):

17.6 PHP-API: Legacy-Klassen und Dienste der Public API #

Die Legacy-Methoden liegen, sofern nicht anders angegeben, in kernel/classes/; die Dienste sind die Interfaces in Ibexa\Contracts\Core\Repository (Ibexa 4.6, ibexa/core v4.6.28; unter eZ Platform lautete der Namespace eZ\Publish\API\Repository). Aufrufe der Plattform laufen als der aktuelle Benutzer, der am PermissionResolver gesetzt ist, während Legacy-Code meist mit den Rechten des angemeldeten Benutzers lief und in Skripten Prüfungen übersprang.

eZContentObject und ContentService #

Die Legacy-Klasse hat keine Methode publish(); das Veröffentlichen läuft über die Operation publish oder über eZContentFunctions.

eZContentObjectTreeNode und LocationService #

eZUser und UserService #

eZContentClass und ContentTypeService #

Suche, URL-Aliase, Rollen und der Rest #

17.7 Passwörter, URL-Aliase und Bildspeicherung #

Passwort-Hash-Typen #

ezuser.password_hash_type enthält eine der Konstanten von eZUser (kernel/classes/datatypes/ezuser/ezuser.php); eZUser::createHash() berechnet jede davon:

Ibexa 4.6 unterstützt nur 6 und 7 (SUPPORTED_PASSWORD_HASHES); Ibexa 5 ergänzt 256. ezsystems/ezpublish-kernel 7.5 (eZ Platform 2.5) deklarierte noch 1, 2, 3, 5, 6 und 7, wobei die MD5- und Klartext-Typen seit Kernel 6.13 als veraltet galten. Alle Benutzer in der Ibexa-5-Referenzdatenbank haben Typ 7.

Exponential erzeugt den Hash bei der Anmeldung neu: Mit site.ini [UserSettings] UpdateHash=true (Standard) und HashType=php_default (Standard) ersetzt eZUser::_loginUser() nach einer erfolgreichen Passwortprüfung jeden anderen gespeicherten Typ durch einen Hash vom Typ 7, aktualisiert password_hash und password_hash_type und leert den Cache des Benutzers. Benutzer, die sich angemeldet haben, seit die Website zu Exponential gewechselt ist, haben daher bereits einen Hash, den die Plattform akzeptiert. So listen Sie die übrigen vor der Migration auf:

SELECT password_hash_type, COUNT(*) FROM ezuser GROUP BY password_hash_type;

Konten, die noch die Typen 0 bis 5 haben, können sich auf der Plattform nicht anmelden; dort ist für sie ein Zurücksetzen des Passworts nötig. ezuser.password_hash ist im Schema von Exponential (kernel/sql/mysql/kernel_schema.sql) wie auf der Plattform VARCHAR(255), sodass bcrypt- und Argon2-Hashes hineinpassen.

URL-Alias-Tabellen #

Die Tabellen der Plattform haben dieselben Spalten unter denselben Namen (Ibexa 4.6) bzw. heißen ibexa_url_alias_ml, ibexa_url_alias_ml_incr und ibexa_url_wildcard (Ibexa 5), sodass die Aliase mit den Daten umziehen. Anschließend werden sie mit ibexa:urls:regenerate-aliases neu erzeugt (exponential:urls:regenerate-aliases auf Exponential Platform v5, das keinen ibexa:-Alias registriert). Die Slug-Transformation muss übereinstimmen: Der Standard von Exponential ist urlalias ([URLTranslator] TransformationGroup), die Ibexa-5-Referenzinstallation verwendet urlalias_lowercase.

Speicherpfade für Bilder und Dateien #

Die Anleitung des Herstellers kopiert <old root>/web/var[/<site>]/storage an dieselbe Stelle in der neuen Installation; die im XML und in ezimagefile gespeicherten Bildpfade müssen danach auf vorhandene Dateien zeigen, was die Prüfungen in 17.8 feststellen.

17.8 Datenprüfungen vor der Migration #

Der Hersteller führt Probleme auf, die nach einer Migration auftreten. Nach jedem davon lässt sich zuerst in der Datenbank von Exponential suchen. Das SQL läuft auf MySQL, PostgreSQL und SQLite; führen Sie es auf einer Kopie aus.

Die Befehlsnamen der Plattform sind diejenigen, die der Hersteller dokumentiert; ihr Präfix ändert sich zwischen den Plattformversionen.

17.9 Werkzeuge für Migration und Upgrade #

Jedes bin/php/<name>.php steht auch als ./console exp:<name> zur Verfügung; der Code der meisten davon liegt in kernel/private/classes/commands/. Die Standardoptionen (-s/--siteaccess, -q, -v, -d, --allow-root-user) gelten für alle Skripte, die auf eZScript beruhen. Kapitel 11 erklärt, in welcher Reihenfolge sie auszuführen sind.

Datenbank-Update-Dateien #

update/database/<engine>/<version>/dbupdate-<from>-to-<to>.sql, für mysql, postgresql und sqlite. MySQL und PostgreSQL enthalten die Kette von 4.0/dbupdate-3.10.0-to-4.0.0.sql über die 5.x-Schritte (mit Alpha-, Beta- und RC-Schritten in unstable/ für 4.0 bis 5.0 und dbupdate-cluster-*-Dateien für den MySQL-Cluster bei 4.3, 4.7, 5.2 und 5.4), danach das Verzeichnis 6.0 mit dem Schritt von 5.4 (dbupdate-5.4.0-6.0.0.sql auf MySQL, dbupdate-5.4-to-6.0.sql auf PostgreSQL) und dbupdate-6.0.0-6.0.15.sql. SQLite hat nur 6.0/dbupdate-6.0.0-6.0.15.sql. Jede MySQL-Datei beginnt mit SET default_storage_engine=InnoDB; (von MySQL ab 5.5.3 und von MariaDB akzeptiert); Kopien aus der Zeit vor Oktober 2026 enthielten SET storage_engine, was aktuelle Server ablehnen.

Die Verzeichnisse 6.12/, 7.2/ (nur PostgreSQL) und 7.3/ stammen aus der Upstream-Legacy-Linie der Jahre 2016 bis 2018 und sind nach der Version des Symfony-Kernels nummeriert, neben dem sie liefen; wenden Sie sie niemals als Dateien an. Ihre drei Schemaänderungen (ezuser.password_hash auf 255 erweitert, die PostgreSQL-Sequenzen in <table>_<column>_seq umbenannt, ezcontentobject_trash.trashed) nimmt die Datei von 5.4 auf 6.0.0 vor und erneut die Datei von 6.0.0 auf 6.0.15, jeweils nur dort, wo sie in der Datenbank fehlen (11.3). Oracle hat keine 6.0-Datei: Führen Sie die Anweisungen für password_hash und trashed aus 11.5 von Hand aus. php bin/php/console exp:checkdbfiles --no-verify-branches prüft, ob der Baum vollständig ist (Tabelle unten).

update/common/scripts #

bin/php: Schema, Daten und Konvertierung #

Skripte von Extensions: extension/eztags/bin/php/convertezkeyword.php überführt ezkeyword-Attribute in eztags (--from-attr-id, --to-attr-id, --parent-tag-id); extension/enhancedselection2/bin/php/migrate_to_database.php und updateenhancedselection.php aktualisieren den Speicher von Enhanced Selection.

bin/php: Prüfungen nach einem Upgrade #

Shell-Hilfsskripte in bin/shell/: checkdbschema.sh, checkdbupdate.sh (--check-stable, --check-previous), verifyfiles.sh (--quiet) und generatefilelist.sh. In der Administration führt Setup > Upgrade-Prüfung dieselbe Dateiprüfung gegen share/filelist.md5 aus und vergleicht das laufende Schema mit share/db_schema.dba, zusammengeführt mit den Schemas der aktiven Extensions (kernel/private/classes/views/setup/systemupgrade.php).

Umzug auf die Plattform oder von ihr weg #

Dieses Repository enthält keinen Datenkonverter zu oder von eZ Platform oder Ibexa. Die Legacy-Bridge führt den Kernel von Exponential innerhalb einer Plattform-Installation auf einer gemeinsamen Datenbank aus (Branches für eZ Platform 2.5, Platform 3.3, Ibexa 4.6 und Platform 5), mit den Konsolenbefehlen exponential:legacy:init, configure, install-extensions, symlink, assets-install und script auf der Linie 3.x ab v3.0.0.30, der Linie 4.x ab v4.0.0.2 und in jedem 5.x-Tag, wobei die alten Namen ezpublish:* als veraltete Aliase erhalten bleiben. Die Linie 2.5 (master, v2.1.10 bis v2.1.12) und die früheren 3.x- und 4.x-Tags kennen nur die alten Namen (ezpublish:legacy:init ...). Auf Seiten der Plattform dokumentiert der Hersteller ezxmltext:convert-to-richtext, ibexa:urls:regenerate-aliases, ezplatform:images:normalize-path und die in 17.8 aufgeführten Befehle ezpublish:update:legacy_storage_*.

17.10 Glossar umbenannter Begriffe #

Quellen #

In diesem Repository:

• 11. Upgrade: die Reihenfolge, in der die Update-Dateien und Skripte auszuführen sind.
• Upgrade, Inhaltsmodell und Bearbeitung, Templates und Design, Betrieb einer Website.
• Legacy-Bridge, Spezifikation des Legacy-Bridge-Bundles, Übersicht der Plattformpakete, Site-Bundles der Plattform, Forks von Plattformpaketen und umbenannte Befehle.
• HTTP-Caching, Prüfung der Dateikonsistenz, Audit-Protokoll, Glossar.
• Code: share/db_schema.dba, kernel/sql/, kernel/classes/datatypes/, kernel/classes/datatypes/ezuser/ezuser.php, kernel/classes/ezcontentobjecttreenode.php, kernel/classes/datatypes/ezimage/ezimagealiashandler.php, lib/eztemplate/classes/eztemplateautoload.php, kernel/common/eztemplateautoload.php, settings/site.ini, settings/image.ini, settings/file.ini, settings/httpcache.ini, update/, bin/php/.

Extern:

• Migrationsseiten des Herstellers: Migrate from eZ Publish, Migrate from eZ Publish Platform, Common migration issues, Migrating from eZ Publish (Version für eZ Platform 2.5) (die Version 1.13 der Seite wird nicht mehr veröffentlicht; ihre alte Adresse leitet auf die aktuelle Seite weiter).
• Feldtypen: Feldtyp-Referenz, Image, User, Null, MapLocation, Matrix.
• Quellcode: ezsystems/ezpublish-legacy, ezsystems/ezpublish-kernel (Hash-Konstanten von User in 7.5), ezsystems/ezplatform-xmltext-fieldtype, ezsystems/LegacyBridge, ibexa/core.
• PHP: password_hash, password_verify.
• Symfony und Twig: Konfiguration, Verbindungs-URLs für Doctrine DBAL, Mailer-DSN, ESI, Twig für Template-Designer, Twig include.

Inhalt · Zurück: 16. Migration von eZ Platform und Ibexa