Druckbare Version
Danke @pumukel.
Es geht bei der Installation um drei bestehende Websites. Für die Hauptdomain gibt es einen Relaunch den ich betreue. Das ist Contao. Die anderen beiden sind Subdomains mit einmal Joomla und einmal Made Simple.
Wenn ich dem Kunden einen Umzug zu einem anderen Hoster vorschlage, muss ich auch diese vorhandenen Installationen berücksichtigen.
Ich fasse mal kurz den aktuellen Stand zusammen.
Strato hat mit der Umstellung auf MySQL 5.6.31 auf InnoDB Datenbanken umgestellt. Ein erstellen von MyISAM Datenbanken ist wegen der fehlenden Engine nicht mehr möglich.
Deshalb blieb immer der Hinweis
bestehen.Code:ALTER TABLE `tl_files` ADD KEY `path` (`path`(333));
Auf meinen Hinweis bei Strato, dass durch die Änderung die Länge für den Index nicht ausreicht, hat Strato Ende letzter Woche oder Anfang dieser Woche eine Veränderung vorgenommen. Ich kann sehen, das innodb_large_prefix aktiviert ist.
Leider gibt es jetzt aber eine Fehlermeldung:
Siehe dazu auch https://github.com/contao/core/issues/8484Code:Fatal error: Uncaught exception Exception with message Query error: Index column size too large. The maximum column size is 767 bytes. (ALTER TABLE `tl_files` DROP INDEX `path`, ADD KEY `path` (`path`(333));) thrown in system/modules/core/library/Contao/Database/Statement.php on line 295
Da war wohl der Wunsch der Vater des Gedankens. Ich bin mir zwar nicht sicher, aber, wenn es wirklich aktiviert ist und die Fehlermeldung kommt trotzdem, dann bringt uns das vermutlich nichts. Der Grund dürfte sich dann daraus ergeben.
Aus dem MySQL 5.6 Reference Manual
Daraus schliesse ich dann, dass "unsere" InnoDB-Tabellen eben keine "DYNAMIC" oder "COMPRESSED" row formats benutzen, sondern REDUNDANT oder COMPACT. Ob das seitens Contao einstellbar wäre weiß ich nicht.Zitat:
Enable this option to allow index key prefixes longer than 767 bytes (up to 3072 bytes) for InnoDB tables that use the DYNAMIC and COMPRESSED row formats. (Creating such tables also requires the option values innodb_file_format=barracuda and innodb_file_per_table=true.) See Section 14.8.8, “Limits on InnoDB Tables” for the relevant maximums associated with index key prefixes under various settings.
For tables using the REDUNDANT and COMPACT row formats, this option does not affect the allowed key prefix length.
Vielleicht muss man den key also tatsächlich noch weiter kürzen. Ob er dann noch viel bringt wird sich weisen und auch von der jeweiligen Installation abhängen. Das Schlimmste was passieren kann ist m.E., dass dann eben trotz angelegtem key ein full table scan durchgeführt wird bei manchen Abfragen. Was vor Einführung dieses key bei allen älteren Contao-Versionen sowieso der Fall war.
Vielleicht kannst du ja auch mal versuchen in Erfahrung zu bringen, ob Strato bei dieser Änderung versehentlich den SQL strict mode eingeschaltet hat. Ansonsten sollte es doch eigentlich bei einer Warnung und automatischen Verkürzung des keys bleiben.
Du hast völlig recht. Darauf habe ich gar nicht geachtet.
Ich habe in meiner Testinstallation mal die Tabelle tl-files umgestellt auf DYNAMIC, dann das Installtool aufgerufen.
Ergebnis kein Fehler und Datenbank lässt sich aktualisieren. Frontend und Backend scheinen fehlerfrei zu laufen.
Jetzt die Preisfrage an die Experten:
Welche anderen Probleme/Inkompatibilitäten etc. können damit enstehen.
Datenbanken sind nicht so ganz mein Fachgebiet.
Nachtrag: tl-files stand vorher auf COMPACT
Habe nur einenZitat:
Zitat von tab
innodb strict mode gefunden und der ist "off "
#Zwischendurcheinfachmaldankesagendasihrdadranblei bt !
Das ist was anderes, mit dem innodb strict mode kann man noch weitere Warnungen zu Fehlern machen.
So habe mir noch mal die weiteren Einstellungen des DB-Servers angeschaut.
Die Servervariable
sql mode steht auf NO_ENGINE_SUBSTITUTION
Wenn ich es richtig aus der Dokumentation rausgelesen habe, ist das ab MySQL 5.6.6 Standard.
Für den strict mode müsste da STRICT_TRANS_TABLES oder STRICT_ALL_TABLES verwendet werden. Demnach ist der strict mode nicht eingestellt.
Parallel habe ich noch einmal bei Strato nachgefragt, ob Sie Ihre Politik bei Shared Hostingpaketen nur noch InnoDB anzubieten nicht noch einmal überdenken wollen. Viel Hoffnung habe ich allerdings nicht.
Naja, im Prinzip hast du das Problem ja gelöst, auch wenn der Weg zur Lösung im Sinne von Contao nicht unbedingt optimal ist. Eigentlich will man ja nicht manuell an Tabellen rumkonfigurieren müssen, bis die Installation funktioniert. Aber bestimmt bekommen es die Core-Entwickler hin, das irgendwie zu automatisieren. Dass MyIsam nicht bis in alle Ewigkeit verfügbar sein wird, dürfte mittlerweile klar sein. Entwickelt wird da dran eh nichts mehr und mit MySQL 5.6 ist einer der Hautvorteile auch dahin. Bis dahin unterstützte InnoDB nämlich keinen Fulltext Search. Aber seit MySQl 5.6 hat sich das geändert.
Wenn die Umstellung auf DYNAMIC mir nicht bei irgendetwas anderem auf die Füße fällt kann ich damit leben.
Das Ändern der Tabelle in der Datenbank ist in dem Fall ja nahezu geschenkt.
Ich glaube aber für alle die bei Strato derzeit Contao neu installieren wollen ist das Problem nicht ganz so trivial zu lösen.
Da kann die Tabelle tl-files nämlich gar nicht erst erstellt werden.
Wenn man dann etwas rustikal und mutig vorgeht
- per Hand eine Tabelle tl-files anlegt, Warnungen, dass die Tabelle keine Struktur hat ignoriert
- dann auf DYNAMIC umstellt
- das Installationstool noch einmal aufruft
dann funktioniert es auch.
Ich hänge mich hier auch mal rein, bin heute selbst auf den Fehler "#1709 - Index column size too large. The maximum column size is 767 bytes." gestoßen.
Jetzt muss ich kurz doof fragen: Wie/was genau stellt man auf DYNAMIC um?
Kleine Anekdote aus dem Strato-Call-Center: "Da müssen Sie mal schauen, ob Contao überhaupt generell auf unseren Hosting Paketen läuft" - "Ihr habt das in euren 1-Klick-Installationen drin."- "Oh."
Hallo Kim,
in phpmyadmin gehen und dort die Tabelle tl-files auswählen.
Im Menü Operationen anklicken und unter Tabellenoptionen das ROW_FORMAT von COMPACT auf DYNAMIC umstellen und mit ok bestätigen.
Alternativ kann auch der entsprechende SQL-Befehl
ausgeführt werden.
Bei einer Neuinstallation war nur die Tabelle tl_files betroffen, ob das auch noch bei anderen Tabellen auftreten kann weiss ich nicht.
ich würde es auseinander schreiben .-)Code:ALTER TABLE `tl_files` ROW_FORMAT=DYNAMIC;
Ich bin jetzt etwas schlauer. Strato lässt nur noch innodb zu, meine Datenbank lieft bei netcup ebenfalls unter MySQL 5.6.33 und hat MyISAM. Das muss ich jetzt in innodb umwandeln, dann sollte es wieder klappen. Versteh ich trotzdem nicht ganz, denn es hakt ja nur an der tl_files. Der Strato-Support war aber auch etwas überfordert und meinte, das MyISAM einfach nicht mehr unterstützt wird. Das ist doch wirklich zum Davonlaufen, bei Strao, 1&1 und Konsorten rennt man doch JEDES MAL in irgend ein dämliches Problem :mad:
Seltsam finde ich, wenn ich (lokal) meine Tabelle mal als InnoDB anlege, wird automatisch dynamic eingestellt. Wieso/Wie mach Strato da compact?
Strato macht dir als Kollation auch latin rein.
Kurze Info: Trotz vorheriger Umwandlung von MyISAM zu InnoDB knallt es weiterhin an der tl_files. Der Weg scheint also doch zu sein, tl_files manuell anzulegen. Meine Güte, das kann's doch nicht sein :mad:
So müsste die richtig angelegt werden, InnoDB und DYNAMIC:
Code:CREATE TABLE IF NOT EXISTS `tl_files` (
`id` int(10) unsigned NOT NULL,
`pid` binary(16) DEFAULT NULL,
`tstamp` int(10) unsigned NOT NULL DEFAULT '0',
`type` varchar(16) NOT NULL DEFAULT '',
`path` varchar(1022) NOT NULL DEFAULT '',
`extension` varchar(16) NOT NULL DEFAULT '',
`hash` varchar(32) NOT NULL DEFAULT '',
`found` char(1) NOT NULL DEFAULT '1',
`name` varchar(255) NOT NULL DEFAULT '',
`meta` blob,
`uuid` binary(16) DEFAULT NULL,
`importantPartX` int(10) NOT NULL DEFAULT '0',
`importantPartY` int(10) NOT NULL DEFAULT '0',
`importantPartWidth` int(10) NOT NULL DEFAULT '0',
`importantPartHeight` int(10) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC AUTO_INCREMENT=1 ;
Mein echt umständlicher Schlüssel zum Erfolg:
Datenbank importieren, auf Fehlermeldung warten. tl_files laut Glens Anleitung manuell anlegen. Im Install-Tool die restlichen Datenbank-Tabellen anlegen lassen. Im phpmyadmin alle Tabellen leeren (nicht löschen!) und den gesamten Dump noch mal importieren.
Wenn jemand einen kürzeren Lösungsweg hat, wäre ich sehr dankbar dafür.
Wenn bereits eine Contao-DB vorhanden ist (Umzug von Entwicklungsserver auf Strato), dann finde ich das Ganze recht "unproblematisch".
- neue Datenbank bei Strato anlegen
- vorhandene SQL-Datei entsprechend ändern
(ENGINE bei CREATE TABLE 'tl_files' wie oben von Glen beschrieben)- SQL-Datei bei Strato importieren
- Installtool aufrufen
- Datenbankverbindung eintragen
Dann läuft es bei mir.
Wenn ich mich nicht sehr täusche, dann wird in irgendeinem der Threads zu diesem Thema doch beschrieben, wie man die geänderte Version einer Tabelle (tl_files) mit kürzerem key auch updatesicher in der dcaconfig.php eintragen kann. Geht sowas dann nicht auch mit der kompletten Tabelle?
Hallo. Ich lese mich gerade in das Thema ein und wollte mal nachfragen ob es schon neue Erkenntnisse zu dem Thema gibt?
Ich muss gerade eine Seite bei Strato neu installieren und eine bestehende übertragen. Bei der Neuinstallation hänge ich gerade, da ich keinen Zugriff auf das System habe. Der Umzug einer anderen Seite soll jetzt starten, habt ihr hier Erfahrungswerte?
Viele Grüße,
Kristin
Was Neues gibt es da m.E. nicht. Aber wie es dennoch geht steht doch oben alles drin.
Bei einer Neuinstallation ohne Zugriff aufs System würde ich mich glaub ich weigern. Nicht nur wegen Strato sondern grundsätzlich.Zitat:
Zitat von pretty-cool
Was verstehst du unter "keinen Zugriff aufs System"? Nicht mal FTP? Dann kannst du ja weder einen Umzug noch eine Neuinstallation durchführen. Ansonsten geht immer was ;).Zitat:
Zitat von pretty-cool
@tab - den FTP-Zugang habe ich schon bekommen. Ansonsten ist dieses Vorgehen übrigens nicht so ungewöhnlich bei Unternehmen, die einen Dienstleister für die Betreuung des Hostings engagiert haben. Über Sinn und Unsinn dieses Vorgehens lässt sich hier natürlich streiten. Habe ich aber schon öfter erlebt... ;-)
@mlweb - vielen Dank für die Rückmeldung. Ich probiere mich dann im ersten Schritt mal mit dem Umzug.
Ich meinte eben, dass man über den FTP-Zugang notfalls schon sehr viele Dinge machen kann. Man kann damit z.B. PHP-Skripte hochladen, die man über den Webserver dann ausführen kann. Damit könnte man z.B. eine passende tl_files in der Datenbank erzeugen. Umständlich, aber wenn der Kunde unbedingt dafür bezahlen will...
Komisch, habe ich bei meinen Kunden bisher nicht so erlebt.Zitat:
Zitat von pretty-cool
Ja stimmt schon. Aber wenn man eine saubere Struktur aufbauen möchte (für jede Domain bzw. Subdomain einen eigenen Ordner als root) fangen doch die Probleme an oder kann man da auch nur mit FTP Zugang etwas drehen von dem ich mal wieder nichts weiss?Zitat:
Zitat von tab
Hatte ich letztens mal, wobei dem Dienstleister gar nicht bewusst war, dass ich für die betreffende Domain gar kein document root einstellen konnte, obwohl ich die Zugangsdaten des Kunden hatte. Das heißt, auch unser gemeinsamer Kunde konnte das nicht einstellen. Vermutlich hat er die Berechtigungen mittlerweile angepasst, jedenfalls meinte er, das sei so nicht beabsichtigt gewesen. Offenbar machen seine Kunden sowas üblicherweise nicht. Sonst wäre es ja schon mal aufgefallen, dass es nicht geht. In dem Fall war es eine angenehme Zusammenarbeit mit dem Dienstleister, der mir dann eben kurz eingerichtet hat, was ich haben wollte. Wenn sich da einer absolut querstellt, dann hilft meist ein klärendes Gespräch mit dem Kunden.Zitat:
Zitat von mlweb
Im Prinzip ja, per .htaccess oder eventuell auch mit PHP, ist aber natürlich nicht optimal. Wenn es andere, sauberere Einstellmöglichkeiten gibt, dann sollten die eigentlich auch genutzt werden. Macht ja letztlich auch keinen Sinn, den Kunden "auszutricksen", auch wenn es meist möglich wäre. Der erwartet eine Dienstleistung von mir. Wenn ich dafür irgendwelche Einstellungen brauche und ich es nicht selbst einstellen darf, was ich in manchen Fällen auch durchaus verstehen kann, dann teile ich ihm mit, was ich benötige. Dann muss er eben dafür sorgen, dass die notwendigen Einstellungen von ihm selbst oder seinem zuständigen Dienstleister gemacht werden.Zitat:
Zitat von mlweb
Kurze Info, weil ich aufgrund meines Problems bei einem Umzug von Entwicklung (Mittwald) zu LIVE (Strato) auch das Problem mit der tl_files hatte:
DAS Problem konnte ich mit Euren Angaben lösen.
Bei mir waren aber auch alle auto_increments weg (angefangen mit tl_article) und ließen sich auch nicht setzen. Ist beim Duplizieren eines Artikels aufgefallen...
Ich habe jetzt erstmal ne alte MySQL 5.5 DB im selben Paket mitbenutzt...
Gruß
Marcus
Hallo,
also bei mir ist das Problem auf einem Strato-Server aktuell beim Update auf Contao 3.5.18 aufgetreten.
Ich habe, dem o.g. Rat folgend, die tl_files auf DYNAMIC gesetzt, wodurch die Aktualisierung funktionierte.
Anschließend erschien die gleiche Fehlermeldung aber noch einmal im Zusammenhang mit der Tabelle tl_search.
Hier funktionierte die Aktualisierung interessanterweise auch ohne, dass ich die Tabelle auf DYNAMIC gesetzt habe.
Beim Neuaufbau des Suchindexes wurden jedoch nur noch die URLs einer meiner Domains (ich betreibe die Installation als Multidomain) als indiziert (also grün) markiert.
Sämtliche URLs der zweiten Domain wurden rot und mit [0] vorweg dargestellt, also z.B. [0] http://www.zweitedomain.de.
Auch das Einloggen ins Backend über die zweite Domain brachte keine Lösung.
Zwar wurden nun sämtliche URLs der ersten Domain rot und mit [0] markiert, der Aufbau der URLs der zweiten Domain funktionierte aber auch nicht.
Hier erschien keine Fehlermeldung, aber das Ladesymbol drehte und drehte sich eine halbe Ewigkeit, bis ich den Prozess dann abgebrochen habe.
Unter 3.5.14 funktionierte der Neuaufbau des gesamten Suchindexes beider Domains noch schnell und problemlos.
Ich habe dann tl_search ebenfalls auf DYNAMIC gesetzt, aber danach funktionierte der Neuaufbau gar nicht mehr und sämtliche URLs wurden rot dargestellt.
Also habe ich die Installation noch einmal auf den alten Stand gesetzt und nun gleich tl_search auf DYNAMIC gesetzt mit der Folge, dass statt [0] bei der ersten URL [500] stand und sich das Ladesymbol danach wieder ewig drehte.
Dieses Problem scheint also für Stratokunden doch etwas dramatischer zu sein.
Natürlich könnte man die Aktualisierung der Tabellen unterlassen, aber es ist doch irgendwie unschön, wenn dort permanent eine Aktualisierungsmeldung auftaucht, die man ignorieren muss.
Außerdem habe ich für meinem Kunden gerade einen Live-Update-Schlüssel zwecks eigenständiger Systemaktualisierung erworben und es ist nur eine Frage der Zeit, bis ihm das System um die Ohren fliegt, weil er versehentlich doch die Tabellen aktualisiert.
Viele Grüße
Jay
Für das Aufbauen des Suchindex bei Multidomain Installationen musst du spezielle Vorkehrungen treffen. Siehe zB https://community.contao.org/de/show...n-InstallationZitat:
Zitat von SoLucido
Siehe https://github.com/contao/core/issues/8541Zitat:
Zitat von SoLucido
Dann ist wohl die bessere Lösung, den Index einfach entsprechend kürzer zu machen und das (in der initconfig.php?) einzutragen.
Hi Spooky,
danke für die Rückmeldung.
Unter 3.5.14 auf einem 1&1-Server ging es, so wie ich es eingestellt habe, noch problemlos.
Das Problem taucht, wie gesagt, erst auf, seit die Seite bei Strato liegt und die von mlweb ausführlich beschriebenen Einschränkungen bzgl. InnoDB vorliegen.
Kann man da in der Entwicklung denn gar nichts machen?
Mein Kunde ist ja offensichtlich nicht der einzige Stratonutzer.
Es können doch jetzt nicht alle Stratokunden den Provider wechseln und immerhin hat mein Kunde für das Live-Update bezahlt, kann es jetzt aber nicht nutzen.
Viele Grüße
Jay
Welches Problem genau?Zitat:
Zitat von SoLucido
Warum? Welches Problem hast du mit dem Live-Update?Zitat:
Zitat von SoLucido
Nun, wenn Strato einfach mal Nicht-Abwärtkompatible Änderungen vornimmt, dann passiert nun mal so etwas.
Contao hat MyISAM als Basis und nicht InnoDB. Es gibt ja Möglichkeiten es trotzdem darunter zum Laufen zu bekommen, aber das Bedarf eben Handarbeit.
Siehe Beiträge zuvor hier von mir.
Was ich grundsätzlich nicht verstehe ist ein Wechsel von 1&1 zu Strato. Das ist ja wie das Austreiben des "Teufels mit dem Beelzebub".Zitat:
Zitat von SoLucido
Wobei ich persönlich noch bessere Erfahrung mit 1&1 habe als mit Strato.
@Spooky: Na das Thema, in dem es hier in dem Beitrag die ganze Zeit geht ;) s. diverse Beiträge von mlweb zu: ALTER TABLE `tl_files` ADD KEY `path` (`path`(333));
@BugBuster: Es ist natürlich wirklich ärgerlich, dass Strato diese Einschränkungen hat. Mir würde auch nur eine Antwort seitens der Entwicklung reichen, ob das Problem mit der Feldlänge gefixt wird oder nicht. In einem anderen Beitrag, den ich aber leider nicht wieder finde, erschien mir eine Antwort von Leo Feyer auch zu sein, dass es nicht schwierig zu lösen sei. Meine Frage ist lediglich, ob es umgesetzt wird oder nicht, bevor ich irgendetwas verbiege.
@mlweb: Tja, das frag mal den IT-Heini meines Kunden. Es gab wiederholt E-Mail-Probleme bei 1&1 wegen Blacklists und da hat dieser vermeintliche EDV-Spezialist die Website kurzerhand zu Strato umgezogen. Ich dachte, ich spinne, als ich das erfuhr, vom Regen in die Traufe. :eek:
In deinem ursprünglichen Post hattest du auch von weiteren Problemen gesprochen, die nichts mit diesem Thema hier zu tun haben.Zitat:
Zitat von SoLucido
Deine Fragen und Anmerkungen solltest du direkt hier posten: https://github.com/contao/core/issues/8484Zitat:
Zitat von SoLucido
Hier im Forum bringt es eher nichts.
In meinem ursprünglichen Post habe ich berichtet, dass das exakt gleiche Datenbankproblem bei Strato, über das hier in diesem Thread geschrieben wird, auch bei mir aufgetreten ist und ich die gleiche Fehlermeldung wie bei der tl_files- auch bei der tl_search-Tabelle hatte. Also hatte mein Beitrag mit diesem Thema sogar sehr viel zu tun.Zitat:
Zitat von Spooky
Ach so, weil ich hier auf eine Fehlermeldung geantwortet hatte, dachte ich, das Forum wäre auch zum Posten von Fehlern gedacht und die Moderatoren würden mit dem Entwickler in direktem Kontakt stehen.Zitat:
Zitat von Spooky
Okay, danke für die Info und den Link. Dann schau ich mal auf GitHub vorbei.
In deinem ursprünglichen Post hast du 3 verschiedene Probleme angebracht:Zitat:
Zitat von SoLucido
Zitat:
Zitat von SoLucido
Zitat:
Zitat von SoLucido
Daher meine Frage, welches Problem du meinst.Zitat:
Zitat von SoLucido
Es empfiehlt sich generell nicht mehrere Probleme im selben Thread (und noch dazu im selben Post) zu posten. Dadurch wird der Thread mit Diskussionen zugemüllt, die mit dem ursprünglichen Thema eigentlich nichts zu tun haben.
Für die Moderatoren kann ich nicht sprechen. Ich zumindest mache das tlw. schon - das erwähnte GitHub issue wurde bspw. von mir aufgrund von Posts im Forum erstellt :). Trotzdem bringt es natürlich immer mehr weitere Anmerkungen oder Diskussionspunkte direkt im GitHub Issue anzubringen.Zitat:
Zitat von SoLucido