Bilder löschen vom Server - Sammelthread

Hallo an alle,

ich möchte mal eine Diskussion darüber anregen, was mit den vielen Stellen im Admin los ist, wo direkt oder indirekt Bilder/Files gelöscht werden müssten, dies aber nur fehlerhaft oder gar nicht funktioniert. Es betrifft fast alle Forms, die auch einen Bild/File-Upload bieten, also Artikel, Kategorien, Hersteller, Promo-Banner, Wrapping, etc. Das einzige, was korrekt geht, ist das direkte Löschen der Artikel-Bilder, ansonsten ist es leider IMMER der Fall, dass der DB-Eintrag zwar gelöscht wird, aber die eigentlichen Files nicht! Dadurch müllen sich die Bilder-Dirs mit der Zeit derart zu, dass man kaum noch durchblickt (wenn man oft Bilder ändert), und irgendwann könnte auch der Webspace knapp werden…

Dieser Thread geht auch in die Richtung:
http://www.oxid-esales.com/forum/showthread.php?t=10923
aber das Problem ist ja noch viel umfangreicher, weswegen ich anders ansetzen möchte.

Ich habe bereits 1 Bugreport hinzugefügt:
https://bugs.oxid-esales.com/view.php?id=3392

und einen ergänzt:
https://bugs.oxid-esales.com/view.php?id=3345

Der hier ist auch passend, da wie gesagt diese foreach()-Fehler kommen, wenn glob() mal false zurückgibt, was durchaus erlaubt und denkbar ist:
https://bugs.oxid-esales.com/view.php?id=3339

Alles soweit schön und gut, aber wie verfährt man nun am besten:

  • dutzende Einzel-Bugs melden oder
  • ebensolche Feature-Requests eintragen oder
  • es selbst per Hotfix-Modul o.ä. in die Hand nehmen?

Ich sehe es klar als Bugs, da der Wille ja durchaus da war, es sauber zu coden, aber irgendwie wurde es nicht zu Ende gedacht. Falls mir jemand noch nicht folgen kann: Es geht darum, dass beim Löschen eines kompletten Artikels, Herstellers, Kategorie, etc., oder beim Ändern/Löschen einzelner Bilder desselbigen fast nie die alten Bilder vom Server gelöscht werden. Und ich arbeite zwar aktuell mit Oxid CE 4.5.4, aber es scheint ein generelles und uraltes Problem zu sein, was wohl noch nie besser lief (auch nicht mit der alten Bildordner-Struktur von 4.4.x).

Ich habe es mal versucht, alles händisch zu fixen, aber es gibt teilweise mehrere Wege zum Ziel und es macht ganz schön viel Arbeit. Einen Großteil kann man durch Erweiterung der oxutilsfile-Klasse hinbekommen, aber ich habe Zweifel, ob das der sauberste Ansatz ist. Ich könnte noch einige Code-Beispiele liefern, aber möchte gerne erstmal ein paar allgemeine Entwickler-Meinungen zum Thema hören.

Ist es evtl. (im schlimmsten Fall) sogar bewusst gewollt, möglichst wenig zu Löschen? Dann würde mich der Grund dafür aber brennend interessieren. Klar gibt es den Ausnahmefall, des Kopierens von Artikeln, wo man aufpassen muss, dass wg. gleicher Bildnamen erst gelöscht wird, wenn alle Artikel-Kopien ebenso gelöscht wurden, aber das scheint dort schon gut zu klappen und muss ja nicht geändert werden. Bei den Files sieht es schon wieder anders aus, und “Media” erstrecht…

So, und nun haut in die Tasten! :slight_smile:

Okay, 1 Hotfix-Beispiel will ich Euch zur Verdeutlichung nicht vorenthalten:

Klasse oxarticle, Funktion _deletePics() ergänzen am Ende:

        // delete article file
        if ( ( $sFile = $this->oxarticles__oxfile->value ) ) {
            $sPath = $this->getConfig()->getPictureDir( false ) . oxUtilsFile::getInstance()->getImageDirByType( "FL" );
            oxUtilsPic::getInstance()->safePictureDelete( $sFile, $sPath, "oxarticles", "oxfile" );
        }

Dann wird beim Ändern oder Löschen der Artikel-Datei und beim Löschen des Artikels auch die Datei wirklich vom Server gelöscht.
Und dies sollte imho eigentlich Standard sein, oder?

Hm, ich bin ein wenig überrascht von der großen Resonanz (quasi Null)… :frowning:
Was läuft da falsch:

  • falscher Thread?
  • falsche “Wortwahl”?
  • mangelndes Interesse?

Oder stuft Ihr das Ganze als eher kosmetisches Problem ein, mit dem man leben kann/muss? Marco, was meinst Du z.b. dazu? Irgendeine Meinung wird doch jemand haben, oder nicht? :confused:

Hallo Mitmacher,

als kosmetisches Problem würde ich das nicht sehen, da es Fälle gibt, in denen

[ul]
[li]der zur Verfügung stehende Platz eine Rolle spielt
[/li]Es gibt derzeit keine Möglichkeit zur “Garbage Collection” in den Bildern, also ein Löschen aller verwaister Bilder
[/ul]
[ul]
[li]man Google etc. die alten Bilder entziehen möchte
[/li]Sonst sind die alten Bilder noch in 100 Jahre in der Bildersuche zu finden
[/ul]
[ul]
[li]das Bild unbedingt z.B. wegen Copyright-Problemen gelöscht werden muss
[/li]Glaubt man beispielsweise durch Löschen des Artikels das Problem von der Backe zu haben, so liegt es immer noch erreichbar (und abmahnbar) auf dem Server
[/ul]

Da die Bilder eines Artikels beim Kopieren des Artikels selbst nicht kopiert werden, sondern intern nur auf das gleiche Bild auf der Disk verweisen wird, muss man mit dem Löschen, so wie Du es vorgeschlagen hast, aufpassen, sonst ist mit dem Löschen des einen Artikels auch das Bild des anderen weg.

Für mich wäre ein Admin-Funktion, die man als Bereinigung laufen lässt ausreichend.

Joachim

Schön, ich bin nicht alleine, das fühlt sich schon besser an! :smiley:

An die rechtlichen Dinge habe ich noch gar nicht gedacht, aber die sind ja evtl. sogar das Wichtigste an der ganzen Geschichte, stimmt! Und Du magst schon Recht haben, das einfachste wäre eine zentrale Aufräumfunktion im Admin (die man dann natürlich auch regelmäßig finden und benutzen muss). Es gibt glaube ich schon ein Modul für ähnliche Cleanup-Zwecke, aber 1. finde ich es gerade nicht wieder (blöde exchange-Suche!) und 2. müsste man es evtl. halt um die Bilder erweitern.

Besser wäre es aber, wenn die Entwickler das Problem erkennen und beseitigen würden, sonst bin ich leider echt geneigt, ein Hotfix-Modul o.ä. zu basteln, das habt Ihr denn davon! :stuck_out_tongue:

hmmm… das wäre doch eigentlich ne thematisch passende Erweiterung für das tmp-clear bzw. Views-aktualisieren Teil des Modulconnectors von D3?

Ach, da ist so etwas eingebaut? Danke für den Tipp! Aber wie hieß bloß dieses andere Mini-Modul oder war es nur ein ZIP-File im Forum? Argh, blöde, wenn man es nicht gleich speichert und verlinkt… :mad: