25 Reaktionen zu “Türchen 2: Tutorial – TYPO3 entrümpeln”

Kommentare abonnieren (RSS) oder TrackBack URL

Dankeschoen- Das hat mich immer schon mal interessiert. Gibt es denn auch eine Moeglichkeit Typo3 beizubringen Assets NICHT in den uploads folder zu kopieren sondern in ihrem Orginalverzeichniss zu belassen?

Thomas M am 02. Dezember 2008 um 00:27

Ich habe es nicht getestet, aber ich glaube wenn man keinen Upload Folder übergibt, dann werden die Pfade alle relative gespeichert und es kommt zu keiner Kopie. So etwas sollte man aber von Anfang an einstellen und nicht bei einem laufenden Projekt umlegen.

Tim Lochmüller am 02. Dezember 2008 um 00:36

Ansonsten hilft hier nur der Einsatz der DAM-Erweiterung, mit der ich mich leider noch nicht so richtig anfreunden konnte, zu viel Probleme beim Hochladen von Daten per FTP die dann nicht richtig indexiert werden usw…

Den Artikel finde ich sehr gut, gerade für Anfänger wäre diese Übersicht ein guter Beitrag im TYPO3-Wiki. Was meinst du?

Florian am 02. Dezember 2008 um 06:47

Du schreibst: „Mein Tipp: Die Extension updated nicht den Referenz Index. Dieser sollte im Anschluss des Löschens manuell geupdated werden, damit dieser wieder richtig ist.“

-> Was ist der „Referenz Index“ & wie bzw. wo kann ich diesen manuell bearbeiten?

Danke für den Beitrag, der in die Bookmarks gehört und zum Frühjahrsputz zum Einsatz kommt.

Mopps am 02. Dezember 2008 um 09:23

Eigentlich ist das ein Feature, denn wenn ich einen Datensatz wiederherstelle ist auch das Bild wieder mit dabei.

Dummerweise fehlt dieses Feature, wenn ich aus der Liste der Bilder die Bilder entferne: dann wird auch das Bild in uploads/pics/ entfernt.

Blöd ist daran vor allem, dass hier kein durchgängiges System verwendet wird. Denn wenn ich ein Bild durch „wiederherstellen“ wieder bekommen möchte, kriege ich den Dateinamen zurück – aber das Bild bleibt gelöscht.

Bug oder Feature?

Martin Holtz am 02. Dezember 2008 um 09:55

Den Reference Index findest du auch im backend Modul “DB-Überprüfung”. Das ist ein Index in dem alle Relationen von TYPO3 abgebildet werden. Der Index wird benutzt um in der Listenansicht hinten die Realations-Nummer auszugeben. Wenn du die anklickst, dann kannst du sehen wo der aktuelle Datensatz referenziert wird. Nach dem löschen von Records passt dieser Index in der Regel nicht mehr. Deshalb das Update…

Tim Lochmüller am 02. Dezember 2008 um 10:00

Hi Tim und Besucher,
genau mit gleichen Mitteln hatte ich vor kurzem auch eine Seite von mir entrümmpelt. Diese läuft schon seitdem es TYPO3 3.6.1 gab. Nur die Sache mit dem „Reference-Index“ hatte ich nicht bedacht 🙁 Dankeschööön, Gruss Michael

Michael am 02. Dezember 2008 um 13:55

Ich danke Dir für diesen Beitrag, der für mich in die Kategorie „Was Sie schon immer gerne über Typo3 wissen wollten, aber nie zu fragen wagten.“ gehört.

Danke!

ChristianS am 03. Dezember 2008 um 10:15

Hi!
Danke für den tollen Artikel.

Falls jemand die Crawler-extension benutzt sollte er die zugehörige DB Tabelle (tx_crawler_queue) ebenfalls regelmäßig leeren.

Ich mach das alles mit einem kleinen Cronjob:

#! /bin/sh
#
# loescht die cache & index tabellen

# declaring the constants
PATH=/bin:/sbin:/usr/bin:/usr/sbin
MYSQL_USER=“DB_USERXX“
MYSQL_USER_PASSWORD=“XXX“
MYSQL_DATABASE=“typo3″
SCRIPT_NAME=“mysql_cache_index_leeren_cmds“

mysql –user=$MYSQL_USER –password=$MYSQL_USER_PASSWORD –database=$MYSQL_DATABASE –force < /mnt/hdd2/scripts/$SCRIPT_NAME;

