Kommentare von

Also ist die Struktur auf Hosttech ok. PHPMyAdmin bildet ja nur ab, was ist. Ist die comments Tabelle aus dem dump vor der Migration oder so wie sie jetzt ist?
Warum also ist ein Dump, der dann soweit OK aussieht, auf der neuen Dokumenzi DB falsch bezüglich der 4-Byte Zeichen, der Emojis? (Siehe Kästchenfrage in Notepad++)
Um das dokumenzi Problem zu lösen, musst du also den zur Verfügung gestellten Dump untersuchen und punktuell vergleichen mit der Struktur die jetzt als DB vorliegt (ohne dump). Denn das ist ja das, was sie bzw. nachfolgend du drauf gekippt haben. Ist der Dump soweit ok kann eigentlich auch nichts dergleichen geschehen. Sind die Tabellen gelöscht worden bevor der dump darauf entladen wurde? Irritierend finde ich auch, dass es sich als MariaDB 10.2.37 ausgibt. Das ist so ähnlich wie die openssl Versions Geschichte und passt überhaupt nicht zu einer Server-UPGRADE-Migration mit der sie ja schon soooowoesooooo schon lange gewartet haben. Zu erwarten wäre Minimum 10.3 wenn nicht schon .4 oder .5, da schon das sehr konservative Debian stable auf 10.3.x ist. Das dahinter jemand zurückfällt fällt mir schwer nachzuvollziehen. 🙄

Zum Zweiten:
Warum fehlen Manitu (was ja ursprünglich mit deinem dokumenzi Migrations Problem nichts zu tun hat) die COLLATE utf8mb4_unicode_ci Auszeichnungen?!?

In PHPMyAdmin kannst du ja jeden table auch als Struktur ansehen, dort siehts du es so wie es nachher auch im Dump zu finden wäre. Wenn dort nichts dergleichen steht, fehlen sie. Außerdem muß man den Dump als utf8 abgespeichert ziehen (aber das sollte eigentlich schon automatisch gesetzt sein).

Es geht doch um den Dump vom hosttech Server. Siehst du in ihm die oben angemerkten Kästchen (unter Notepad++) wo die Emojis stehen??

Check mal die Mainitu Struktur. Ist sie tatsächlich so wie es der dump screenshot bezüglich der Kollationen aussagt?
Wenn du das bestätigst, ist desweiteren die Frage wie das denn sein kann. Wie genau ist diese Datenstruktur dort bei Manitu entstanden? War es eine Kopie einer alten von Anno Domini von hosttech? Ein Mischmasch, zwischen neu installierter Struktur und alten Daten? etc.?

Das ist verwirrend, ich weiß. Aber es gibt einfach ein paar Dinge auseinanderzuhalten. UTF8 als Beschreibung und Name ist eigentlich das was Mysql als UTF8MB4 versteht. Das ist einer der (historischen) Eigenarten von Mysql dass sie damals UTF8 für einen Raum benutzten ohne diesem den vollständigen unicode Satz zu geben. Überall sonst meint also der Name UTF8 eben den erweiterten Satz mit den inkludierten Bytes. Solch ein Byte, zb Emojis, sind belegte 4 Zeichen, die ein einzelnes Zeichen aus diesem erweiterten Unicode beschreiben, also 4 Byte je Zeichen. Hat also eine Datenbank die Anweisung 4-Byte pro Zeichen zuzulassen muss sie auch so zählen - was insbesondere wichtig ist für die Indizes, also die gecachten "Tabellen" zur schnelleren Indizierung bei Datenabfragen und Suchabfragen. Ohne diese wären Datenbanken grottig langsam und das zunehmend.

