Bild-Elemente nach Webspace-Wechsel wie von Zauberhand komplett gelöscht

Ich habe hier gerade einen sehr eigenartigen Effekt erlebt:

Ich habe eine Neuinstallation einer 3.2.7 gemacht und auf der Basis lokal in XAMPP eine kleine Website hochgezogen. Nachdem ich damit fertig war, habe ich die Website auf den Webspace übertragen. Zuvor habe ich lokal noch die Systemwartung aufgeräumt und die Dateien synchronisiert (meine übliche Vorgehensweise bevor ich ein Backup erstelle).

Nachdem ich auf dem Webspace die Datenbank und alle FTP-Daten auf den Webspace geladen sowie die localconfig/pathconfig angepasst hatte, schaute ich sie mir im Frontend an. Mir fiel sofort auf, dass sämtliche Bilder nicht mehr angezeigt wurden. Im Backend habe ich mich in die Dateiverwaltung eingeloggt und nochmal synchronisiert. Contao meldete sämtliche Ordner und Dateien als neu bei der Synchronisation!

Krasser wurde es dann noch, als ich auf die Seiten ging, wo die Bilder eingebunden waren. Ich erwartete, dass vielleicht die Bildzuweisungen fehlen, wie das manche Leute nach einem Update berichten (wenngleich ich hier ja kein Update, sondern nur einen Webspace-Wechsel hatte).

Aber alle Bild-Inhaltselemente waren einfach weg! So als hätte sie jemand von Hand vorm Wechsel gelöscht (was definitiv nicht geschehen ist, da nur ich an der Seite arbeite). Ich musste dann tatsächlich alle Bild-Inhaltselemente komplett neu anlegen.

Hat jemand eine Idee was da passiert ist? Sowas ist mir ja noch nie untergekommen ...

// Contao-Check ist natürlich in Ordnung.

Upps, das ist ja wirklich krass. Dass Bilder mal "verlorengehen", das kennen wir ja schon, aber ganze Inhaltselemente?
Hast du schon mal in die Datenbank reingeschaut, sind die Elemente da noch drin? Ansonsten vielleicht nochmal die Datenbank online neu einspielen, eigentlich dürfte es da ja keine Unterschiede zur lokalen DB geben. Vielleicht ist beim ersten Einspielen ein Fehler passiert und der Dump nicht komplett importiert worden.

Sieht auf den ersten Blick alles "normal" aus in der DB. Ich hatte bisher drei Inhaltselemente-Typen angelegt: Überschriften, Text, Bild.
Nach dem Wechsel fehlten ausschließlich die Bild-Elemente.

Total absurd. Na ja, ich muss die Seite von diesem Webspace eh gleich nochmal auf einen anderen Webspace verlegen (diesmal zum Kunden). Mal schauen, ob es diesmal problemlos klappt.

Korrigiere, da ist doch etwas faul in der Datenbank. Ich versuchs gleich mal aufzuschreiben.

Ursprungsort (lokales XAMPP, MySQL 5.6.14) an dem die Neuinstallation der 3.2.7 stattfand und die Website ganz frisch gebaut wurde:

Wenn ich mir in phpMyAdmin die Ursprungstabellen für tl_content und tl_files ansehe, sieht alles normal aus.
Schau ich mir die Struktur der Tabellen an, steht bei Kollation sauber utf8_general_ci.
Auf der Startseite von phpMyAdmin steht als Server Zeichensatz UTF-8 Unicode (utf8).

Soweit wirkt also alles normal.

Beim Exportieren der Datenbank habe ich darauf geachtet, dass die Zeichencodierung der Datei utf-8 ist.

Jetzt gibt es die ersten Auffälligkeiten:

Exportiere ich so, dass mir eine .sql-Datei zum Speichern angeboten wird, fallen mir gleich mehrere Dinge auf, wenn ich diese dann wie gewohnt danach mal in PSPad aufmache:

1. Es gibt Zeichensatzfehler. Das Ü wird plötzlich zum Ãœ usw.
2. Wenn ich mir in der tl_content den Eintrag zu den Bildern ansehe, steht da sowas drin:

Code:

---

(17, 4, 'tl_article', 256, 1392369799, 'image', 'a:2:{s:4:"unit";s:2:"h1";s:5:"value";s:0:"";}', NULL, '', '|%G#•Yã¼Ó\0ÿ±
', 'Logistik weltweit', '', 'a:3:{i:0;s:0:"";i:1;s:0:"";i:2;s:12:"proportional";}', 'a:5:{s:6:"bottom";s:0:"";s:4:"left";s:0:"";s:5:"right";s:0:"";s:3:"top";s:0:"";s:4:"unit";s:0:"";}', '', '', '', 'above', NULL, '', NULL, NULL, '', '', '', '', '', 0, 'ascending', '', '', '', '', '', NULL, '', '', '', '', '', '', '', NULL, NULL, '', 4, 0, 0, '', '', NULL, '', NULL, '', '', 0, 300, 0, '', 0, 0, 0, 0, 0, '', NULL, '', 'a:2:{i:0;s:0:"";i:1;s:0:"";}', 'a:2:{i:0;s:0:"";i:1;s:0:"";}', '', '', '', 'ascending', 0, '', '', '', '', 'com_default', NULL, '', '', '', 0, '', '', '', 5, 'bottom', 'center', '', '', '', '', '', '', '', ''),

---

Beachtet die zerschrottete Angabe an der Stelle wo die UUID steht. In der phpMyAdmin-Ansicht sieht das noch normal aus und ist die übliche UUID des Bildes. Hier ist das nur noch Chaos.

Ein entsprechendes Pendant aus der tl_files sieht so aus:

Code:

---

(36, 'èÎjã”Ö㇟\0ÿ±
', 1392313649, 'èÎj5”Ö㇟\0ÿ±
', 'file', 'files/images/slider/XXXX.jpg', 'jpg', '99a03f6605d389d8875e0c3cec615a9c', '1', 'XXXX.jpg', 0x613a313a7b733a323a226465223b613a333a7b733a353a227469746c65223b733a31393a224c6f67697374696b2070657220536368696666223b733a343a226c696e6b223b733a303a22223b733a373a2263617074696f6e223b733a303a22223b7d7d),

---

Ich habe dann mal alternativ so exportiert, dass die Export-Infos nicht als File zum Download angeboten, sondern in einem Textfeld in phpMyAdmin ausgegeben werden:

Solange die Exportdaten so als Text auf dem Server angezeigt werden, wirken sie wieder normal.

ABER: Hier fehlen nun plötzlich sämtliche Inhaltselemente die eine der UUID-Angaben enthalten. Trifft im aktuellen Fall die Bilder, wäre aber vermutlich auch bei Element Download o.ä. (immer wo die UUID zum Einsatz kommt) auch der Fall, nur dass ich die eben in der Seite nicht genutzt habe.

Und es fehlen sämtliche Insert-Einträge aus tl_files. Komplett.

Da ich vorhin die zweite Export-Variante gewählt habe, erklärt das die erneut nötige Datensynchro sowie die fehlenden Elemente.

Unklar ist mir aber natürlich die Ursache.

Im ersten Moment dachte ich, dass mein lokales XAMPP vielleicht einen Schuss hat, wobei mir das nicht logisch erschien, da ich wirklich ganz genau drauf geachtet hatte, dass überall UTF-8 eingestellt ist. Hab sogar extra nochmal die mysql.ini und die phpMyAdmin-Konfig gecheckt. Es ist wirklich überall auf UTF8 gestellt.

Wie eingangs beschrieben, habe ich das Backup online auf einen Webspace (bei All-Inkl) gespielt (natürlich zuvor die Kollation der DB dort auch auf UTF8 gestellt und darauf geachtet, dass der Import als UTF8 geschieht) und hatte dort dann eben keine Infos mehr in der tl_files-Tabelle stehen sowie die fehlenden Bild-Inhaltselemente. Ich habe also völlig neu synchronisiert und auch die Bild-Elemente neu eingestellt.

Die Website sah wieder normal aus und der Check war zufrieden.

Nun habe ich das Spielchen mit dem Export vom All-Inkl-phpMyAdmin (andere Version) aus wiederholt.

Hier werden in der Ansicht nun zwar nicht mehr die Bild-Elemente gelöscht (vermutlich wegen der anderen phpmyAdmin-Version die wohl anders auf die Zeichensatzfehler reagiert) und auch die tl_files-Einträge bleiben erhalten, aber es gibt schon wieder Zeichensatzfehler (sehen nur etwas anders aus).

tl_content:

Code:

---

(33, 4, 'tl_article', 256, 1392375260, 'image', 'a:2:{s:4:"unit";s:2:"h1";s:5:"value";s:0:"";}', NULL, '', '.�B��f��\0��A�', 'XXXX weltweit', '', 'a:3:{i:0;s:0:"";i:1;s:0:"";i:2;s:12:"proportional";}', 'a:5:{s:6:"bottom";s:0:"";s:4:"left";s:0:"";s:5:"right";s:0:"";s:3:"top";s:0:"";s:4:"unit";s:0:"";}', '', '', '', 'above', NULL, '', NULL, NULL, '', '', '', '', '', 0, 'ascending', '', '', '', '', '', NULL, '', '', '', '', '', '', '', NULL, NULL, '', 4, 0, 0, '', '', NULL, '', NULL, '', '', 0, 300, 0, '', 0, 0, 0, 0, 0, '', NULL, '', 'a:2:{i:0;s:0:"";i:1;s:0:"";}', 'a:2:{i:0;s:0:"";i:1;s:0:"";}', '', '', '', 'ascending', 0, '', '', '', '', 'com_default', NULL, '', '', '', 0, '', '', '', 5, 'bottom', 'center', '', '', '', '', '', '', '', ''),

---

tl_files:

Code:

---

(48, '.�D�f��\0��A�', 1392375185, '.�C>�f��\0��A�', 'file', 'files/images/slider/XXXX.jpg', 'jpg', '789474236243ea1744689bab2bb599d4', '1', 'XXXX.jpg', NULL),

---

WICHTIG: Wie schon erwähnt, solange man sich die Tabellen vor dem Export normal in phpMyAdmin ansieht, sieht alles völlig normal aus. Keine Fehldarstellungen sichtbar. Erst beim Export werden sie sichtbar und stehen dann entsprechend chaotisch in der Datei drin.

Das ist doch total absurd. Hat jemand eine Idee was da los sein könnte?

Also ich hab mir auch mal eine meiner Datenbanken angeschaut und exportiert. Meine SQL-Dumps sehen genauso aus wie deine. Wenn ich sie mir in Notepad++ anschaue, dann habe ich erst mal Zeichensatzfehler im Text, schae ich unter Kodierung steht da ANSI ?!? Ändere ichdas, sehen meine Umlaute wieder normal aus, die UUIDs allerdings nicht. Schaue ich mir die Tabelle tl_files direkt in phpMyAdmin an, dann sehen meine UUIDs "ordentlich aus", ändere ich allerdings in den Optionen und nehme den Haken bei "Binäre Spalten als Hexadezimalwerte darstellen" (oder so ähnlich, habs nicht mehr offen), dann ist die Ähnlichkeit zum SQL-Dump schon größer ;). Daraufhin bin ich mal hergegangen und habe beim Export in den Optionen das auch so eingestellt, dass einmal die Binären Daten als Hexadezimalwerte exportiert werden sollen und einmal nicht. Das Ergebnis sieht für mich im Notepad++ allerdings gleich aus. Wenn ich nachher mehr Zeit habe, mache ich mal ein diff mit den Dateien. Geht hier im Windows leider nicht, nichts passendes installiert. Obwohl, das ist mir einen Transfer auf den uberspace wert ;):cool:
Sehe gerade beim diff, dass da nur der "varchar(32)" Hash anders gespeichert wird aber nicht die "binary(16)" pid und uuid spalten. Die sind wohl nicht binär genug (oder zu binär ;))
Werde nachher mal schauen, was aus meinem online Bild lokal wird nach dem Import.