// Script mysql_cache_index_leeren_cmds
// leert mit TRUNCATE die entsprechenden Tabellen + quit

TRUNCATE cache_extensions \G
TRUNCATE cache_hash \G
TRUNCATE cache_imagesizes \G
TRUNCATE cache_md5params \G
TRUNCATE cache_pages \G
TRUNCATE cache_pagesection \G
TRUNCATE cache_typo3temp_log \G
TRUNCATE index_fulltext \G
TRUNCATE index_grlist \G
TRUNCATE index_phash \G
TRUNCATE index_rel \G
TRUNCATE index_section \G
TRUNCATE index_words \G
TRUNCATE tx_crawler_queue \G
\q

Jürgen G. am 03. Dezember 2008 um 21:58

Eine Alternative zu „kj_recycler“ stellt auch „CleanDB (Key: tmsw_cleandb)“ dar.

Die Extension macht im Endeffekt das Gleiche wie die vom Autor genannte Extension und löscht alle Datensätze, die in der Datenbank nur mit einem entsprechenden Flag versehen wurden.

Hahnefeld am 14. Januar 2009 um 09:45

Das Löschen der angegeben index.html in den Verzeichnissen uploads/… ist mit Vorsicht zu geniesen. Diese Dateien verhindern in fehlerhaft konfigurierten Systemen das Listing der Verzeichnisse!

Das pauschale Löschen der angegeben DB-Tabellen cache_* oder gar index_* hat den Vorteil, dass die index_search auch gleiche deinstalliert werden kann.

Alles in allem halte ich den Ratschlag so allgemein zu geben für ziemlich leichtsinnig.

Gruss.

Peter am 20. Januar 2009 um 13:26

Wer zudem Probleme mit dem PDF Generator hat, der kann sich diesen Post noch anschauen:
http://blog.marit.ag/2009/01/30/die-langsamkeit-des-pdf-generators/

Die Performance Einbußen können durch das Nichtlöschen von generierten PDFs kommen. Wenn der Ordner sehr voll ist, dauert ein Dateizugriff natürlich auch dementsprechend.

Tim Lochmüller am 30. Januar 2009 um 18:42

1. @peter:
– index.html korrekt. aber eben auf leichtsinnig konfigurierten servern.
– db-tabellen cache_ können völlig problemlos geleert werden. Genaugenommen macht ein cache-leeren mittels des hinlänglich bekannten Knopfes auch nix anderes.
– index_ auch diese tabellen sollte man *hin und wieder* leeren. Sonst hängen dort Dinge aus Anno Schnee rum, werden ‚gefunden‘ sind aber nicht mehr da.

2. @author: zu sys_history würde ich noch sys_log hinzunehmen. aber auch hier sei darauf aufmerksam gemacht: dort werden bestimmte logging daten gespeichert, die dann natürlich weg sind.

kj_recycler: Ist mit Vorsicht zu geniessen. Ich habe es noch nicht 100% verifiziert (also den code genau angeschaut), aber es scheint, als ob die extension bilder die in flexformfeldern referenziert werden nicht als solche erkennt und löscht. und das ist eher übel. auch wenn ich kaum extensions kenne die das mit flexform lösen, ausser einer eigenentwicklung. 😉
Allerdings scheint es im TYPO3 internen Tool das selbe Prob zu geben.

wenn wir auf das thema performance eingehen: die simple pagehit statistic deinstallieren, config.stat_mysql=0 eintragen, und die tabelle sys_stat löschen.
Das Modul ist für den professionellen Einsatz völlig ungeeignet, und müllt nur die Datenbank zu. Vom HDD IO will ich jetzt mal gar nicht reden …

Clemens am 25. Februar 2009 um 23:49

Die Extension „rempic“ (Clean up Typo3) ist auch mit äußerster Vorsicht zu geniesen! Die hat bei mir schon alle auch noch benutzen Bilder in den News entfernt 🙁

Grüsse, Michael

Michael am 26. Februar 2009 um 14:38

Ich habe die Extension kb_cleanfiles installiert. Allerdings werden mir nur die index.html Dateien angezeigt.
Ich habe extra ein neues Inhaltselement angelegt, ein Bild eingebunden und dann das Inhaltselement wieder gelöscht. Keinerlei Auswirkung auf kb_cleanfiles.
Das Selbe bei Extensions. Nur die index.html Dateien.

