Realurl ist eigentlich DIE Extension, mit der man die generierten URLs von TYPO3 lesbar umschreiben kann. Was das für Vorteile hat und was der Unterschied zur Simulate Static Docouments ist, steht im Beitrag SSD vs. Realurl.
Mir fällt immer wieder auf, dass viele, die realurl regelmäßig installieren und benutzen, oftmals nichts von den einfachsten Funktionen wissen, die die Erweiterung bereits per Default mitbringt.
Hier ein paar Sachen, die man ausschließlich mit realurl (und ohne weitere Extensions wie phpmyadmin oder realurlmanagement) machen kann:
- Weiterleitungen anlegen (z.B. per 301)
- Realurl Cache leeren
- Generierte Pfade überprüfen und modifizieren
- Seiten aus Pfadgenerierung ausschließen
Wer das schon alles kennt, kann den Beitrag getrost ignorieren.
1. Weiterleitungen anlegen
1.1 Anwendungsfall
Wir haben einige Kunden, die ihre Online-Kampagnen auch mit Offline-Kampagnen kombinieren möchten. So soll z.B. auf Plakaten und in Broschüren eine vereinfachte URL auf eine bestimmte Landingseite für ein iPad Gewinnspiel verweisen.
Die Aufgabe wäre in diesem Fall eine URL nach diesem Beispiel zu genierieren: http://www.domain.org/iPad
1.2 Erklärung
Um eine neue Weiterleitung (extern oder intern) anzulegen, muss man das Backend-Modul „Info“ (innerhalb von „Web“) und danach irgendeine Seite aus dem Baum auswählen. Die erste Select-Box auf der rechten Seite muss auf „RealURL-Verwaltung“ und die zweite auf „Redirects“ stehen. Nun kann man über „Add new redirects“ eine weitere Umleitung einrichten.
Jede Zeile beschreibt eine neue Umleitung. 3 Felder stehen zur Auswahl:
Feld | Beschreibung | Beispiel |
---|---|---|
Source URL | Die relative Ausgangsurl | iPad (steht für http://domain.org/iPad) |
Destination URL | Die Ziel-URL (intern oder extern) | /index.php?id=22 oder /campaign/ipad.html |
Permanent | Permanente oder temporäre Weiterleiung (301 oder 302) | – |
EDIT START
1.4. By the Way
– Bei bereits vorhandenen Weiterleitung finden sich übrigens interessante Informationen über die Anzahl der Aufrufe dieser Weiterleitungs-URL sowie wann diese das letzte Mal genutzt wurde und auch der Referer der letzten Nutzung (sofern vorhanden).
– Man kann natürlich auch auf Dateien verlinken, wenn man das möchte (Beispielsweise wenn die AGB als PDF irgendwo im Fileadmin Verzeichnis liegen: http://domain.org/agb)
1.5 Nachteile
Wie Peter in den Kommentaren erwähnt hat, bedeutet jeder Aufruf einer Umleitungs-URL, dass PHP, MySQL, etc.. aufgerufen werden muss. Eine Umleitung via .htacces (siehe Peters Beispiel unten) ist bei großer Last performanter und schont den Server. Eine Änderung in der .htaccess kann jedoch nicht vom Redakteur gemacht werden.
Hier muss jeder für sich entscheiden: Performance vs. Usability
Beispiel für .htaccess:
RedirectPermanent /iPad http://www.domain.tld/campaigns/landingpage-ipad.html
EDIT END
2. Realurl Cache leeren
2.1 Anwendungsfall
RealURL kann sich „verschlucken“, wenn ein Redakteur eine bestehende Seite durch eine neue ersetzen möchte, wobei diese beiden Seiten gleich betitelt wurden und auf der gleichen Ebene liegen. Obwohl nun die alte Seite ausgeblendet wurde, wird die neue Seite nicht richtig oder gar nicht im Frontend angezeigt. Das liegt schlicht daran, dass der Pfadcache von realurl nicht weiß, welche Seite auszugeben ist.
2.2 Erklärung
In dem oben genannten Fall kann man den Pfadcache gezielt auf dieser einen Seite leeren (sobald beide Seiten nicht mehr gleich betitelt sind oder eine ausgeblendet wurde). Auch hier benötigen wir das Info-Backend-Modul. Danach muss die entsprechende(n) Seite im Baum ausgewählt werden. Innerhalb von „RealURL-Verwaltung“ auf „ID-to-path mapping“ stellen.
Nun sieht man die entsprechenden Einträge im Pathcache (mehrere Zeilen für mehrere Parameter auf der gleichen Seite – z.B. Sprachparamter). In oben genannten Fall reicht es aus, wenn man den Pathcache durch einen Klick auf das Mülleimer-Symbol leert.
Hinweis: RealURL-Pathcache komplett leeren: Man kann den Pathcache auch komplett leeren, wenn man das möchte. So wie oben beschrieben sollte man die oberste Seite im Seitenbaum auswählen und bei Depth auf unendlich stellen. Nun sieht man den Cache des kompletten Baums. Ein Mülleimer-Symbol im Header lässt uns den kompletten Cache leeren.
3. Generierte Pfade überprüfen und modifizieren
3.1 Anwendungsfall
Möchte man eine URL manuell ändern (sollte in der Regel nicht vorkommen – oder etwas stimmt nicht mit der RealURL Konfiguration), so kann man das natürlich auch tun.
3.2 Erklärung
Ähnlich wie bei 2.2 erklärt, lassen sich im „Info“ Modul unter „RealURL-Verwaltung“ und „ID-to-path mapping“ generierte Einträge durch das Stift-Symbol bearbeiten und erneut abspeichern. Diese Änderung hält so lange, wie ihr es in eurer RealURL-Konfiguration vorgegeben habt.
3.3 Screens
4. Seiten aus Pfadgenerierung ausschließen
4.1 Anwendungsfall
Euer Kunde hat sich einen Sysfolder mit dem Namen „Campaigns“ angelegt, in die er seine Kampagnen-Landingseiten unterbringen will. RealURL wird die Seiten dann in diesem Stil anzeigen: http://domain.org/campaigns/landingpage1.html
An der Stelle würde es vermutlich Sinn machen, die Ebene „campaigns“ gar nicht erst in der URL anzuzeigen.
4.2 Erklärung
In den Seiteneinstellungen einer Seite (in unserem Fall „campaigns“) lässt sich ganz einfach ein Haken bei „Exclude from speaking URL“ setzen. Realurl wird diese Seite bei künftigen Pfaderstellungen nicht mehr beherzigen: http://domain.org/landingpage1.html
Hinweis: Wenn der Pfad bereits im RealURL Cache liegt, kann es sein, dass man diesen einmal leeren muss (siehe 2.2)
4.3 Screens
5. Weitere Einstellungen
Im Info-Modul lässt sich außerdem noch die komplette Realurl-Konfiguration ansehen.
Ein weiterer Punkt ist das Error-Log. Hier finden sich alle nicht-vorhandenen URL, die ein Besucher (oftmals auch Spider) aufzurufen versucht haben. Das Error-Log lässt sich dort übrigens auch leeren.
Freue mich wie immer über Feedback von euch
Gruß, Alex
P.S.: Auf TYPO3 Jobsuche in Bayern? Junges Team freut sich über Verstärkung.