Bei der Arbeit mit Typo3 kommt häufig auch der Crawler zum Einsatz. Vor allem beim Caching großer Webpräsenzen ist er eine große Hilfe. Denn es ist gerade hinsichtlich des Zusammenhangs Ladezeit - Suchmaschinenranking wichtig, dass alle Webseiten schnell abgerufen werden können.

Der Crawler zieht seine Konfiguration aus der TSConfig der Rootseite im Backend. Eine ausführliche Anleitung findet sich in der

• Dokumentation Typo3 Crawler und im
• Typo3 Crawler Wiki

Für den Crawler gibt der Pfad "tx_crawler.crawlerCfg.paramSets"die Parameter zur Konfiguration an. Eine normale Konfiguration sieht folgendermaßen aus:

Im Objekt "language", wessen Name i.Ü. frei wählbar ist, werden als Erstes an den Crawler Parameter übergeben. Den String in den eckigen Klammern wertet der Crawler so aus, dass im ersten Teil eine Tabelle angegeben werden kann, aus der dynamisch abgefragt wird und im Zweiten die jeweilige Spalte. Des Weiteren kann man über den Konfigurations-Parameter "procInstrFilter" zusätzliche Extensions in den Crawlprozess einbinden. Die baseUrl gibt dem Crawler die zu crawlende Domain an.

Da Inhalts-Erweiterungen wie z.B. tt_news eine andere Art der Inhaltsverwaltung haben, muss der Crawler daran angepasst werden. Bei tt_news sind die Inhaltselemente nicht kaskardierend an eine Rootseite eingehängt, sondern liegen in einem Ordner. Die Auswahl des jeweiligen Datensatzes erfolgt über einen Parameter in der URL. Diese Funktion muss in der Crawler-TSConfig nachgebildet sein:

Wie man sieht, ist die Übergabe der Paramter ähnlich wie im ersten Beispiel über die Angabe der Datentabelle (tt_news), wobei hier die ID des Sysordners angegeben ist, in dem die News liegen. Damit der Crawler diese Konfiguration nur für die einzelnen Newsbeiträge ausführt, wird er über "pidsOnly" auf die UID der "Singelview"-Seite eingesperrt.

So weit, so gut. Steht ja auch alles in der Doku.

Bei tt_news gibt es darüber hinaus eine Pagination. Diese listet in der LIST - Ansicht alle weiteren Beiträge auf Unterseiten auf, sobald die maximale Anzahl Seiten pro Listenansicht erreicht ist. Diese "Unterseiten" werden über den URL-Parameter "pointer" generiert. Ohne eine entsprechende Konfiguration werden diese Übersichtsseiten aber nicht vom Crawler erfasst. Dies mag für das Caching eventuell unerheblich sein. Wenn man mithilfe des Crawlers und der Extension staticpub jedoch HTML-Seiten generieren möchte, fehlen die Dateien im Ordner der statischen Seiten.

Als Lösung müsste man demnach eine weitere Crawler-Konfiguration anlegen und dem Parameter "pointer" die jeweilige Pagination-ID (Also 1-n) mitgeben. Generell ist die Übergabe dynamischer Parameter über das TSConfig abhängig von der jeweiligen Extension. Wie oben bereits gesehen, kann über die TSConfig dem Crawler eine Tabellenabfrage mitgegeben werden. Und witzigerweise scheinen die Macher des Crawlers auch an den Sonderfall mit der Pagination gedacht zu haben. Bei einem Blick in die Skript-Dateien fällt einem die Funktion "expandParamters" ins Auge, welche die übergebenen Informationen auswertet. Und an diese Funktion kann man auch einen "integer-range" übergeben, im Format [int] - [int]. Im TSConfig würde das folgendermaßen aussehen:

Wobei der Crawler hier die Werte von eins bis 50 durchgeht, unabhängig davon, ob noch Inhalte für die Pagination vorhanden sind. Aber es tut, was es soll, und das ist das Wichtigste :-)

Durch Zufall bin ich durch die google Webmastertools darauf aufmerksam geworden, dass ich eine Fehlerseite auf allen meinen Typo3-Projekten habe, wo eigentlich keine sein sollte. Wenn ich die Indexseite einer Typo3-Installation mit laufendem Realurl folgendemaßen Aufrufe, bekomme ich einen 404 Fehler:

http://www.domain.de/index.html

bzw. das für Realurl typische

"Segment "index" was not a keyword for a postVarSet as expected!"

Normalerweise bedeutet dieser Aufruf ja "gib mir die Startseite zurück". Da eber einige eingehende Links auf die index.html verweisen, wollte ich diese per 301-Weiterleitung auf die Startseite "/" umziehen.

Dafür wollte ich per htaccess eine Weiteleitung setzen. Das geht bekanntermaßen per Redirect:

Geht aber nicht, und der Fehler ist sogar nachvollziehbar. Da normalerweise ein Aufruf des Domain-Wurzelverzeichnisses den Aufruf der Index-Datei zur Folge hat, ist obige Anweisung eine Endlosschleife. Sozusagen "Leite von der Indexseite auf das Wurzelverzeichnis auf die Indexseite".

Die Lösung bringt Typo3 mit. Wobei ich mich ehrlich gesagt darüber wundere, dass sie funktioniert... Bei installiertem Realurl können die sprechenden URLs über das "Info" Modul im linken Backend-Menü administriert werden (Info->"Speaking URL Management" im Dropdown). Im daraufhin erscheinenden Dropdown "Redirects" auswählen. Dort auf "New Entry". Url ist demnach die "index.html", die weitergeleitet werden soll auf "Destination"->"http://www.domain.de/". Natürlich per 301, man will ja nichts verschenken :-). Dann wird sauber weitergeleitet.

