Lokale Website auf Webserver hochgeladen: Datenbankaktualisierung nicht mehr möglich

Hallo, nach dem Hochladen einer lokalen Website-Kopie (aus XAMPP) auf den Webserver - genau nach Anleitung - kann die Website zwar fehlerfrei aufgerufen werden, aber die Datenbank lässt sich nicht mehr aktualisieren. Das Contao-Installtool bricht die Aktualiserung mit folgender Fehlermeldung ab:

Code:

---

[2021-08-26 13:59:40] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\DriverException: "An exception occurred while executing 'ALTER TABLE tl_content CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci':  SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline." at /home/['Aktueller Benutzer']/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 128 {"exception":"[object] (Doctrine\\DBAL\\Exception\\DriverException(code: 0): An exception occurred while executing 'ALTER TABLE tl_content CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci':\n\nSQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline. at /home/['Aktueller Benutzer']/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:128, Doctrine\\DBAL\\Driver\\PDO\\Exception(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline. at /home/['Aktueller Benutzer']/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDO/Exception.php:18, PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline. at /home/['Aktueller Benutzer']/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:132)"} []

---

Eigentlich dürfte das Contao-Installtool überhaupt keine Aktualisierungen der Datenbank durchführen, weil die Website-Kopie 1:1 auf den Server übertragen wurde.
Meine Frage, kann ich den Fehler manuell reparieren, oder muss ich alles (Datenbank, Contao Manager, Contao CMS, Files, Module, Templates etc.) noch einmal von Anfang an installieren bzw. hochladen? Vermutlich wird der Datenbankaktualisierungsfehler aber auch nach einer Neuinstallation erneut auftreten.

Update 1:
Gerade ist mir aufgefallen, dass die beiden PHP-Versionen nicht 100%ig übereinstimmen. Auf dem Webserver befindet sich die Version 7.3.28 bei der lokalen Installation (XAMPP) ist es die Version 7.3.26. Könnte dieser minimale Versionsunterschied den o.g. Fehler verursachen? Zwischen .26 und .28 gab es nur ein paar Bug-Fixes (Imap, SOAP, Standard).

Update 2:
Verrückterweise exportiere ich aus XAMPP die Datenbank mit der Kollation utf8mb4_general_ci. Nachdem ich die Datenbank auf dem Webserver importiert habe, wird sie mit der Kollation latin1_swedish_ci deklariert. Vermutlich deshalb versucht das Contao-Installtool die Tabellen inutf8mb4_general_ci zu konvertieren. Beispiel: ALTER TABLE tl_crawl_queue CONVERT TO CHARACTER SET utf8 COLLATE utf8mb4_unicode_ci

Die Unterschiede in den PHP-Versionen spielt hier keine Rolle.

Das Contao Installtool möchte auch nicht direkt die Datenbank aktualisieren, sondern weißt darauf hin, dass die "Row size too large" ist.

Hier ein Thread, wo es um diese Thematik geht: https://community.contao.org/de/show...size-too-large

Das ist es ja eben, die o.g. Fehlermeldung im Contao-Installtool dürfte überhaupt nicht erscheinen. Ich füge weder etwas hinzu, noch ändere ich irgendetwas an der Datenbankstruktur. Die lokale Website-Kopie habe ich 1:1 auf den Webserver hochgeladen, inkl. aller Erweiterungen/Pakete/Module. Allerdings hatte ich bei meiner lokalen Website-Kopie (XAMPP) vergessen, den Strict-Mode für die DB zu aktivieren. Auf dem Webserver war der Strict-Mode schon aktiv. Das habe ich bei der lokalen Website-Kopie nachgeholt und die Datenbank via Contao-Installtool erfolgreich aktualisiert. Der Fehler muss also an anderer Stelle liegen. Ich weiß im Moment nur nicht wo.

Das ist einfach ein anderer Datenbankserver mit anderen Einstellungen, beim XAMPP sind sie halt so, dass die row_size für diese Einstellungen ok ist. Der MySQL/MariaDB-Server im Webhosting hat andere Einstellungen, die eben nur eine geringere row_size erlauben. Laut Fehlermeldung wurde schon versucht, was an einer Tabelle zu ändern, wenn auch nur den Character Set. Der kann sich natürlich auch auf die benötigte row_size auswirken, bzw bei der Gelegenheit merkt der Server eben, dass die row_size für seine Einstellungen zu gross wird.