Nun speichert also zb phpmyadmin eigentlich als UTF8, wenn utf-8 für den Export gesetzt ist. (Trotzdem bitte noch mal nachkontrollieren ob es das auch bei dir macht.). So eine sql Datei hat dann eine versteckte Zeichenfolge, eine Byte Order Mark (BOM), am Dateianfang, die die Verwendung von UTF-8 als Kodierung kennzeichnet. Notepad++ liest das und weiß, dass es sich um UTF8 handelt. Darstellen kann es die erweiterten Zeichen aber nicht. Du wirst keine Emojis sehen, aber dafür ihren Platzhalter, also das ominöse umrandete Kästchen von dem ich sprach. Ist es nicht da und an dessen Stelle nur ein ? ist das 4-Byte Zeichen nicht erkannt bzw kaputt. Kaputtes aber kann man nicht so wieder in eine DB importieren so das daraus wieder komplette 4-Byte Zeichen werden. Deshalb sagte ich, dass ein Export der unzureichend war nicht zur Weiterverarbeitung taugt, außer man nimmt den Verlust in Kauf.

Ich meine das es eigentlich ausreichend wäre/ist, wenn die Kollation der Text Felder (wie schon beschrieben) in den Tabellen utf8mb4_irgendwas (ebenfalls wie beschrieben) ist. Das die ganze DB von vorrnherein so deklariert wird, ist nur dann möglich, wenn man selbst komplett dazu berechtigt ist, was wahrscheinlich bei Hostern nur eher bedingt der Fall sein wird. Bezüglich Kollationen und charsets haben wir also generelle Einstellungen für den Server und den Client, also eher sehr globale Einstellungen, spezifische Datenbankeinstellungen, denn ein Datenbanksystem kann ja mehrere Datenbanken haben, Tabelleneinstellungen die für die Tabellen selbst gelten und Einstellungen der einzelnen Felder in den Tabellen. Das sind die granulierten Abhängigkeiten, meine ich.

Vielleicht irre ich mich diesbezüglich auch und die Export/Import Frage ist doch von der globalen Einstellung abhängig. Geschrieben hatte ich die Datenbank Preparation für eine Styx Installation so: https://ophian.github.io/hc/en/preparing-db.html

Was steht denn im zur Verfügung gestellten Dump und deinen Dumps die du selbst hier gezogen hattest am Anfang bei

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

Das 40101 ist dabei nur ein comment, der besagt, es nicht unterhalb mysql versionen 4.1.1 zu installieren. Der set names Befehl aber ist wichtig.

Laienmässig sage ich, dass ich ein Problem zwischen Styx und der Speicherung in der DB habe. Denn, wenn ich jetzt Emojis in einen Beitrag/Kommentar schreibe und diesen speichere, so sehe ich Sekunden später mit phpMyAdmin in der DB nur noch Fragezeichen.

Das verstehe ich nicht - auch nicht vom Sinne her. Denn wenn, dann dürftest du dieses Emoji 🤔 nicht sehen können, weder hier im blog comment, noch in der aufgeklappten pma Tabellenansicht, noch in der pma Bearbeitungsansicht für ein comment. Und wenn, dann hätte es bisher ja auch nicht geklappt.. 🧐

Nanu ????

Das ist nicht wirklich möglich - hagelnde Fehler wären dann auch schon bei 8.0.0 und 8.0.1 aufgetreten. Das sind nur Minor PHP 8 Versionen die Bugs fixen. Ich bin schon seit 2 Monaten auf PHP 8.0.3 und gerade eben auf 8.0.5 umgestiegen. Und ich finde nur noch sehr vereinzelt irgendwelche warnings, geschweige denn Fehler.

Es wäre also gut wenn du das noch mal anstellst und ich mir das ansehen kann. Und gerne auch hier behandeln, denn das mit den neuen Styx discussions betrifft dich gar nicht, so du doch eine so schicke Testinstallation hast.

Ich nehme mal an es hätte einfach einen ordentlichen Seitenreload gebraucht.

Doch wahrscheinlich hängt das (auch?) mit dem Nginx Proxy zusammen, der müsste dann mit der neuen Konfiguration ersteinmal vollständig durchgeladen werden.

In eingeloggtem Zustand kann ich nicht in einem zweiten Fenster kommentieren. Ich erhalte die Error-Page mit folgendem Hinweis:

Warning: Undefined array key "phone" in /plugins/serendipity_event_spamblock_bee/serendipity_event_spamblock_bee.php: 411.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.