Für alle nur zu Info. Ich habe beim Test von Contao 4.5 bei Webgo Paket Platin festgestellt, dass die Option innodb_large_prefix nicht aktiv ist.
Beim Support wurde dazu ein Ticket erstellt.
Ich melde mich sobald ich weitere Infos bekommen.
Druckbare Version
Für alle nur zu Info. Ich habe beim Test von Contao 4.5 bei Webgo Paket Platin festgestellt, dass die Option innodb_large_prefix nicht aktiv ist.
Beim Support wurde dazu ein Ticket erstellt.
Ich melde mich sobald ich weitere Infos bekommen.
Nur als ergänzende Info: Es besteht übrigens die Möglichkeit, auch weiterhin MyISAM und utf8_unicode_ci als Datenbank-Engine und -Collation zu benutzen, indem man die Datenbankkonfiguration in der app/config/config.yml entsprechend anpasst: https://github.com/contao/managed-ed...b-large-prefix
Das wäre überall dort relevant, wo derzeit noch kein InnoDB zur Verfügung steht oder man die erforderlichen Settings nicht (selbst) anpassen kann.
Und Cache Clearen über die Konsole oder den Manager nicht vergessen nach Änderungen in der config.yml :D
Ich habe heute nachfolgende Antwort von Webgo bekommen:
"Diese Option war noch nicht korrekt in MariaDB gesetzt, ich habe dies nun angepasst und die Meldung sollte nun verschwinden."
Ich habe es gerade getestet und es hat bei mir wunderbar funktioniert.
Hallo, ich möchte dieses Thema noch mal hochholen, da WebGo bei mir die Tage zwar ein Update der MySQL-Datenbank auf Version 5.5.58 durchgeführt, aber die innodb_large_prefix-Option weiterhin nicht aktiviert hat. Auch die anderen Optionen (innodb_file_format und innodb_file_per_table) sind noch nicht korrekt gesetzt.
Das ist mir leider erst aufgefallen, nachdem ich mittels Install-Tool die Datenbank vollständig auf InnoDB umgestellt hatte und ich heute bemerkt habe, dass seitdem weder Suchindex noch Seitencache generiert werden. Ein Ticket bei WebGo habe ich diesbezüglich bereits gestellt.
Leider habe ich es über die config.yml noch nicht hinbekommen, die Umstellung rückgängig zu machen, damit zumindest die Seitensuche wieder funktioniert. Evtl. hat da jemand Erfahrungen mit!?
Die Seitensuche hat damit nichts zu tun. Versuche es außerdem mal mit MariaDB anstatt MySQL.
Danke Spooky für die schnelle Antwort und den MariaDB-Tipp. Seit meinem Paketwechsel bei WebGo fehlt diese Option anscheinend bei mir. Ich kläre das mal ab und gebe dann Feedback.
Das mit der Seitensuche kann ich mir auch nicht erklären, allerdings hat sie unter Contao 4.4 noch funktioniert.
Unter Contao 4.4.13 funktioniert die Suche derzeit nicht. Auch nicht unter Contao 4.5.3 glaube ich.
Dank deines Hinweises und dieses Tickets (https://github.com/contao/core-bundle/issues/1337) konnte ich jetzt den Fix für 4.5.3 erfolgreich anwenden: https://github.com/contao/core-bundle/issues/1337
Der Seitencache funktioniert allerdings weiterhin nicht. Auch nicht in einer extra frisch installierten Contao-Version. Aber wie ich gerade gelesen habe, scheint das ein Symphony-Problem zu sein: https://github.com/contao/core-bundle/issues/1302
Ja, derzeit muss man leider noch eine Weile ohne Seitencache auskommen.
Bei netcup ist das im Shared Hosting auch nicht möglich. Ich hab die config.yml angepasst (https://github.com/contao/managed-ed...b-large-prefix), doch das führt dazu, dass ich den Symfony-Cache nicht neu erstellen kann:
Hab ich da was falsch gemacht? Den Code aus dem Github-Beispiel hatte ich 1:1 übernommen.Code:bash-4.1$ /usr/local/php71/bin/php vendor/bin/contao-console cache:clear -e=prod
In ArrayNode.php line 319:
Unrecognized options "doctrine, dbal" under "contao"
Bin jetzt von 4.5.3 auf 4.4.13 zurück.
Poste deine config.yml
Code:# Contao configuration
contao:
url_suffix: ''
doctrine:
dbal:
connections:
default:
default_table_options:
charset: utf8
collate: utf8_unicode_ci
engine: MyISAM
So ist es richtig:;)Code:contao:
url_suffix: ''
doctrine:
dbal:
connections:
default:
default_table_options:
charset: utf8
collate: utf8_unicode_ci
Und auf MyISAM musst du vermutlich auch nicht zurück steigen.
Ach, die Einrückung?! :o
Ja, doctrine: war eingerückt.
Ein Jahr später muss ich das jetzt auch mal auf dem Hostingserver eines Kunden monieren. Bei MySQL-Datenbank ist innodb_large_prefix gesetzt, bei MariaDB nicht. :rolleyes:Zitat:
Zitat von mlweb
Ich habe einstweilen die MariaDB gelöscht und wieder eine MySQL erzeugt, habe seither wohl gewohnheitsmäßig MySQL genommen. Aber das kanns doch eigentlich nicht sein.
Aber sollte ja dann problemlos möglich sein, die DB zu exportieren und in eine neue MariaDB zu importieren, sobald die Option aktiviert ist. Offenbar ist jeder Server ein Unikat. :D Von HTTP/2 auch noch keine Spur. Ich weiss nicht, ich würde doch versuchen, alle Server auf dem selben Stand zu haben, da tut man sich ja bei Änderungen wesentlich leichter als wenn man jedes Mal die Einstellungen erst mal checken muss als Admin. Aber ist natürlich auch erst mal Arbeit dahin zu kommen.
Edit: Das "sicherheitstechnisch bedenkliche" node.js ist auf dem Server auch noch installiert. ;)
Hatte heute auch gerade mal wieder einen Kundenpaket am Wickel bei dem innodb_large_prefix nicht aktiv war.
Manchmal nervt es, dass bei Webgo jeder Server ein Unikat zu sein scheint.
Wollen wir mal hoffen, dass Webgo bei den neuen Kundenpaketen aus dem Chaos bei den alten Aktionspaketen (Silber/Gold/Platin/CMS Pro/CMS Power) gelernt hat. Die sind ja auch deutlich teurer.