Wenn der Datenbankserver im Webhosting "schmaler" konfiguriert ist, warum konnte dann die Website komplett gleichen Inhalts zuvor bereits auf demselben Webspace erfolgreich gehostet und auch aktualisiert werden? Das einzige, was sich aktuell geändert hat, ist die Contao-Version: alte Version: 4.4.57, neue Version: 4.9.12 bzw. 4.9.20. Der Provider unterstützt neuerdings ebendiese neuere Contao-Version. Ein Upgrade war vor allem deswegen notwendig, weil sich die alte Version 4.4.57 inkl. Module via Contao Manager nicht mehr "sauber" aktualisieren ließ. Da ein direktes Upgrade von 4.4.57 auf 4.9.12 bzw. 4.9.20 nicht möglich war, habe ich den Umweg über die lokale Website-Kopie (XAMPP) gewählt. Dass ich jetzt mit solchen Fehlern zu kämpfen habe, hätte ich nicht gedacht.

Das 4.9.20 Update hattest du ja noch nie auf dem Webserver laufen, nur das Original 4.4.57. Das mag zwar die selben Inhalte haben, aber es reichen ja möglicherweise z.B. ein paar neue Spalten oder sogar eine Vergrößerung einer Spalte in tl_content entweder vom Core oder von einer Erweiterung, um eben knapp über die zulässige row_size zu kommen. Was meinst du denn genau mit "weil sich die alte Version 4.4.57 inkl. Module via Contao Manager nicht mehr sauber aktualisieren ließ"? Gab es Fehlermeldungen oder was war sonst das Problem?

Zitat:

---

Zitat von mnefzger

weil sich die alte Version 4.4.57 inkl. Module via Contao Manager nicht mehr "sauber" aktualisieren ließ.

---

Also gab es ja auch da schon ein Problem auf dem Server.

Die Contao-Version 4.4.57 ist über zwei Jahre hinweg durch zahlreiche Updates zuletzt in sich inkonsistent geworden, sodass sich einige Module nicht mehr auf die neueste Version updaten ließen. Die Fehlermeldungen habe ich mir nicht im einzelnen angesehen, weil ich zu diesem Zeitpunkt schon dazu tendierte, die alte 4.4.57er Version aufzugeben. Möglicherweise gab es bei den neuesten Versionen dieser Module schon das row_size-Problem. Vorallem auch im Hinblick auf den ablaufenden LTS der 4.4er Version, habe ich mich dann endgültig dazu entschieden, die nächste LTS-Version 4.9 zu installieren. - Wahrscheinlich wird es aber am besten sein, den Provider zu wechseln. Auch wenn der Provider neuerdings angeblich die 4.9er Contao-Version unterstützt, scheint es im Detail doch zu haken.

Danke für die Rückmeldungen. Gestern Abend ist es mir dann doch noch gelungen, die Änderungen in der Datenbank via Contao Installtool erfolgreich durchzuführen. Ich weiß nicht genau wie und warum bzw. auf Grund welcher Aktion es am Ende funktioniert hat. Nach zahlreichen Erneuerungen bzw. Leerungen der Anwendungs-/Composer-Caches und zahlreichen Composer-Updates sowie Datenbereinigungen in der Contao Systemwartung und auch mehrfacher Neuerstellung der Datenbank sowie Änderungen der Einträge in der config.yml lief das Contao Installtool schließlich ohne Fehler durch. Anscheinend bereitet auch die Strict-Mode-Anweisung für die Datenbank Probleme:

Code:

---

doctrine:
    dbal:
        connections:
            default:
                default_table_options:
                    charset: utf8
                    collate: utf8_unicode_ci
                    engine: MyISAM
                options:
                    1002: "SET SESSION sql_mode=(SELECT CONCAT(@@sql_mode, ',TRADITIONAL'))"

---

