Katalogeinträge inkl. Ressourcen komplett löschen?

[xchs]

Hallo,

gäbe es irgendeine Möglichkeit, beim Löschen eines Katalog-Eintrages im Backend neben dem DB-Datensatz auch die dazugehörigen Ressourcen (z.B. die betreffenden Produktbilder) gleichzeitig mitzulöschen (physisch vom Server)?

[MacKP]

Hallo xchs,
mir ist keine bekannt, da der Katalog auch nur das kann was TL bietet. Und da passiert das ja auch nicht wenn eine Galerie entfernt wird ;-)

Wobei sowas auch nicht gerade sinnvoll ist. Denn: was ist wenn man nur mal eben ein altes Item entfernt und die Bilder in einem neuen nutzen möchte?
Es müsste also auf jeden Fall noch eine Abfrage erfolgen...

Viele Grüße

[xchs]

Hallo MacKP,

Hallo xchs,
mir ist keine bekannt, da der Katalog auch nur das kann was TL bietet. Und da passiert das ja auch nicht wenn eine Galerie entfernt wird ;-)

Wobei sowas auch nicht gerade sinnvoll ist. Denn: was ist wenn man nur mal eben ein altes Item entfernt und die Bilder in einem neuen nutzen möchte?
Es müsste also auf jeden Fall noch eine Abfrage erfolgen...

Da hast Du wohl recht! Selbstverständlich müsste diese Option explizit beim Löschen bestätigt werden.

Das Problem, das ich zurzeit sehe, ist folgendes: Redakteure laden Produktbilder (à ca. 200-300 KB oder mehr) per FTP auf den Webspeicherplatz, erstellen die entsprechenden Katalogeinträge und - sobald diese nicht mehr aktuell sind - werden die betreffenden Katalog-Datensätze wieder gelöscht. Leider verbleiben so unzählige Bild-Leichen auf dem Server liegen (z.Z. ca. 500 MB) und da die Redakteure beim Hochladen natürlich nicht die von mir ursprünglich vorgegebene Ordnerstruktur einhalten (und meist Bilder unterschiedlicher Produkte alle zusammen in einen Ordner reinschmeißen) wird es dann müßig, nur jene Bilder rauszusuchen, welche aktuell in keinem Katalog mehr gebraucht werden.
In solchen Fällen wäre wahrscheinlich wirklich auch mehr Disziplin von den Redakteuren einzuforden, aber ob das wirklich einfacher ist und langfristig dann auch eingehalten wird, vage ich zu bezweifeln...

[MacKP]

Hallo xchs,
ich kann den Wunsch und das Problem sehr gut verstehen.
Damit muss sich auf jeden Fall beschäftigt werden.
Allerdings sehe ich da das Problem etwas grundsätzlicher, da dieses Problem überall in TL aufkommt und nicht nur im Katalog.
Daher sollte so etwas eventuell eher direkt an leo adressiert sein.

Viele Grüße

[xchs]

Daher sollte so etwas eventuell eher direkt an leo adressiert sein.

Du findest also, das wäre einen Feature Request wert? *Leowirdnichtbegeistertsein*

Ich werd mal drüber schlafen...

[xtra]

nunja, bevor das als Feature Request eingestellt wird, muss man sich hierzu sehr viele Gedanken machen.
Denn davon wird nicht nur Leo nicht begeistert sein, sondern ich gleich mit.

Punkte die ich hier mal eben in den Raum werfe:
1. Wann sollten Die Bilder geloescht werden? - Abfrage beim User? Welche User haben diese Berechtigung?
2. Kann der user garantieren, dass das Bild nicht noch in einem anderen Katalogeintrag verwendet wird (kann man im Katalog ggf. noch abfangen). Oder in einem Newseintrag? Oder in einer Gallerie? Oder als Avatar? Oder als....
3. Koennen wir das aus Punkt 2 yberhaupt herausfinden? Wir kennen nicht alle Datenbanken, die Bilderurls speichern. Was ist mit den Modulen auf die der aktuelle User keine Berechtigung hat? Die gehen komplett an uns vorbei...

Ich neige (wie auch schon an anderer Stelle gesagt, finde nur den Thread gerade nicht) dazu zu sagen, dass eine solche Funktion in TYPOlight derzeit (mit vertretbarem Aufwand) nicht moeglich ist, nicht vorgesehen ist und auch nicht eingebaut wird.

Gruss
Chris

[FloB]

Eine relativ einfache Methode wäre, alle in der DB verlinkten Dateien aufzulisten und diese mit der Dateistruktur abzugleichen. Die Dateien, die nicht in der DB auftauchen, sind potentielle Löschkandidaten (am besten vergleicht man diese noch mit dem Create-/Modified-Timestamp, damit man nicht erst grade erstellte Dateien löscht).

[xchs]

Hallo Chris,

nunja, bevor das als Feature Request eingestellt wird, muss man sich hierzu sehr viele Gedanken machen.
Denn davon wird nicht nur Leo nicht begeistert sein, sondern ich gleich mit.