Was ich nicht verstehe - vielleicht hilft hier jemand weiter, der mehr Ahnung hat: Wo ist der Unterschied, ob ich die Weiterleitung per htaccess setze oder per Skript im header? Sollte die Endlosschleife nicht in beiden Fällen auftreten? Naja, ich bin froh, das es jetzt erstmal läuft!

Nachdem ich das Problem der großen Seitenbäume durch einen Workaround lösen konnte, stand ich jetzt bei dem gleichen Projekt vor dem Problem, dass die Seitentitel zu lang waren und im Backend abgeschnitten wurden. Jeder Titel wird standardmäßig nach 30 Zeichen gekürzt. Wenn innerhalb dieser 30 Zeichen kein individuelles Merkmal der Seite erscheint, hat man keine Möglichkeit, die Seiten voneinander zu unterscheiden. Die Lösung is, dass man im Typo3 für die Backend-Benutzer den "Standard-Abschnitt" und die Anzeige vergrößert:

TSconfig des BE-Users oder besser der BE-Benutzergruppe:

Gefunden habe ich die Lösung bei Sebastian. Thx!

Eine coole Extension von Typo3 ist der Crawler. Er hat die simple Aufgabe, alle veröffentlichten Seiten einer Präsenz nacheinander aufzurufen. Das Prinzip ähnelt dabei dem eines Suchmaschinen-Spiders, der sich anhand der gesetzten Links durch eine Webseitenstruktur hangelt. Am ehesten entspricht der Crawler also einem Linkspider, wie etwa dem Programm Xenu.

Wofür ist das gut?

Der Crawler für Typo3 hat die primäre Funktion, die aufgerufenen Seiten in den Cache zu schreiben, damit diese schneller geladen werden. Das ist vor allem bei Webseiten mit vielen Unterseiten, die selten besucht werden, sinnvoll. (Gerade vor dem Hintergrund, dass Ladezeiten von den Suchmaschinen eventuell als Rankingfaktor angesehen werden, macht es Sinn, eine Webseite nicht von googlebot cachen zu lassen, sondern dies selbst zu tun - aber das nur am Rande.)
Darüber hinaus kann man mit dem Crawler in Verbindung mit weiteren Extension wie z.B. staticpub die Präsenz als HTML-Seiten speichern, oder zeitgesteuerte Veröffentlichungen starten.

Jetzt hatte ich vor kurzem den Sonderfall, dass ich ein Typo3-System nur für das Schreiben statischer HTML-Seiten konfiguriert habe. Die komplette Installation wollte ich per htaccess für den direkten Zugriff sperren. So weit so gut. Nur dass der Crawler jetzt auch zur Passwort-Eingabe aufgefordert wurde. Der Seitenaufruf per Inurl-Login wie user:passwort@domain.de hat auch nicht funktioniert. Was tun?

Die Lösung: Verzeichnisschutz mit IP-Freigabe

Bezeichenderweise war die Lösung (mal wieder) bei Selfhtml zu finden. Wie dort beschrieben, kann man in der htaccess den Zugriff von bestimmten IPs, IP-Bereichen oder Namensadressen zulassen. In diesem speziellen Fall trägt man einfach die IP des Webservers ein, auf dem die Typo3-Installation liegt.

Von dort aus wird ja auch der Crawler gestartet. Da sich die IP des Server  (in der Regel :-) nicht ändert, gibt es auch keine Probleme mit der Zuverlässigkeit. Nur beim Serverumzug oder wenn man evtl. das Webpaket wechselt, muss man den Verzeichnisschutz anpassen. Das sollte man sich - zusammen mit allen anderen Hacks - in der privaten Changelog notieren :-).

Jetzt gibt es natürlich die Möglichkeit, sich über die Listenansicht eine beliebige Anzahl Datensätze anzuzeigen (ganz unten, "Erweiterte Ansicht" aktivieren). Darüber kommt man an die Seiten ran, wenn man sie editieren möchte.

Probleme hat man, wenn man z.B. einen internen Link setzen will. Dann wird im PopUp ganz normal der Seitenbaum ausgelesen und bei 1000 ist Schluss.

Der Workaround

Ich habe wie gesagt keine Lösung gefunden, wie man die maximale Anzahl der Seiten im Baum erhöhen kann. Weil ich in diesem speziellen Fall weniger als 2000 Seiten habe, konnte ich über die Funktionen unter "Funktionen" die Sortierung der Inhaltselemente umkehren und so an die verschütteten Seiten gelangen. Das ist natürlich nur sehr eingeschränkt praktikabel.

Hat jemand eine andere Lösung? Vielleicht habe ich ja etwas total Naheliegendes übersehen?! Freue mich auf Vorschläge!

Kommt selten vor, dass ich ein Typo3-Problem mit Hilfe von Google nicht lösen kann. Nach 2 Stunden ergebnisloser Suche werde ich wohl einen Workaround bemühen.

Das Problem

Ich betreue eine Typo3-Seite mit über 10.000 Inhaltsseiten. Zum Teil sind mehr als 1000 Unterseiten unter einer "Parent" - Seite eingehängt. Wenn ich den Seitenbaum im Typo3 aufklappe, zeigt er mir die ersten 1000 Seiten an und schneidet den Rest ab.