Export/Import Datenbank

Achtung lese auch im Backend.

Eigentlich sieht das ja entsprechend gut aus mit den  40101 Zeilen...

Bitte paste mal aus der dump.sql Datei die Datenbank-Struktur des comments tables als Beispiel. Vielleicht sind bei dir die Kollationen falsch gesetzt. Meine sieht zB. so aus:

CREATE TABLE `styx_comments` (
  `id` int(11) NOT NULL,
  `entry_id` int(10) UNSIGNED NOT NULL DEFAULT 0,
  `parent_id` int(10) UNSIGNED NOT NULL DEFAULT 0,
  `timestamp` int(10) UNSIGNED DEFAULT NULL,
  `title` varchar(150) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `author` varchar(80) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `email` varchar(200) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `url` varchar(200) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `ip` varchar(64) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `body` longtext COLLATE utf8mb4_unicode_520_ci DEFAULT NULL,
  `type` varchar(100) COLLATE utf8mb4_unicode_520_ci DEFAULT 'regular',
  `subscribed` enum('true','false') COLLATE utf8mb4_unicode_520_ci NOT NULL DEFAULT 'true',
  `status` varchar(50) COLLATE utf8mb4_unicode_520_ci NOT NULL,
  `referer` varchar(200) COLLATE utf8mb4_unicode_520_ci DEFAULT NULL
) ENGINE=Aria DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;

Auch wenn bei dir nur utf8mb4_unicode_ci stünde wäre noch alles in Ordnung. Alle Felder die etwas mit Text zu tun haben, also text oder varchar Felder, müssten eine Kollation für utf8mb4 aufzeigen. Selbst bei utf8mb4_general.ci, denn https://www.pixelfriese.de/unterschied-zwischen-utf8_general_ci-und-utf8_unicode_ci/

Wenn  du den Dump in notepad++ betrachtest, müsste du an den Stellen an denen Emojis verwendet werden, ein kleines (umrahmtes) Kästchen sehen, a la "<p>&nbsp; 🔗 If you use issue" (in der Übertragung ist hier daraus ein Kettenglied geworden) das anzeigt, dass dort ein 4-Byte Zeichen hockt. Ist das nicht so kannst du schon recht sicher sein, dass du den Dump nicht zufriedenstellend verwenden wirst können.

Deinen Live Blog mt diesem Testblog zu vermischen ist auch keine wirklich gute Idee und führt zu Fehlern und Verwirrrungen, wie du schon erlebt hast.

Es ist eben durchaus möglich, dass dein dokumenzi blog gerade was die SQL Struktur angeht noch etwas bedürftig ist, denn es stammt ja aus der Zeit in der versucht haben einem System das noch nicht bereit dafür war einen entsprechenden Überzug zu verpassen und du demzufolge mit Strukturen und Inhalten herumexperimentert hast, will sagen: Dass es keine eigene neue Installation auf gefügigem Grund war, bzw nicht die in Styx gegebene Konvertierungs/Migrations Wartungsaufgabe einer alten DB benutzt hat.

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.. 🧐