Punkte die ich hier mal eben in den Raum werfe:
1. Wann sollten Die Bilder geloescht werden? - Abfrage beim User? Welche User haben diese Berechtigung?
2. Kann der user garantieren, dass das Bild nicht noch in einem anderen Katalogeintrag verwendet wird (kann man im Katalog ggf. noch abfangen). Oder in einem Newseintrag? Oder in einer Gallerie? Oder als Avatar? Oder als....
3. Koennen wir das aus Punkt 2 yberhaupt herausfinden? Wir kennen nicht alle Datenbanken, die Bilderurls speichern. Was ist mit den Modulen auf die der aktuelle User keine Berechtigung hat? Die gehen komplett an uns vorbei...

Ich neige (wie auch schon an anderer Stelle gesagt, finde nur den Thread gerade nicht) dazu zu sagen, dass eine solche Funktion in TYPOlight derzeit (mit vertretbarem Aufwand) nicht moeglich ist, nicht vorgesehen ist und auch nicht eingebaut wird.

Danke für Deine Einschätzungen.

ad 1: Natürlich müsste es diesbezüglich einen klaren Hinweis geben, dass mit dieser Aktion die Datei(en) unwiderruflich gelöscht werden, irgendwie in der Art wie in der Erweiterungsverwaltung (mit großem Stopp-Zeichen und nochmaliger Bestätigungsaufforderung)

ad 2 und 3: Da hast Du natürlich vollkommen recht! Das wird in dieser Form sicherlich schwierig werden, wenn man neben der Katalog-Erweiterung auch andere Inhaltselemente berücksichtigen müsste.

Eine relativ einfache Methode wäre, alle in der DB verlinkten Dateien aufzulisten und diese mit der Dateistruktur abzugleichen. Die Dateien, die nicht in der DB auftauchen, sind potentielle Löschkandidaten (am besten vergleicht man diese noch mit dem Create-/Modified-Timestamp, damit man nicht erst grade erstellte Dateien löscht).

Ja, das wäre vielleicht noch besser, so eine Art Bereinigungsfunktion. Könnte man dann in die TYPOlight-Systemwartung integrieren. Ich weiß jetzt nur nicht genau, ob man das fix in den Core aufnehmen sollte oder ob das besser in einer Erweiterung aufgehoben wäre.

[xtra]

Eine relativ einfache Methode wäre, alle in der DB verlinkten Dateien aufzulisten und diese mit der Dateistruktur abzugleichen. Die Dateien, die nicht in der DB auftauchen, sind potentielle Löschkandidaten (am besten vergleicht man diese noch mit dem Create-/Modified-Timestamp, damit man nicht erst grade erstellte Dateien löscht).

Verraetst du mir bitte, in welchen Tabellen und welchen Feldern ich dann alles nachsehen muss?
Theorethisch muss ich dann jeden DCA laden, nach fieldtype file suchen und anschliessend die kompletten Tabellen in diesen Feldern nach dem aktuell zu loeschenden File durchsuchen und kann mich dann erst nicht drauf verlassen dass irgendwo das File noch verwendet wird, weil es evtl. in einem longtext verlinkt ist. Wenn ich die nun auch noch mit Fulltext durchsuchen muss, dann stell ich dir mal eben, bei einer grossen Seite, den Datenbankserver ne Zeit hin in der kein Besucher mehr replies bekommt, weil ich die DB aktuell zum loeschen gelockt habe.
In der Theorie klingt das Vorgehen sehr einfach, aber glaube mir, wir haben daryber schon eine zeitlang diskutiert und kamen zum Schluss dass es nicht mit vertretbarem Aufwand moeglich ist, alles zu finden wo das File noch verwendet wird.
Daher yberlasse ich die Entscheidung, das file zu loeschen gaenzlich dem User.

Gruss
Chris

[FloB]

Ich habe nicht gesagt, dass mein Vorschlag eine generelle Funktion sein soll – es war eine Antwort auf den ersten Post, nicht die darauf folgende Diskussion um ein Bereinungs-Feature. Natürlich steht nirgendwo, in welchen DB-Feldern überall Dateien verlinkt sind. Diese DB-Felder muss man schon selber zusammentragen.

Was ich mir jedoch vorstellen könnte: Eine generelle Bereinungsfunktion (im Core), bei der man per Hook / Config-Array DB-Felder eintragen kann, in denen Dateien zu finden sind (Dateien müssen ja auch nicht in DCA-Type "file" / "filetree" et al. gespeichert sein). Hat jedoch den Nachteil, dass Dateien von nicht angemeldeten Feldern standardmäßig gelöscht werden würden. Das sollte natürlich nicht der Fall sein. Weitere Problematik (wie du schon sagtest): Was ist mit Dateien, die in einem Textfeld verlinkt sind? Da müsste man eine Parsermethode einrichten, die Textfelder nach möglichen Pfaden absucht. Also alles nicht so einfach zu automatisieren.