Tipp: Fehler "Invalid parent ID ..." bei Update 3.0x/3.1.x auf 3.2.x

[Dr. Jo]

In diesem Fred hier:
https://community.contao.org/de/show...l=1#post298490

ist beschrieben, wie bei einem Update von 3.1.4 auf 3.2.x die folgende Fehlermeldung erscheint (ansonsten ist der Fred dann in Richtung Contao-Check abgedriftet):

Fatal error: Uncaught exception Exception with message Invalid parent ID 4201 thrown in D:\VertrigoServ\www\hkun321_3n\system\modules\core \library\Contao\Database\Updater.php on line 535 #0 D:\VertrigoServ\www\hkun321_3n\contao\install.php( 1077): Contao\Database\Updater->run32Update()
#1 D:\VertrigoServ\www\hkun321_3n\contao\install.php( 526): InstallTool->update32()
#2 D:\VertrigoServ\www\hkun321_3n\contao\install.php( 191): InstallTool->runDatabaseUpdates()
#3 D:\VertrigoServ\www\hkun321_3n\contao\install.php( 1093): InstallTool->run()
#4 {main}

Ich habe das Gleiche heute Abend beim Update von 3.0.6 auf 3.2.7 festgestellt. Wenn man dann die Seite neu lädt und den Fehler ignoriert, sind anschließend verlinkte Bilder und Downloads nicht mehr vorhanden, sondern an deren Stelle findet sich der Warnhinweis "Dieses Element verwendet noch das alte Contao 2 SRC-Format. Haben Sie die Datenbank aktualisiert?".

Meine Lösung: VOR dem Update der Datenbank die Tabelle tl_files auf identische Hash-Werte prüfen - kam bei mir teils bei Dateien vor, die identische Dateinamen hatten, aber in verschiedenen Verzeichnissen lagen, oder aber bei leeren Verzeichnissen. Mit phpmyadmin kriegt man das ja recht schnell raus. Anschließend habe ich diese Duplikate gelöscht und siehe da, das Update lief fehlerfrei durch, alle verlinkten Dateien waren an Ort und Stelle.

Vielleicht hilft es ja jemandem, der sich mit dem gleichen Problem herumschlägt - ist ja eine recht günstige Zeit für Updates ...

Viele Grüße

Dr. Jo

[tab]

Das ist wohl eine weitere Auswirkungeines Problems mit dem db filesystem.
https://github.com/contao/core/issues/6441
Wenn das was du oben geschrieben hast allgemeingültig ist, dann wird das wohl wirklich die Ursache für eine ganze Reihe gemeldeter ähnlicher Probleme sein. Duplikate von Dateien innerhalb des file trees. Der obige issue ist auch immer noch offen. Die Beseitigung des Fehlers scheint eine echt harte Nuss zu sein.

[MacKP]

Dr. Jo,
könntest du dich bitte da auch noch mal ins Ticket hängen?
Wäre super, wenn du das auch noch von der Sichtweise aus beschreiben könntest, damit sich da mal was tut...

Viele Grüße

[Dr. Jo]

Yup, mache ich. KLingt ja jetzt auch nicht so sehr beruhigend ...

Viele Grüße

Dr. Jo

[Dr. Jo]

Kleiner Nachtrag, poste ich jetzt ersma hier statt direkt bei Github, weil ich mit den technischen (Un-)Tiefen des DBFS jetzt nicht so vertraut bin:

Ich habe hier eine weitere 3.0.6er Installation, bei der ich ebenfalls zahlreiche Dateien mit identischen Hashes ausfindig gemacht habe. Gleiche Dateien oder zumindest Dateien mit gleichen Dateinamen, teilweise aus dem Grund, dass ich bestimmte Dateien in dieser Multidomain-Installation gerne sauber getrennt ablege, auch wenn dann halt mal eine Datei doppelt vorhanden ist. Ist das jetzt ein Bug oder ein Feature?

Mein Elan, da jetzt schnell auf den Live Update-Knopf zu drücken, ist verständlicherweise ein wenig gebremst ...

[tab]

