URL Rewriting mit coolUri und Typo3 Installation in Unterverzeichnis
In diesem HowTo wird beschrieben, wie man SEO freundliche, lesbare URLs mit der Typo3 Extension coolUri erstellt. Es wird der Use Case einer Typo3 Installation in einem Unterverzeichnis angenommen, welches in den generierten URLs ausgeblendet werden soll.
Als Testumgebung dient ein Typo3 Version 4.7.7 und coolURI Version 1.0.37.
Standard Typo3 URLs
Typo3 hat von Haus aus die Eigenschaft, Seiten mit einer ID zu versehen. Diese werden dann über die index.php als Query String per HTTP Get übergeben. Für eine Domain http://www.example.org erhält man so eine Struktur für die Haupt- und Unterseiten, die keinen Aufschluss darüber gibt, worum es auf den jeweiligen Seiten geht.
http://www.example.org/index.php?id=123
bzw. andere IDs.
URL Rewriting per .htaccess
Um lesbare URLs zu erzeugen kann man entweder auf URL Rewriting per .htaccess zurückgreifen und den Seiten eine quasi statische URL zuweisen, die der Webserver (z.B. Apache) dann auf die jeweilige Typo3 Unterseite matcht und diese ausgibt.
Dies eignet sich für Websites mit einigen wenigen Seiten, die selten verändert werden. Neue Seiten müsste man per Hand in der .htaccess eintragen
Grundsätzlich ist in die .htaccess die neue (statische) URL einzutragen und die URL der Typo3 Seite, auf die gematcht werden soll:
RewriteEngine On
RewriteRule /neue-statische-url.html /index.php?id=321 [L]
Man kann hier auch mit regulären Ausdrücken arbeiten, um Seiten zu matchen, aber das soll hier nicht das Thema sein.
URL Rewriting mit coolUri
Zum Glück gibt es für Typo3 eine Reihe Extensions, die das URL Rewriting bequem und automatisiert direkt im Typo3 erledigen.
Die wahrscheinlich bekannteste Extension ist RealURL.
RealURL kann je nach Anwendungsfall mit einigem Konfigurationsaufwand verbunden sein, wohingegen die Extension coolURI verspricht, mit wenigen Schritten zum Ziel lesbarer, SEO freundlicher URLs zu kommen.
Einfache Konfiguration bei neuer Typo3 Standardinstallation
Angenommen es handelt sich um eine neue Typo3 Seite die direkt unter dem Dokumentenstamm (Dcument Root der httpd.conf im Apache) der Domain liegt: Glückwunsch!
- CoolURI einfach im Typo3 Backend per Extension Manager laden und installieren.
- Die im Installationsverzeichnis von Typo3 (hier: Document Root) liegende _.htaccess umbenennen in .htaccess
- Die im Extension Verzeichnis von CoolURI Default Konfigurationsdatei
/typo3conf/ext/cooluri/cooluri/CoolUriConf.xml_defaultin das Verzeichnis/typo3conf/kopieren und umbenennen in CoolUriConf.xml
Eintrag im TypoScript Template
Setup Typoscript im Seiten-Template aufrufen und an geeigneter Stelle folgende Zeilen einfügen
page.config {
simulateStaticDocuments = 0
tx_cooluri_enable = 1
redirectOldLinksToNew = 1
}
Das war’s!
Typo3 Installation in einem Unterverzeichnis
Liegt Typo3 nun nicht direkt im Document Root der Domain, sondern in einem Unterverzeichnis, hängt es davon ab, wie die Typo3 Website in diesem Unterverzeichnis angesprochen wird.
301 Redirect
Wird die Domain z.B. per 301 Redirect in einer im Document Root liegenden .htaccess Datei weitergeleitet auf das Unterverzeichnis, etwa mit
Redirect 301 / /unterverzeichnis/index.php
so ist dies auch in der Adresszeile des Browsers sichtbar und man braucht für die Konfiguration von coolURI nichts weiter zu beachten als oben beschrieben. Lediglich beziehen sich die letzten beiden Arbeitsschritte auf das Unterverzeichnis, also die im Typo3 Verzeichnis liegende _.htaccess.
Man hat also 2 .htaccess Dateien: die erste im Documentenstamm beinhaltet lediglich eine Weiterleitung ins Typo3 Installationsverzeichnis (hier: /unterverzeichnis/) und in diesem liegt die Standard Typo3 .htaccess, die man ausser dem Umbenennen sonst nicht weiter zu editieren braucht.
coolURI Konflikte mit RealURL
Wenn man vor der Installation von coolURI ein wenig mit RealURL herumexperimentiert hat und sich der Einfachheit halber dann für coolURI entscheidet, wird man höchstwahrscheinlich Problem bekommen. Spätestens bei URLs mit 2 Verzeichnisebenen im Pfad also etwa http://www.example.org/unterverzeichnis/noch-ein-verzeichnis/seite.html meldet sich coolURI mit Fehler wie:
Page Not Found
Reason: Segment "noch-ein-verzeichnis" was not a keyword for a postVarSet as expected on page with id=unterverzeichnis.
Man kann jetzt stundenlang an der Konfiguration von coolURI herumdoktorn: Es wird nichts ändern, denn coolURI funktioniert einwandfrei. Sucht man im Internet etwa nach der ausgegebenen Error Message, erhält man kaum Themen mit Bezug auf coolURI, dafür aber erstaunlich viele mit Bezug auf RealURL.
Änderungen in der localconf.php
Des Rätsels Lösung ist hier ein (wie auch immer gearteter) Konflikt von coolURI mit einer vorhergegangenen RealURL Installation. Um das Problem zu beheben reicht es, RealURL zu deaktivieren (Man wird es nicht weiter brauchen, denn man will ja das URL Rewriting eh mit coolURI machen). Statt jetzt die Extension zu deinstallieren, Datenbakeinträge, Konfiguration etc. abzuändern, reicht es völlig aus RealURL in der localconf.php im Verzeichnis /typo3conf/ zu deaktivieren. Entweder in einem geeigneten Editor nach dem String realurl suchen und alle Vorkommen löschen. diese finden sich zumindest in den Zeilen, die mit
$TYPO3_CONF_VARS['EXT']['extList'] und
$TYPO3_CONF_VARS['EXT']['extList_FE'] und
$TYPO3_CONF_VARS['EXT']['extConf']['realurl'] beginnen.
Oder man kopiert die entsprechenden Zeilen, kommentiert das Original mit // aus und löscht die Einträge für realurl dann.
Jetzt nochmal den Typo3 Cache leeren und am besten den Cache von coolURI auch (Im Backend unter „Admin Tools“ -> „CoolURI“ und dann unter „Delete/Update all“ auf den Button „DELETE EVERYTHING AND START AGAIN“ klicken.
Schon schreibt CoolURI schöne lesbare URLs mit den im Typo3 Backend vergebenen Seitennamen (So wie sie im Page Tree stehen).
Verändern der automatisch generierten URLs
Alternative Bezeichnungen einzelner URL-Abschnitte kann man für jede Seite ganz einfach über den Eintrag „Alias“ unter WEB -> Page -> Auswählen der Seite im Page Tree -> Select Menu „Page Information“ -> Edit (Stiftchen klicken) und unter Registerreiter „General“ das Input-Feld „Alias“ suchen.
Ebenso lassen sich prima Teilabschnitte (Ordner, Übergeordnete Seiten) einer URL ausblenden, wenn man ebenfalls unter „Page Information“ des entsprechenden URL-Abschnitts (Folder/Parent Page)auf den Tab „Extended“ klickt und dort ein Häkchen bei „Exclude this page from middle of a page path“ setzt.
Eigene statische URLs in coolURI hinterlegen
Man kann darüber hinaus auch ganz einfach statische URLs für Seiten, files, Query Strings anlegen. Hierzu auf „Admin Tools“ -> „CoolURI“ -> „New Link“ und die gewünschte statische URI im Feld URI eintragen, etwa /meine-coole-uri/ und die entsprechenden Parameter der Typo3 Seite unter Parameters eingeben. Und als Sticky markieren (falls man mal die URLs updated, bleiben die unverändert). Eignet sich auch prima in Zusammenarbeit mit anderen Tools wie etwa TEQneers SEO Enhancements, die zwar eine robots.txt und eine sitemap generieren können, aber dafür ebenso die kryptische Typo3 Bezeichnungen verwenden wie index.php?type=841133 für die robots.txt oder index.php?id=123&type=841132 für die Sitemap im XML Format.
Ausblenden des Typo3 Installationsverzeichnisses
Hat man Typo3 nun in einem Unterverzeichnis installiert, könnte man es entweder ins Root Verzeichnis der Domain (Dokumentenstamm) kopieren. Dies ist nicht ratsam. Evtl müssten Datenbank-Einträge angepasst werden, wurden irgendwo absolute Links verwendet oder relative Links in ein nicht unter dem Typo3 Installationsverzeichnis, aber auf dem selben Server liegenden Verzeichnis für Bilder, Files, whatever?
Umsetzen des Document Roots
Die einfacheste Variante ist das Umsetzen des Dokumentenstamms, also die Domain direkt auf das entsprechende Installationsverzeichnis zeigen zu lassen. Auch hierbei ist darauf zu achten, ob sich irgendwelche absoluten Links finden, die nachher broken wären, wenn das Installationsverzeichnis aus der URL verschwindet.
Hat man einen eigenen Server mit Root Zugriff, kann man den entsprechnden Eintrag in der httpd.conf des (z.B.) Apache Web Servers ändern und den Apache Service neu starten.
Arbeitet man nur mit einer Domain, dürfte dies in der httpd.conf zu setzen sein etwa unter
#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
ServerName localhost:80
#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot /usr/web
Eine detailierte Dokumentation findet sich bei der Apache Software Foundation
Evtl. ist hier auch noch die Directory Directive anzupassen.
Arbeitet man mit Virtual Hosts, finden sich diese in der vhost.conf in einem Block, etwa
DocumentRoot /www/example2
ServerName www.example.org
# Other directives here
Umsetzen des Document Roots in einer Server Verwaltungssoftware, etwa PLESK
Hat man keinen direkten Zugriff auf die Konfigurationsdateien des Apache Web Servers, aber etwa Zugriff auf den Server selbst über eine Verwaltungssoftware wie Parallels Plesk, so lässt sich hierüber relativ einfach der Dokumentenstamm ändern. Die entsprechende Domain auswählen (Sollte sich im Dashboard finden oder unter dem Registerreiter „Websites & Domains“ und auf den Link „Hosting-Einstellungen“ neben der zu verwaltenden Domain klicken. In den Hosting Einstellungen den Eintrag Dokumentenstamm entsprechend anpassen auf das Installationsverzeichnis von Typo3.
Sollte sich keine Möglichkeit finden, den Document Root zu ändern oder die Domain auf das Typo3 Installationsverzeichnis zu setzen, kann man dies auch über .htaccess lösen.
Ausblenden des Installationsverzeichnisses mit .htaccess mod_rewrite
Um das Installationsverzeichnis mit der .htaccess per mod-rewrite auszublenden, muss natürlich das Rewrite Module (mod_rewrite) auf dem Apache laufen. Dies vorausgesetzt, reicht im Prinzip ein einziger Eintrag in der .htaccess um alle Anfrage in das Unterverzeichnis umzuleiten, ohne das der User dies in der Adresszeile des Browsers sieht:
RewriteRule !^unterverzeichnis/ unterverzeichnis%{REQUEST_URI} [L]
wobei der exemplarische Name unterverzeichnis natürlich durch den tatsächlichen Namen des Installationsverzeichnisses zu ersetzen ist.
Das ganze noch in eine If Abfrage, ob das Rewrite Module funktioniert, Einschalten der Rewrite Engine und ein Umleiten der Domain auf die Startseite von Typo3 (z.B. Seiten-ID=123), sieht das dann so aus:
RewriteEngine on
RewriteRule ^$ http://www.example.org/index.php?id=123 [R=301,L]
RewriteRule !^unterverzeichnis/ unterverzeichnis%{REQUEST_URI} [L]
That’s it.
Die Standard .htaccess im Installationsverzeichnis (siehe coolURI Installation) kann so bleiben.
Zusätzliche Angaben zur Base URL im Setup TypoScript
Im Typo3 müssen jetzt für coolURI noch die Base URL im Typoscript des Seitentemplates angegeben werden, da sonst das Installationsverzeichnis doch in allen generierten Links wieder auftaucht
page.config {
simulateStaticDocuments = 0
baseURL = http://www.example.org/
absRefPrefix = http://www.example.org/
tx_cooluri_enable = 1
redirectOldLinksToNew = 1
}
Natürlich ist hier der tatsächlich verwendete Domain-Name einzutragen.
Page Not Found Errors bei coolURI und per .htaccess ausgeblendetem Unterverzeichnis
Jetzt sollte alles funktionieren, aber keine der von coolURi generierten URLs wird gefunden, die Original index.php?id=123 aber schon. Woran liegt’s?
Ungültiger Link-Aufbau in t3lib_div bei ausgeblendetem Installationsverzeichnis und Verwendung von coolURI
Um Ihnen endlose Sucherei zu ersparen, hier direkt eine Kurzdiagnose und die Lösung:
Die Seitenaufrufe mit den schicken URLs von coolURI schlagen fehl, weil coolURI in der function cool2params($params, $ref) in der Datei class.tx_cooluri.php einen Verkürzten relativen Link aufruft. Interessanterweise wird der link (die mit coolURI generierte coole URI) exakt um so viele Zeichen am Anfang abgeschnitten, wie der Name des Installationsverzeichnisses lang ist. Wer’s überprüfen mag: einfach mal in Zeile 111 vor dem rekursiven Aufruf
$pars = $lt->cool2params($paramsinurl);
den Wert der Variablen $paramsinurl debuggen oder per echo ausgeben lassen.
Der Wert kommt allerdings schon falsch in der function an, nämlich aus
$params['pObj']->siteScript
wird also irgendwo anders falsch gesetzt.
Hat man Typo3 etwas in ein Verzeichnis „cms/“ installiert, wird aus der Request URI „noch-ein-verzeichnis/seite.html“ eine um 4 Zeichen (inklusive slash) verkürztes „-ein-verzeichnis/seite.html“, was Typo natürlich nicht finden kann. Da dies bei allen Links / URI passiert, wird keine Unterseite über die umgeschriebenen URIs gefunden.
Will man herausfinden, wo diese kaputten Links herkommen, landet man letzten Endes bei der Datei /t3lib/class.t3lib_div.php
Etwa um die Zeile 3640 herum findet sich in der function getIndpEnv($getEnvName) die Stelle, wo die siteScript Variable in die TSFE geschrieben wird
case 'TYPO3_SITE_SCRIPT':
$retVal = substr(self::getIndpEnv('TYPO3_REQUEST_URL'), strlen(self::getIndpEnv('TYPO3_SITE_URL')));
break;
Des Rätsels Lösung ist, das Typo3 den Wert der ‚TYPO3_REQUEST_URL‘ um die Länge der ‚TYPO3_SITE_URL‘ kürzt. Die TYPO3_SITE_URL setzt sich allerding aus dem Host UND dem ausgeblendeten Unterverzeichnis zusammen – im beschriebenen Szenario werden die Länge des String ‚cms/‘, also 4 Zeichen zuviel abgeschnitten.
Ersetzt man hier ‚TYPO3_SITE_URL‘ durch ‚TYPO3_REQUEST_HOST‘, bleibt der URI komplett und coolURI macht wirklich coole URIs.
Auskommentiert und mit erklärenden Kommentaren:
case 'TYPO3_SITE_SCRIPT':
//$retVal = substr(self::getIndpEnv('TYPO3_REQUEST_URL'), strlen(self::getIndpEnv('TYPO3_SITE_URL'))); //causes error in coolUri when rewriting and hiding installation folder
$retVal = substr(self::getIndpEnv('TYPO3_REQUEST_URL'), strlen(self::getIndpEnv('TYPO3_REQUEST_HOST').'/')); //causes problems in coolUri when NOT hiding installation folder
break;
(Alle Angaben ohne Gewähr)