Prüfe mal, bei mir ist das vorausgewählt, beim Export den Punkt aktivieren:
"Binäre Spalten in hexadezimaler Schreibweise exportieren (zum Beispiel wird aus „abc” 0x616263)"

Wenn du das dann wieder mit phpMyAdmin importierst sollte das funktionieren.
Müsste auch mit jedem anderem Importer gehen.

Das Feld "Binäre Spalten in hexadezimaler Schreibweise exportieren (zum Beispiel wird aus "abc" 0x616263)" ist beim Export automatisch angehakt.

Nachtrag:
Die ganze Sache wird imho auf jeden Fall irgendwie von phpmyAdmin ausgelöst, denn wenn ich backupDB installiere und darüber exportiere, ist alles gut. Es gibt keinerlei Zeichensatzfehler und alle Einträge sind normal da.

Sprich: Die gute Nachricht ist, dass Contao wohl nicht schuld ist :)

Stellt sich jetzt aber trotzdem die Frage, was beim phpMyAdmin-Export schief geht. Ich kann mir das echt beim besten Willen nicht erklären ...

Denke auch, dass es irgendein Problem vielleich mit der Kompatibilität zwischen den phpmyadmin und mysql Versionen sein wird. Wie auch immer, ich habe jetzt gerade mal eine 3.2.7 Installation in der Gegenrichtung von online nach lokal übertragen. Beide Datenbankbackups, die ich heute vor einigen Stunden mit unterschiedlichen Einstellungen gemacht hatte, liessen sich lokal importieren und funktionieren. Mit phpmyadmin sehen auch in der Datenbank die UUIDs wieder vernünftig aus und die Bilder werden auch angezeigt.

