Installtool mit Fehlermeldung nach Update

Hallo, nach einem Update von einer 4.9.? auf die letzte Version 4.9.31 hängt das Installtool beim Datenbank aktualisieren. Es kommt dann die typische Fehlerseite.

In der log-Datei stehen als letzte Einträge:

Code:

---

[2022-08-04 13:44:39] request.INFO: Matched route "contao_install". {"route":"contao_install","route_parameters":{"_route":"contao_install","_scope":"backend","_token_check":true,"_controller":"Contao\\InstallationBundle\\Controller\\InstallationController::installAction"},"request_uri":"https://www.xxx.se/contao/install","method":"POST"} []
[2022-08-04 13:44:40] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\DriverException: "An exception occurred while executing 'ALTER TABLE tl_module ENGINE = InnoDB ROW_FORMAT = DYNAMIC':  SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs" at /home/rjckhylq/public_html/xxx/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_module ENGINE = InnoDB ROW_FORMAT = DYNAMIC':\n\nSQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs at /home/rjckhylq/public_html/xxx/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. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs at /home/rjckhylq/public_html/xxx/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. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs at /home/rjckhylq/public_html/xxx/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:141)"} []

---

Den Produktionscache habe ich schon erneuert

Kann mir jemand helfen?
Vielen Dank

schau mal, ob dir hier weitergeholfen wird

Hallo Bernhard, Danke für Deine Hilfe. Verstehe ich das richtig, dass ein update auf die 4.13. hilft? Und wenn ja, sollte ich das update durchführen, auch wenn der ursprüngliche Fehler noch existiert?
Ich würde denken, dass erstmal die 4.9.31 sauber läuft, und dann der nächste Schriftt auf 4.13. gemacht werden sollte. Oder repariert die 4.13. den Fehler?
Ich stehe da auf dem Schlauch, da ich die Code-Zeilen nicht verstehe
Gruß
Gert

Ein Update auf 4.13 schadet ja grundsätzlich nie :D
Sofern es deine Erweiterungen zulassen.

Ich würde dies in einer Parallel-Installation mal austesten. Und schauen, ob es deinen Fehler denn behebt.
Wie du ja auch im genannten Beitrag lesen kannst, wurde mit 4.13 in diese Richtung aktualisiert.

So wie ich das verstanden habe im anderen Thread, würde ich davon ausgehen, dass die geplanten Optimierungen in 4.9.31 schon umgesetzt sein müssten. Aber da darf man sicher keine Wunder erwarten, das betrifft ja nur den Core und nicht die ganzen externen Erweiterungen. Klar kann man hier und da ein paar Byte einsparen im Core, siehe letztens die "playerColor", die Spalte wurde verkleinert auf die vernünftige Größe, die ein RGB-Wert als Hex-Wert eben so braucht. Aber man wird das insgesamt sicher nicht auf die Hälfte reduzieren können. Zumindest nicht ohne Performance-Einbussen, wenn man z.B. von varchar auf text umstellt. Klar, ein Teil der Daten ist dann raus aus der Tabelle, aber dafür ist dann halt der Zugriff auf die Daten aufwändiger, dauert also etwas länger.

Also sind auch die Programmierer von Erweiterungen gefragt, vielleicht müssen ja nicht unbedingt die gesamten Daten einer Erweiterung in tl_module oder tl_content abgeladen werden. Oder man muss grundsätzlich überlegen, ob man die kritischen Tabellen irgendwie sinnvoll automatisch auf mehrere Tabellen verteilen kann, wenn sie überlaufen. Sowas war glaube ich vor längerem schon mal im Gespräch.

Und als Anwender muss man sich eben überlegen, ob man wirklich für jeden Buchstaben eines Texts eine eigene Erweiterung braucht :D. Vieles geht auch relativ einfach mit Core-Mitteln. Vielleicht etwas weniger komfortabel als mit einer Erweiterung, aber wenn dafür dann die Tabellen nicht platzen, ist das für mich allemal das kleinere Übel.

