Sie befinden sich hier: suit.rebell.at › Artikel › Trailing Slash bei RealURL entfernen

Trailing Slash bei RealURL entfernen

Warum überhaupt?

Seit Matt Cutts vor ein paar paar Jahren in seinem Blog erwähnt hat, dass er einen Trailing Slash bevorzugt, überschlagen sich alle selbsternannten Suchmaschinenoptimierungsexperten mit Ratschlägen, warum der Trailing Slash unbedingt dran muss - wohlgemerkt wird das in seinem Blog-Eintrag mit keinem Wort erwähnt.

Matt Cutts schreibt eigentlich nur, dass man sich auf einen Ressourcenamen einigen soll. Wie er richtig erläutert sind z.B. example.com/, www.example.com/, example.com/index.html oder example.com/index.php für einen Webserver (oder auch für eine Suchmaschine) völlig unterschiedliche Dinge. Kurzum, er rät dazu sich auf eine Variante zu einigen und diese konsequent beizubehalten bzw. auf die "richtige" umzuleiten.

Die Tatsache, dass selbst das W3C bei der Verwendung des Trailing Slash je nach Unterseite teilweise "wild" herumwechselt, aber jeweils auf die entsprechende Variante umleitet, spricht jedenfalls eine deutliche Sprache.

Ich für meinen Teil bevorzuge es, keinen Trailing Slash zu verwenden - da ich meine Artikel als "Dokumente" in den jeweils übergeordneten "Ordnern" betrachte. Im Sinne von HTTP ist das natürlich Unsinn. Wie eingangs erwähnt gibt es lediglich Ressourcen - ob diese tatsächlich einer Ordnerstruktur entsprechen oder wie in unserem Fall mit RealURL nur fingiert sind, spielt keine Rolle.

Zielsetzung und schlechte Lösungen

RealURL bietet auch in Version 1.10.2 keine Konfigurationsmöglichkeit um den Trailing-Slash nicht anzuzeigen ohne auch zugleich ein unsinniges Suffix (wie etwa .html) an das Pfadsegment anzuhängen. Das gilt es zu umgehen, denn wir wollen schöne URLs ohne Trailing Slash:

example.com/artikel/artikelname/ -> example.com/artikel/artikelname

Um den standardmäßig angefügen abschließenen Schrägstrich zu entfernen findet man in den Weiten des Internets teilweise umständliche Lösungen die hardcodiert die Kernfunktionalität von RealURL beeinflussen oder komplizierte XCLASS-Erweiterungen verwenden. Möglicherweise wird man auch auf eine von mir gepostete banle Lösung stoßen - hier wird einfach in der RealURL-Konfiguration defaultToHTMLsuffixOnPrev mit NULL (U+0000) befüllt. Das funktioniert auch recht zuverlässig solange man nicht die "falschen" Extensions installiert, denn hier scheint es generell Probleme mit der Zeichencodierung zu geben - mit einem gelösten Problem hat man also im schlimmsten Fall gleich drei neue am Hals.

Des Rätsels Lösung

Die einfachste Lösung ist ein Hook an die Funktion encodeSpURL() welcher seit Version 1.5.3 enthalten ist. Prinzipiell muss lediglich jedes Vorkommen von / am Ende der Zeichenkette oder /? und /# innerhalb der Zeichenkette um den Slash bereinigt werden. Das ist mit einem regulären Ausdruck ansich keine Hexerei.

Im folgenden Beispiel wird durch den Hook encodeSpURL_postProc die Funktion user_encodeSpURL_postProc() aufgerufen. Natürlich kann die Funktion auch einen beliebigen anderen Namen tragen, auch können (indem man mehrere Funktionsnamen im entsprechenden Array einträgt) mehrere Funktionen nacheinander aufgerufen werden.

Damit später keine endlosen Umleitungsschleifen entstehen muss appendMissingSlash bei älteren Versionen unbedingt auf false stehen, in neueren Versionen ab etwa 1.10.x hingegen sollte der Wert auf true oder 'ifNotFile' gesetzt sein. That's it.

function user_encodeSpURL_postProc(&$params, &$ref) {
	if ($params['URL'] != '/') {
		$params['URL'] = preg_replace(
			'/\/($|\?|\#)/U',
			'\1',
			$params['URL']
		);
	}
}

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['realurl'] = array (
	'encodeSpURL_postProc' => array('user_encodeSpURL_postProc'),
	'_DEFAULT' => array (
		'init' => array (
			// […]
			'appendMissingSlash' => 'ifNotFile',
		),
		// […]
	),
);

Fehlerhaftes RealURL patchen

Leider enthält der Hook in Version 1.5.3 einen Fehler und verwirft den generierten URi komplett sobald man dieses Feature verwenden möchte. Dieser Fehler wurde mit Version 1.7.0 bereits korrigiert, dennoch ist man unter Umständen an die ältere Version gebunden. Wenn man z.B. aufgrund der verwendten Distribution des Webservers auf PHP 5.1.x angewiesen ist, kann man lediglich die ältere Version verwenden, bei der man den Fehler manuell (per Patch) korrigieren muss..

Rewrite-Engine anpassen

Da eventuell vorhandene alte URLs noch mit einem Trailing Slash oder gar dem .html-Suffix ausgestattet sein können ist es schlau diese umzuleite, ansonsten wären die neuen Ressourcen in drei unterschiedlichen Varianten erreichbar.

RealURL stellt dafür aber nichts fertiges zur Verfügung - um nicht viel herumzuprogrammieren reicht eine kleine Regel für die Rewrite-Engine des Webservers. Als Basis dafür verwenden wir denselben regulären Ausdruck den wir schon beim Entfernen des Trailing Slash in RealURL selbst verwendet haben.

Natürlich muss auch darauf geachtet werden, dass nichts umgeleitet wird, was wirklich ein File, einen Symlink oder ein Verzeichnis darstellt.

# […]
RewriteCond %{REQUEST_URI} !^\/$
RewriteCond %{REQUEST_URI} (.*)(?:\/|\.html)($|\?|\#)
RewriteRule (.*) http://example.com%1%2 [R=301]

Weise Worte

Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems. Jamie Zawinski (jwzhacks)

Schlagwörter für diese Seite

Slash, Trailing, com, RealURL, example, encodeSpURL, Version, verwenden, postProc, html

Lesenswerte Artikel