Was mir allerdings aufgefallen ist ...
Ich habe mal wieder einen Effekt im DBAFS, den ich mir nicht erklären kann, aber dazu in einem anderen Thread ...

Es ist zum *** ... ich habe gerade wieder das selbe Problem mit den kaputten Backups (Zeichensatzprobleme im Export, dadurch kaputte und nicht mehr nutzbare File-Verknüpfungen).
Dabei habe ich hier einen neuen Laptop, ein neues XAMPP und ein neues PHPMyAdmin. Ich werde noch irre ...

• XAMPP 1.8.3 mit PHP: 5.5.9
• dieses Mal auf Win8-Maschine

Ich frag mal im Xampp-Forum nach, ob die ne Idee haben woran es hakt ...

Manuelles update von 3.0.6 auf 3.2.9
MySQL Vers. 5.1.73 bei 1&1 Webhosting Dual Basic

Hallo Nina,

hast Du inzwischen eine Lösung gefunden?

Nach dem update sind alle Bilder und Downloads weg!

Bei mir sieht es genauso aus, wie Du es oben beschrieben hast:
Bei einem Artikel mit Inhaltselement Text wurde ein Bild hinzugefügt.
In der tl_content steht unter singleSCR:

Code:

---

��������*Oa�

---

In der tl_files steht unter pid:

Code:

---

��������*Oa�

---

und unter uuid:

Code:

---

�\0��������*Oa�

---

Ich kann die Bilder im Backend und Dateien wieder neu zuordnen. Aber das scheint ja keinen Zweck zu haben, wenn sowohl in der tl_content, als auch in der tl_files dann weiterhin Datensalat steht.

Nützt es etwas, wenn ich die tl_files lösche und dann in der Dateiverwaltung neu sychronisiere?

Ich suche dringend eine Lösung, da das update zwar unter einer Subdomain und mit neuer DB durchgeführt wurde, aber die Arbeiten an der operativen Website zur Zeit stillstehen, damit kein neuer Inhalt hinzugefügt wird.

Gruß Peter