Eigentlich ist es ein Feature, leider macht es aber Probleme, könnte also auch als Bug bezeichnet werden
Grundsätzlich bringt es das Folgende. Eine Datei kann an ihrem Hash erkannt werden. So wie ich es verstehe, wird der Hash dabei irgendwie aus den Inhalten der Datei berechnet. Gleiche Dateien bekommen also denselben Hash. Das Feature ist: Verschiebst du per FTP eine Datei in ein anderes Verzeichnis und/oder benennst sie um - und diese Datei ist in ein Inhaltselement eingebunden, dann würde sie normalerweise nicht mehr gefunden, ein Bild in einem Inhaltselement Bild oder Text könnte nicht mehr angezeigt werden. Jetzt aber kannst du einfach das Dateisystem synchronisieren und dieses erkennt anhand des Hashs, wohin sich die fehlende Datei verlaufen hat. Also z.B. du hast die Datei von Verzeichnis1 nach Verzeichnis2 verschoben. Bei der Synchronisierung wird nun bemerkt, dass die Datei in Verzeichnis1 verschwunden ist, aber dieselbe Datei dafür jetzt in Verzeichnis2 gefunden wurde. Das Programm schliesst daraus messerscharf, dass der Benutzer die Datei verschoben hat und biegt die Datenbankinformation (UUID) zu der Datei so hin, dass alle Inhaltselemente die darauf referenzieren die Datei weiterhin finden. In den DB-Einträgen der Inhaltselemente muss dazu nichts geändert werden, insbesondere muss man deshalb auch gar nicht erst alle Elemente suchen, die auf die verschwundene Datei referenziert haben. Ist also schon praktisch, du kannst deine Ordner unter files beliebig umbenennen, verschieben und auch die Dateien umbenennen und das sogar per FTP. Nach der Synchronisierung funktioniert trotzdem wieder alles wie zuvor. Das war das Feature ...
Der Bug dagegen ist, dass es problematisch werden kann, wenn mehrere Dateien / Ordner den selben Hashwert haben. Aber das hast du ja selbst schon gemerkt ...

[Dr. Jo]

Hallo Tab, Danke für die ausführliche Erläuterung - soweit ist das schon klar. Meine Frage nach Bug oder Feature bezog sich eher auf den Umstand, dass verschiedene Dateien (oder, wie bei mir: unterschiedliche Verzeichnisse) identische Hashes besitzen können. Denn wie gesagt, manchmal ist es ja auch sinnvoll, allein schon aus ordnungspolitischer Sicht, die gleiche Datei an verschiedenen Orten zu hinterlegen. Und problematisch wird es halt dann, wenn dadurch ein (notwendiges) Update verunmöglicht wird ... bei meinem aktuellen Fall verwende ich für zwei Domains zwei Themes, die sich aber viele gleiche Dateien teilen. Da will ich ja jetzt nicht die Hälfte löschen - am Ende noch eine hier, eine da ... da ist Unordnung vorprogrammiert.
Hm, scheint jetzt wirklich ein Problem zu werden ...

[tab]

Genau, solche Situationen wird es immer geben, Gründe, warum zum Beispiel ein Bild mehrfach gespeichert wird, einfach organisatorische Gründe. Bisher bin ich davon ausgegangen, dass das nur zum Problem wird, wenn eines der gleichen Bilder gelöscht wird. Hast du z.B. alle Bilder einer Galerie in einem Ordner und eins davon noch zusätzlich woanders, weil du es z.B. als eins von mehreren Bildern in einen Artikel einbinden willst. Eines Tages entscheidest du, dass das Bild nicht mehr in der Galerie angezeigt werden soll und löschst es aus dem Ordner. Momentan ist es dann so, dass das Bild nicht mehr im Artikel angezeigt wird, obwohl das dort eingebundene Bild ja gar nicht gelöscht wurde. Ziemlich lästiger Bug, aber vermeidbar, wenn man es weiss. Man kann z.B. die im Artikel eingebundene Datei löschen und danach die im Galerieordner liegende Datei wieder ins Artikelverzeichnis verschieben. Von hinten durch die Brust ins Auge, aber klappt

Mit deiner Beobachtung kommt jetzt noch eine neue Dimension des Problems dazu. Offenbar ist irgendwo im Update-Algorithmus eine Stelle, an der mehrfach vorhandene Hashes Probleme machen und zu Fehlern führen, obwohl keine der Dateien gelöscht wurde. Und das ist leider nicht so (relativ) leicht beherrschbar. Geht im Prinzip gar nicht, ohne die von dir beschriebene Unordnung zu produzieren, indem man konsequent von mehreren gleichen Dateien nur eine behält und diese dann überall verwendet Gerade bei zwei Themes eigentlich gar nicht praktikabel, da man hier auch noch aufpassen muss, dass beide Themes vollständig exportiert werden können. Ok, man könnte einen "shared" Ordner machen und den mit beiden Themes exportieren. Ist aber auch keine perfekte Lösung.

[Jens_]

Hallo zusammen,

ich habe noch einmal eine Rückfrage zu dem Hinweis mit dem doppelten Hash-Wert. Für mich ist die Frage, ob es irgendeinen anderen Weg gibt, ein Update durchzuführen, ohne doppelte Dateien zu löschen.

Kurz zum Hintergrund bei mir:
Ich nutze mehrfach das gleiche Template in einer Multidomaininstallation, natürlich mit identischen Dateien (SASS, Icons...). Das soll auch bewusst getrennt bleiben. Nach einem Update von einer 3.1.5 auf eine 3.2.7 konnte ich mit dem UUID-Tool alle Bilder rekonstruieren, nur die Contao-eigene Galerie funktioniert nicht mehr. Genau genommen funktioniert sie noch, hat aber alle Bildzuordnungen verloren. Lässt sich das anders heilen, als die Templates auseinanderzureißen? Oder gibt es nur die Möglichkeit, alle Galerien (und das sind viele...) manuell neu zuzuordnen?

