Die Extension KJ Recycler 2005 von Julian Kleinhans stattet das TYPO3-Backend mit etwas aus, das man heute von jedem Betriebssystem her kennt: einem Papierkorb. Ein solcher Papierkorb ist deshalb unverzichtbar, weil man darin all das wiederfindet, was man versehentlich gelöscht hat. Umgekehrt kann man den Papierkorb bewusst leeren und damit alle gelöschten Datensätze physisch aus der Datenbank entfernen. Wie dies im Detail funktioniert, ist auf der Website von Julian Kleinhans sehr schön beschrieben.
Im Prinzip kann TYPO3 all das auch ohne diese Extension: Wenn man etwas löscht, wird es nämlich nicht dauerhaft gelöscht, sondern nur in der Datenbank als gelöscht gekennzeichnet. Wer sich also nicht scheut, mit phpMyAdmin direkt auf die Datenbank zuzugreifen, kann dort irrtümlich gelöschte Daten retten. Diese Methode setzt allerdings einiges Fachwissen voraus und ist insbesondere dann tückisch, wenn Abhängigkeiten zwischen Datensätzen verschiedener Tabellen bestehen. Der KJ Recycler 2005 löst diese Aufgabe wesentlich komfortabler und sollte eigentlich zum Standard-Umfang von TYPO3 gehören.
Hat Typo3 nicht seit der Version 4 ein Versionskontrollsystem? Das würde den Papiereimer doch überflüssig machen.
(Habe noch nichts mit V4 gemacht…)
Eine berechtigte Frage, die mich etwas ins Grübeln gebracht hat.
Provisorische Antwort: Der Recycler erlaubt die Wiederherstellung von gelöschten Datensätzen, während das Versionskontrollsystem von TYPO3 nur Änderungen an Datensätzen rückgängig machen kann. Mit anderen Worten: Wenn z.B. eine Seite ganz gelöscht wird, dann ist sie weg, dann kann das Versionskontrollsystem nicht mehr darauf zugreifen, und dann kommt der Recycler zum Einsatz.
Dann gehe ich also richtig in der Annahme, dass ich in der DB nur nach allen Objekten suchen muss, für die das Feld “deleted” mit eienr 1 bzw. einem Timestamp gefüllt ist?
Derzeit haben wir nämlich 100.000 Seiten und 150.000 Seiteninhalte im Papierkorb und diese per Hand zu leeren, wäre äusserst zeitaufwändig…