Solved K6.1 Konfigurationsbericht erstellen und speichern

rich wrote:

Dann zeigt es der Konfigurationsbericht richtig an. Wie diese Änderung zu utf8mb3 zustande kam, ist mir ein Rätsel. Kunena erstellt bei einer Neuinstallation, als auch bei Migrationen ausschließlich Tabellen mit Kollation utf8mb4.
Vielleicht wurde es von dieser Erweiterung, die du irgendwo erwähnt hattest, geändert.

 

Das Ganze ist mir auch ein Rätsel. Welche Programme oder Erweiterungen, außer Kunena, würden auf diese drei Felder zugreifen und evtl. die Stuktur ändern?
Ich war gerade bei STRATO und habe mir im Kundenlogin die Datenbank angesehen. Ich habe mir von jeder Kunena Tabelle die Stuktur angesehen und überall, wo eine Kollation eingetragen ist, steht utf8mb4_unicode_ci. Die Ausnahme machen die Felder alias, filename und filename_real. Diese Felder haben als Kollation utf8_general_ci  eingetragen.
Das kann doch eigentlich nur von Kunena eingetragen worden sein.
Ich könnte mir vorstellen, daß bei der Installation von K6.1 irgendeine Routine die Datenbankeinträge checkt und meint daß utf8_general_ci keine gültige Kollation ist weil kein "mb" und die default Kollation von MySQL einträgt.
Andererseits könnte ich mir auch vorstellen, daß Kickstart beim entpacken und installieren des Backup die falsche Kollation erkennt und gegen eine utf8mb(X)_unicode_ci Kollation austauscht und dabei die erste Kollation in der Reihe nimmt und das wäre utf8mb3_general_ci.
Das werde ich mal testen. Ich ändere in einer Testversion von k6.0.9.1 die Kollation dieser drei Felder in utf8_general_ci, mache dann ein Backup von dieser Testversion und erstelle eine neue Testversion. Dann sehen wir ob es beim backup passiert.

Gruß Gindi
 

Ich habe jetzt getestet. Ich wollte in einer Testinstallation die Kollation von alias, filename und filename_real in utf8_general_ci ändern. Das war aber nicht möglich, weil es keine utf8 Liste mehr gibt.  Dann habe ich in der Livesite bei STRATO die Datenbank mit phpMyAdmin exportiert und , nachdem ich in der Testinstallation die Datenbank gelöscht habe, die Datenbank von der Livesite dort importiert. Zu meiner Überraschung war die Kollation dieser drei Felder nicht mehr utf8_general_ci sondern utf8mb3_general_ci.
Ich hatte auch auf der Livesite einen Konfigurationsbericht erstellt und abgespeichert. Dieser wurde ohne Irgendeine Meldung so abgebildet, wie es sein soll.
Das liegt wahrscheinlich daran, daß auf der Livesite MySQL version: 5.7.38-log (Server type: mysql) installiert ist.
Auf meinem LAMP server hat MariaDB vermutlich eine Version installiert, die MySQL 8 entspricht.

Ich habe bei STRATO die Kollation dieser drei Felder in utf8mb4_unicode_ci geändert, sodaß künftige Backups der Livesite hier mit der richtigen Kollation installiert werden.
Damit werden Meldungen zum Kollationscheck jetzt nicht mehr kommen und das Thema zu dieser Meldung wäre erledigt.
Mich würde schon interessieren, wieso dieser Check bis zu k6.0.9.1 keine Meldung brachte aber ab Version K6.1 meldete er das Problem?

Gruß Gindi
 

Mich würde schon interessieren, wieso dieser Check bis zu k6.0.9.1 keine Meldung brachte aber ab Version K6.1 meldete er das Problem?

Das weiß ich leider auch nicht, es kann alles mögliche sein. Es gibt Fehler, die treten einmalig auf und wenn sie mal behoben sind, nie wieder auftreten.

Ich habe da was gefunden, was möglicherweise die Unterschiede gemacht hat.
In /administrator/components/com_kunena/src/Model/ToolsModel.php wird der Konfigurationsreport erzeugt.
Bei Kunena 6.0.9.1 wird die Datenbank mit $kunenaDB  = Factory::getContainer()->get('DatabaseDriver');
und bei Kunena 6.1 wird die Datenbank mit $kunenaDB  = $this->getDatabase();
abgefragt.
Die Abfrage  '[confdential]

[Database collation check: '  ist bei beiden Versionen gleich.

Gruß Gindi
 

Wenn du es tatsächlich wissen willst, ob früher deine mb3 Einträge nicht erkannt wurden, dann ändere den Code zurück, und probiere es aus.
Tatsache ist, dass diese Einträgge in der Datenbank vorhanden waren und beim Konfigurationsbericht erstellen mit der BETA2 als solche erkannt wurden.