In dieser Ausgestaltung hat die Strict-Mode-Anweisung dann letztlich funktioniert. Allerdings habe ich während der "Bereinigungs- und DB-Neuerstellungsorgie" die collate-Anweisung zeitweise entfernt und später wieder hinzugefügt.
Alles in allem scheint das Zusammenspiel der Einzelkomponenten eine ziemlich heikle und ruckelige Angelegenheit zu sein, und es ist mir nun schon häufiger passiert, dass die Fehlermeldungen des Installtools eher in die Irre führen als helfen, den eigentlichen Fehler, welcher genau es in meinem Fall auch war, zu finden.

Nachtrag: Die in phpMyAdmin angzeigte (falsche) Kollation latin1_swedish_ci scheint keine Auswirkungen auf das Fehlerbild gehabt zu haben. Die (falsche) Kollationsangabe (eigentlich sollte sie utf8mb4_general_ci lauten) besteht auch nach DB-Neuinstallation und erfolgreicher Aktualisierung weiterhin.

Beim erstellen der DB legst Du doch die "globale" Kollation selbst fest.
Beim reinen Import haben die importierten Tabellen, die Kollation, die in der SQL-Datei stehen
Verstehe ich die völlig falsch oder bin vollkommen auf dem falschen Dampfer?

Zitat:

---

Zitat von mlweb

Beim erstellen der DB legst Du doch die "globale" Kollation selbst fest.
Beim reinen Import haben die importierten Tabellen, die Kollation, die in der SQL-Datei stehen
Verstehe ich die völlig falsch oder bin vollkommen auf dem falschen Dampfer?

---

Ja, in der exportierten SQL-Datei steht die Kollation genau wie gewünscht drin: utf8mb4_unicode_ci, und ich importiere die Tabellen in eine leere Datenbank. Dennoch wird nach erfolgreichem Import im phpMyAdmin-Frontend die (falsche) Kollation latin1_swedish_ci angezeigt. Beim Erstellen einer leeren Datenbank via cPanel habe ich m.W. nicht die Möglichkeit, die "globale" Kollation festzulegen. Das dürfte eigentlich auch keine Rolle spielen, da ja die importierten Tabellen die Kollation "mitbringen". Wie auch immer, scheint sich dieser "Fehler" nicht negativ auszuwirken.

Ich habe gerade mal bei Strato getestet. Beim Anlegen der DB kann ich dort die Kollation auch nicht auswählen, aber ich könnte diese nachträglich ändern. Habe ich für den Test von utf8_general_ci (Standard beim Anlegen einer neuen Datenbank bei Strato) auf latin1_swedish_ci geändert.
Danach eine beliebige aktuelle DB von Contao 4.9 importiert, alle Tabellen utf8mb4_unicode_ci. Die Kollation der Tabellen bleibt wie erwartet erhalten. Die Datenbank selbst steht auch wie erwartet weiterhin auf latin1_swedish_ci. Sprichst Du jetzt von der DB oder von den einzelnen Tabellen?

Ich spreche nur von der DB, nicht von den Tabellen. Die Angabe im phpMyAdmin-Frontend ist vermutlich die Info über die "globale" Kollation. Die Tabellen haben trotzdem utf8mb4_unicode_ci (habe ich gerade stichprobenartig nachgesehen). Ich traue mich jetzt aber nicht im phpMyAdmin-Frontend nachträglich die "globale" Kollation umzustellen, weil ich mögliche Seiteneffekte befürchte. Nicht dass, mir das mühsam errichtete "Kartenhaus" gleich wieder zusammenbricht. ;)

Brauchst Du auch nicht. Die Kollation der Tabellen ist das entscheidende. Ich hatte gedacht, Du meinst Deine Tabellen stehen auf der "falschen" Kollation.

Da bin ich beruhigt. Dann ist das jetzt eben ein "Schönheitsfehler". Für zukünftige Installationen sehe ich einen Zwischenschritt vor: Sofort nach Erstellung einer leeren Datenbank und bevor ich Tabellen aus einem Datenbank-Backup importiere, korrigiere ich die "globale" Kollation manuell. Vielen Dank fürs Testen.