Grüße
Jens_

[Dr. Jo]

@tab:

Eines Tages entscheidest du, dass das Bild nicht mehr in der Galerie angezeigt werden soll und löschst es aus dem Ordner. Momentan ist es dann so, dass das Bild nicht mehr im Artikel angezeigt wird, obwohl das dort eingebundene Bild ja gar nicht gelöscht wurde. Ziemlich lästiger Bug, aber vermeidbar, wenn man es weiss. Man kann z.B. die im Artikel eingebundene Datei löschen und danach die im Galerieordner liegende Datei wieder ins Artikelverzeichnis verschieben.

Ja, für jemanden, der seine Seite selbst verwaltet, mag das gehen. Aber für Redakteure? Was sollen die denken? Dass sie mit Frickelkram arbeiten müssen? Geht IMHO gar nicht.

Ansonsten - die (doppelten) Dateien der Themes halte ich inzwischen nicht so sehr für ein Problem, denn die sind ja in aller Regel nicht über Content-Elemente etc. eingebunden. Ergo ist es wohl auch nicht so schlimm, wenn ich die entsprechenden Referenzen dazu lösche, weil eine erneute Synchronisierung nach dem Update diese Einträge (dann hoffentlich korrekt ...) wiederherstellen sollte. Ärgerlicher, weil mit Arbeit bis viel Arbeit verbunden, sind/wären Dateien, die eben über Content-Elemente eingebunden sind.

@ jens_

Vielen Dank ersma für den Hinweis zu dem UUID-Tool, das kannte ich noch nicht. Ich gebe auch zu, dass ich momentan noch immer am Lesen bin, um das Ganze zu verstehen, weil das bislang einfach kein Thema (d.h. kein Problem war). Nur so viel: Dateien habe ich keine gelöscht, nur Referenzen in der tl_files. Dass bei Dir die Bildzuordnungen in den Galerien verschwunden sind, würde ja aber darauf hindeuten, dass da beim Update etwas schiefgegangen ist. Kannst Du das Update (ggfs. auf einer lokalen Maschine) Schritt für Schritt nachstellen? Dann ließe sich vielleicht auch rekonstruieren, ob auch bei Dir doppelte Hashes zum Problem beitragen ...

Scheint aber doch so zu sein, dass wir nicht die Einzigen sind, die damit ein Problem haben, wenn man verschieden Freds hier und auch bei GitHub anschaut. Etwas Systematik wäre da nicht verkehrt (?).

[tab]

@tab:
Ja, für jemanden, der seine Seite selbst verwaltet, mag das gehen. Aber für Redakteure? Was sollen die denken? Dass sie mit Frickelkram arbeiten müssen? Geht IMHO gar nicht.

natürlich kann man so nicht wirklich arbeiten, Redakteure ganz sicher nicht und auch ich würde das sicher höchstens mal für einige wenige Dateien tun wollen. Es ist auch nicht unbedingt nötig, ich denke über die Dateiverwaltung zu löschen funktioniert auch richtig. Da hat die Dateiverwaltung ja alle notwendigen Infos sofort parat und muss nicht erst nach möglicherweise verschobenen Dateien suchen. Das "Problem" tritt nur auf, wenn man per FTP Dateien löscht/verschiebt und danach synchronisiert.

[Nook]

@tab:
Scheint aber doch so zu sein, dass wir nicht die Einzigen sind, die damit ein Problem haben, wenn man verschieden Freds hier und auch bei GitHub anschaut. Etwas Systematik wäre da nicht verkehrt (?).

Die gleichen Probleme habe ich auch bei einigen Installationen

[tab]

Um die aktuellen Probleme in den Griff zu bekommen, kannst du mal das probieren.
https://contao.org/de/extension-list...reator.de.html
Aber vor dem Versuch ein Backup zu machen versteht sich wohl von selbst.

[Nook]

Um die aktuellen Probleme in den Griff zu bekommen, kannst du mal das probieren.
https://contao.org/de/extension-list...reator.de.html
Aber vor dem Versuch ein Backup zu machen versteht sich wohl von selbst.

Bereits getestet.
Für einzele Bilder klappte das auch prima.

Für ce_galerie jedoch bei mir leider nicht.

[MacKP]

Macht doch bitte ein Ticket dazu.. sonst wird sich das Leo nie anschauen.

Viele Grüße

[Nook]

Macht doch bitte ein Ticket dazu.. sonst wird sich das Leo nie anschauen.

Viele Grüße

Ticket gibt es bereits: https://github.com/contao/core/issues/6441

[Nook]

Dieser Fehler ist zumindest in den bei mir betroffenen Kundensystem auch noch in Contao 3.2.10 vorhanden.

Obwohl die dazugehörigen tickets in Contao geschlossen / gelöst sind.
zB: https://github.com/contao/core/issues/6441