WordPress: Probleme mit der Aktivierung sprechender URLs

Normalerweise arbeite ich im Bereich Content-Management-Systeme mit Drupal (für mehrsprachige oder komplexere Projekte) oder CMS made simple (für einsprachige Websites), doch derzeit werfe ich einen Blick über den Tellerrand und beschäftige mich mit WordPress 3. Damit mir der Einstieg einfacher fällt, arbeite ich seit gestern die dritte Auflage von "WordPress - Das Praxisbuch" (von Vladimir Simovic und Thordis Bonfranchi-Simovic) anhand einer Testinstallation in meinem lokalen XAMPP durch. Das Buch ist zwar noch auf dem Stand von WordPress 2.9, unterschied sich bis Kapitel 3.12 aber nur in wenigen unwesentlichen Details von der 3er Version.

Amazon Werbepause

WordPress - Das Praxisbuch (4. überarbeitete Auflage)

Das Problem

In Kapitel 3.12 angekommen, wollte ich (wie ab Seite 105 beschrieben) sprechende URLs (auch als Pretty-URLs bekannt) aktivieren. Leider endete dies bei jedem Versuch in einer weißen Seite mit dem netten Hinweis Zugriff verweigert (Error 403/Forbidden). Im Gegensatz zu anderen CM-Systemen war jedoch auch das Backend hiervon betroffen. Es zeigte zwar nach dem Umstellen der Permalink-Einstellungen noch kurz die geänderten Einstellungen, aber mit fehlendem CSS-Code und jeder weitere Link führte ebenfalls zu einem 403er.

Die Recherche

Im Gegensatz zu Drupal erstellt WordPress die .htaccess-Datei für die Permalinks von sich aus im Root der Installation, sofern die Rechte hierfür vorhanden sind (was unter Windows der Fall ist). Da ich zudem meine diversen Test-Installationen einfach in unterschiedlichen Unterordnern von XAMPPs htdocs-Ordner mache und dort überall mod_rewrite noch funktionierte, musste ein subtilerer Grund vorliegen. Der derzeitige Inhalt der Datei war nachfolgender:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /unterordner/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /unterordner/index.php [L]
</IfModule>

Also zog ich mal wieder Big G zu Rate und fand als mögliche Ursachen die if-Abfrage und ein deaktiviertes Verzeichnislisting. Beides war bei mir leider nicht direkt die Lösung.

Die Lösung

Die Sache mit dem Verzeichnislisting erinnerte mich daran, daß die .htaccess-Dateien von anderen Systemen um einiges länger ausfallen. Also sah ich mir diese an und ergänzte dann bei meiner WordPress-Testinstallation die nachfolgenden Zeilen mit einem Texteditor (beispielsweise Notepad++):

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Be shy and don't tell everybody everything
ServerSignature Off

Die in Fettschrift markierte Zeile war dann übrigends in meinem Fall des Rätsels Lösung, fragt mich jedoch nicht warum (ich hab echt keine Ahnung).

Fazit

Auch wenn ich den genauen Grund nicht kenne, kann ich nun endlich mit vernünftigen Permalinks arbeiten und habe "nur" eine Stunde mit der Problembehebung verbracht.

Falls ein anderer Fehlercode kommt, so können folgende Gründe möglich sein:

• 500 Server Error: Sehr wahrscheinlich ist mod_rewrite nicht auf dem Server aktiviert.
• 403 Not Found: Ihr habt die Einstellungen für die sprechenden URLs umgestellt und ruft noch einen Link nach dem alten Muster auf.

Letzteres kann übrigends ziemlich nervig sein, wenn schon URLs nach dem alten Muster von Google indexiert wurden. Doch hierfür gibt es mit dem Permalinks Migration Plugin eine passenden Lösung.