cck imagefield replace image löscht das alte image nicht

Willkommen bei Drupal.

Stimmt.

Im weiteren erweist es sich als guenstig die Drupalversion zu kennen.

Ausserdem bitte fuer Fragen/Probleme unterschiedlicher Thematik getrennte Threads eroeffnen.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Das steht zwart im Thread drin, aber eigentlich hättest Du das beim erstellen im dafür vorgesehenen Feld auswählen sollen. Das macht es einfacher den Beitrag zuzuordnen.

Gruss Roger

Drupal 6.6 - habe ich uebersehen da ich meist nur nach oben an den Thread gucke welcher Drupalversion der Thread zugeordnet ist. Sorry.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Sorry, das hab ich völlig übersehen. Ich werd mich bessern :) Und auch in zukunft für jedes Problem einen Thread erstellen :)

Gibt es keine Lösung für das Problem?
Nicht nur, dass es Datenmüll ist, welcher der verfügbaren Platz zuspammt, nachdem ein Bekannter eine Abmahnung für ein Bild erhalten hat, welches zwar auf dem Webserver lag aber nirgendwo verlinkt war, bin ich etwas paranoid, was sowas angeht.

Wenn man ganz paranoid denkt, ist das sogar eine Sicherheitslücke. Man könnte sich üble Leute vorstellen, welche Beiträge schreiben, Bilder hochladen und dann nicht abspeichern. Die URLs der Bilder(Drupal ändert den Dateinamen ja nicht, solange eine Datei mit dem Namen nicht schon existiert!) werden dann über andere Wege verteilt und so könnte die Installation zum Beispiel als Verteiler für verbotene Bilder missbraucht werden! Sowas kann böse ins Auge gehen.

Das Verhindern von Datenmüll durch Datei-Leichen wie auch klare Strukturen bei Imageuploads durch User sind mir bei Drupal seit längerem im Auge. Bisher konnte ich feststellen das Drupal keine Probleme bezüglich Image-Datei-Leichen macht. Soll heissen, vom System hochgeladene Bilder werden vom System auch wieder entfernt.

Ein Problem gibt es allerdings.

Wird ein Bild per CCK Field mit einer Node auf den Server geladen (vom System also) dann existiert dieses Bild im entsprechenden Ordner. Nehmen wir an die Imagedatei hat den Namen "foobar.png".
Wird nun genau diese Imagedatei erneut mit der Node (bearbeiten) heraufgeladen dann wird neben die bereits existierende Datei "foobar.png" eine Imagedatei mit dem Namen "foobar_0.png" abgelegt. Zu diesem Zeitpunkt existiert das gleiche Bild also 2 Mal auf dem Server.
Dieser Vorgang wiederholt sich mit erneutem Hochladen der Datei"foobar.png" so das es mehrere Dateien auf dem Server geben kann nach dem Schema: foobar.png, foobar_0.png, foobar_1.png, foobar_2.png, usw.

Jetzt kommt der Punkt an dem Datei-Leichen entstehen.

Wird mit der Node das aktuelle Bild gelöscht so wird NUR eine Datei auf dem Server gelöscht. Und zwar die Datei welche mit dem Bild in der Node identifiziert wird. Dies ist die als Letzte heraufgeladene Imagedatei - aus Sicht der Node also die aktuelle Datei. Ist dies beispielsweise die Datei "foobar_1.png" so bleiben die Dateien "foobar.png" und "foobar_0.png" als Datei-Leichen auf dem Server.

Aus meiner Sicht ist dieses Verhalten ein Usability-Bug.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Das macht sogar Sinn, denn wie oft kommt es vor, daß ein Dateiname zweimal vergeben ist.
Zum Beispiel liest Du den Chip Deiner Kamera aus, hast Du DSC001.jpg oder so ähnlich, natürlich löscht Du die Daten auf dem Chip, um wieder Platz zu haben. Beim nächsten Auslesen ist es ziemlich wahrscheinlich, daß eine andere Datei eben auch DSC001.jpg heisst.
Ich gebe Bildern, Foto's etc. die ich hochlade möglichst eindeutige Namen, das ist zwar ein wenig Arbeit mehr, so habe ich aber Ordnung und sehe halbwegs durch, wenn mal was schiefläuft.

Was die Dateien in den Preset-Ordnern (imagecache/thumbs o.ä.)betrifft, die werden beim Löschen der Node nicht automatisch gelöscht, vielleicht ja beim nächsten Cronlauf(?), habe ich aber ehrlich gesagt noch nicht weiter ausprobiert. Auf alle Fälle gibt's ja immer noch Flush (...admin/build/imagecache),gut zum "Reinigen" des Ordners Imagecache. Die damit gelöschten Dateien werden beim nächten Aufruf der entsprechenden Nodes wieder hergestellt.

Genau an dieser Stelle kommt der Usability-Bug zum Tragen.

Denn genau dieser Umstamd wird beim Handling von Bildern, beispielsweise beim Einfuegen/Hochladen eines Bildes beim Bearbeiten einer Node dem Anwender nicht bekannt gemacht.

Nun muss man aber nicht glauben das von diesem Bug nur ein Dau betroffen ist. Die ablaufende Logik ist ganz normale Anwendungslogik, eben Usability. Mit dieser Usability hat es jeder Anwender zu tun.
Einzig der erfahrene Drupal-Anwender kommt in diesem Moment ueberhaupt auf die Idee an das Problem mit gleichen Dateinamen zu denken und auch sein Handeln danach auszurichten.

Die Problematik gleicher Dateinamen ist aktuelle sozusagen auf den "kleinsten gemeinsamen Nenner" ausgerichtet. Soll heissen dem Anwender die Arbeit so einfach wie moeglich zu machen.
Eine Moeglichkeit fuer eine eventuelle Loesung als Ausweg aus diesem Dilemma/dieser Situation waere, zumindest dem Admin die Change zu geben mit diesem Umstand konfrontiert zu werden in dem in der Administration entsprechende Optionen fuer eine Konfiguration und damit fuer das Verhalten des Systems bei Uploads von Bildern an die Hand gegeben werden.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Es giebt leider auch Situationen, in denen Imagecache beim Löschen der Nodes nicht die dazugehörigen Dateien löscht, und zwar, wenn http-Requests aus irgendeinem Grund fehlerhaft ausgeführt werden oder irgendwo im Nirvana versacken. Z.B ist an meinem Arbeitsplatz (Heiligendamm in Mecklenburg) kein DSL verfügbar sondern nur so eine Web'n Work-Box von T-Mobile, da ist Arbeiten mit Imagecache schier unmöglich. http://www.drupalcenter.de/node/14756

Viele liebe Grüße