Mein Hoster sagt bezüglich innodb_large_prefix: "Es ist leider nicht aktiviert & kann nicht aktiviert werden, es wurde mit MySQl 5.7.7 abgekündigt"

Ich wollte dem Rat von derRenner folgen und eine Parallel-Installtion mit der ersten Datenbank durchführen, also der Datenbank vor dem ersten update von 4.9.?
Da kommt dann beim Import in phpmyadmin folgende Fehlermeldung:

SQL-Befehl:

-- --------------------------------------------------------

--
-- Tabellenstruktur für Tabelle `tl_module`
--

CREATE TABLE `tl_module` (
`id` int(10) UNSIGNED NOT NULL,
`pid` int(10) UNSIGNED NOT NULL DEFAULT 0,
`tstamp` int(10) UNSIGNED NOT NULL DEFAULT 0,
`name` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`headline` varchar(255) COLLATE utf8_unicode_ci NOT NULL DEFAULT 'a:2:{s:5:"value";s:0:"";s:4:"unit";s:2:"h2";}',
`type` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT 'navigation',
`levelOffset` smallint(5) UNSIGNED NOT NULL DEFAULT 0,
`showLevel` smallint(5) UNSIGNED NOT NULL DEFAULT 0,
`hardLimit` char(1) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`showProtected` char(1) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`defineRoot` char(1) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`rootPage` int(10) UNSIGNED NOT NULL DEFAULT 0,
`navigationTpl` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '',
`customTpl` varchar(64) COLLAT[...]

MySQL meldet: Dokumentation
#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.

[QUOTE=Alok;561601]Mein Hoster sagt bezüglich innodb_large_prefix: "Es ist leider nicht aktiviert & kann nicht aktiviert werden, es wurde mit MySQl 5.7.7 abgekündigt"

Vermutlich existiert diese Einstellung nicht mehr in deiner MySQL-Version, weil sie nicht mehr notwendig bzw sowieso immer aktiv ist. Sie betrifft eigentlich auch nur Indizes und hat m.E. mit deinem Problem nichts zu tun. Du hast schlicht zu viele Erweiterungen, die zu viele Daten in deine tl_module Tabelle speichern wollen. Und irgendwann knallt es dann eben.

Erweiterungen sind nur folgende installiert:

Hast du in deiner config.yml utf8 statt utf8mb4 forciert?

Inhalt der config.yml:

Code:

---

doctrine:
    dbal:
        connections:
            default:
                default_table_options:
                    charset: utf8
                    collate: utf8_unicode_ci

contao:
    prepend_locale: true

---

Entferne

Code:

---

doctrine:
    dbal:
        connections:
            default:
                default_table_options:
                    charset: utf8
                    collate: utf8_unicode_ci

---

Danach den Symfony Application Cache neu aufbauen.

Habe das gemacht, wie du, spooky, geschrieben hast. Dann nochmal ins Installtool. Da tauchte dann auf einmal die Medlung von einem 4.4.7-update auf, siehe Bild,

Anhang 25745

obwohl ich ja usprünglich von einem 4.9.? update aus angefangen habe.

Dann habe ich die erste Option abgehakt und Datenbank aktualisiert, dann blieb nur noch die erste Option übrig und beim erneuten Datenbank aktualisieren war es dann ok.

Soll die gelöschte Anweisung aus der config.yml wieder reingeschrieben werden, spooky?

Soll die andere Zeile verbleiben? Mir sagt das nichts.

Code:

---

contao:
    prepend_locale: true

---

Super und vielen Dank an alle Beteiligten.

Zitat:

---

Zitat von Alok

Soll die gelöschte Anweisung aus der config.yml wieder reingeschrieben werden, spooky?

---

Auf keinen Fall.

Zitat:

---

Zitat von Alok

Mir sagt das nichts.

---

Das hast aber du da rein geschrieben ;). Damit wird der Sprach-Prefix in der URL aktiviert.

OK und nochmals vielen Dank!