Timo am 26. Februar 2009 um 16:44

Weiß jemand, wie ich das Löschen der überflüssigen Dateien im „uploads“ Ordner automatisieren kann z.b. mit einem Cronjob?

Holger am 26. August 2009 um 22:13

ahh…. hast du den Post oben gelesen? Da steht es doch drin. Oder denken wir an einander vorbei?

Tim Lochmüller am 26. August 2009 um 22:27

weiß nicht welchen Post du meinst, habe aber jetzt selbst eine Lösung gefunden:

in den Unterordner „typo3“ wechseln, dort
./cli_dispatch.phpsh lowlevel_cleaner lost_files -r –refindex update –AUTOFIX –YES -s

ausführen. Das löscht automatisch alle Dateien im Uploads Ordner, die nicht mehr referenziert sind. Ausführung auf eigene Gefahr.

Holger am 26. August 2009 um 23:03

Hallo, ich habe 2 Fragen:

1.Der typo3 recycler funktioniert nicht bei Versionierung, siehe: http://forge.typo3.org/projects/show/extension-recycler

Wie werde ich meine Datensätze – zb. uralt tt_news Einträge – trotzdem los?

2. In der DB-Überprüfung bei Database Relations habe ich massig Fehlermeldungen nach folgendem Muster (zum Teil deshalb, weil ich bei übersetzten tt_news die übersetzte Seite nicht vor dem Löschen der tt_news Seite mit der Standardsprache gelöscht habe)

There are 5 records pointing to this missing or deleted record; [tt_news][623]

Dabei handelt es sich immer um endgültig gelöschte Seiten, im recycler ist überhaupt nichts mehr, aber in der Datenbank sind eben – wg. Frage 1 – noch alle alten Sachen drin.

Hier bin ich schonmal fündig geworden, aber leider bricht der Lösungsansatz ab:
http://www.mail-archive.com/typo3-german@lists.typo3.org/msg01973.html

Mein Versuch, in der Datenbank direkt zu bearbeiten, führte zu Fehlermeldungen im Protokoll, siehe hier:
http://www.typo3forum.net/forum/typo3-4-x-fragen-probleme/46579-db-berpr-fung-macht-probleme.html

So, jetzt meine Frage:

Wie ist die Vorgehensweise beim Reparieren des Referenz Index?

gruss g.k.

g.k. am 16. Juli 2010 um 09:25

kb_cleanfiles löscht auch aktuell verlinkte Zauberbilder. Hat jemand das gleiche Problem?

R. Schwarzenbach am 08. März 2011 um 10:18

Um „automatisiert“ mit dem internen „DB-Überprüfung“-Tool zu arbeiten habe ich mir die folgende einfache Shell-Zeile zurechtgelegt. Ausgabe der Überprüfung in eine Datei (clean_files.txt) schreiben und folgendes auf der Kommandozeile ausführen:

awk ‚{ print $0}‘ clean_files.txt | xargs rm

Sefoo am 27. September 2011 um 17:48

Besten Dank für die Zusammenfassung. Ist zwar schon etwas älter, hat mir aber dennoch weiter geholfen. „Database Relations“-> „Dateien, die in keinem Eintrag verwendet werden (bitte löschen!)“ war genau was ich gesucht hatte…

LautundKlar Passau am 19. Oktober 2011 um 10:32

Wie kann man im Fileadmin nicht genutzte Daten finden? Jemand Erfahrung mit softreference index?

Andrea am 21. März 2013 um 18:20

Unter 4.7.10 läuft die Extension nur mit ein paar kleinen Modifikationen, ich hab die mal hier zusammengefasst:

http://seitdem.de/2013/04/04/kb_cleanfiles-unter-typo3-4-7-10/

Daniel Hoffmann am 04. April 2013 um 15:40

Sorry, ich nutze DAM! Im normalen fileadmin sieht man ja die Referenzen, aber im DAM leider nur die DAM Referenzen. Jemand was in der Trickliste?

Andrea am 05. April 2013 um 14:55
Ein Kommentar hinterlassen


 Name


 Mail (wird nicht veröffentlicht)


 Website

Bitte beachten sie, dass ihr Kommentar möglicherweise erst freigeschaltet werden muss.

Kategorien

Archiv (Quick)

Mai 2016
M D M D F S S
« Apr    
 1
2345678
9101112131415
16171819202122
23242526272829
3031