Durch Permalinks bekommen Artikel und Seiten lesbare URLs und auch Struktur. Alle Artikel in der Kategorie ‘Wordpess’ können mit schnurpsel.de/themen/wordpress/ aufgerufen werden, das Monatsarchiv für Juli 2010 mit schnurpsel.de/date/2010/07/.

Auf dem Webserver existiert aber kein Verzeichnis /themen/wordpress/ oder /date/2010/07/. Damit die Seiten trotzdem aufgerufen werden können, erstellt Wordpress eine einfache Regel für das Rewrite-Modul des Apache-Webservers:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Diese drei Zeilen führen dazu, das alles, was nicht tatsächlich als Datei oder Verzeichnis auf dem Server existiert, einfach an die index.php von Wordpress durchgereicht wird. Wordpress kümmert sich nun darum, ob es z.B. eine Kategorie “Wordpress” gibt, stellt die Liste mit den passenden Artikeln zusammen un gibt sie aus.

Was es alles nicht gibt

Im Moment sind wohl mal wieder ein paar Bots oder Skriptkiddies unterwegs, die einfach versuchen, irgendwelche php-Skripte aufzurufen, um mögliche Sicherheitslücken ausnutzen zu können. Das sieht dann etwa so aus:

/scripts/setup.php
/pma/scripts/setup.php
/phpMyAdmin/scripts/setup.php
/phpmyadmin/scripts/setup.php
/myadmin/scripts/setup.php

Solche Dateien gibt es hier allerdings nicht. Auch andere Sachen können zu fehlerhaften Aufrufen führen, z.B. Standard-Icons wie favicon.ico oder apple-touch-icon.png, die manche Browser einfach aufrufen oder durch Nutzer aus der Bildersuche falsch kopierte BILd-URLs.

Durch die für die Permalinks notwendigen mod_rewrite-Regeln werden alle dies Aufrufe nun an Wordpress weitergeleitet. Wordpress wird geladen, stellt eine Datenbankverbingung her, klappert die internene Rewriteregeln ab um schließlich nur festzustellen, daß es mit dem Aufruf nichts anfangen kann. Dann gibt Wordpress schließlich auch nur eine Fehlerseite aus, die möglicherweise auch noch aufwändig gestaltet ist und unnötig viel Daten als Antwort zurücküberträgt.

Wordpress und den Webserver entlasten

Damit nun nicht Wordpress wegen jeder Kleinigkeit behelligt werden, kann man eine spezielle Regel der Wordpress-Regel vorschalten, die einfach gegebenfalls die Abarbeitung der Rewrite-Regeln beendet:

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

Die Idee dabei ist, daß alle Permalink-URLs normalerweise keine Dateierweiterung wie .html, .jpg oder .php haben. Falls nun eine Datei nicht existiert (RewriteCond) und diese Datei mit einem Punkt und mindestens einem weiteren Zeichen endet, wird die Abarbeitung der Regeln an dieser Stelle beendet (RewriteRule). Diese Zeilen müssen vor den Wordpress-Regeln stehen.

Wordpress bekommt diese Aufrufe nicht mehr zu sehen, der Fehler wird einfach vom Webserver behandelt. Hier kommt dann auch eine konfigurierte und vorhanden benutzerdefinierte Fehlerseite zu Anwendung.

Ich weiß, es gibt auch Blogger, die aus welchen Gründen auch immer, die Permalinks mit einem abschließenden .html konfiguriert haben. Aber auch das ist kein Problem, es muß nur eine Zeile hinzugefügt werden, welche die Regel für die Endung .html (oder eine andere) ungültig macht:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI}	!\.html$
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Optimierte Version

Mann kann die zusätzlichen Bedingungen auch direkt in die Wordpress-Rules einfügen. Nachteil hierbei ist aber, daß sie bei Änderungen an den Permalinkeinstellungen verloren gehen, weil Wordpress den Block zwischen # BEGIN WordPress und # END WordPress neu schreibt:

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

Die Version mit Endung .html:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$ [OR]
RewriteCond %{REQUEST_URI}	\.html$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Plugin-Version

Angeregt durch die Kommentare von Ralf habe ich nun eine Plugin-Version fertig gestellt.

Download: 123 Rewrite Error 0.10

Das Plugin schreibt die Regeln beim Aktivieren, Deaktivieren und bei Änderungen an der Permalinkstruktur wie bei der Optimierten Version beschrieben automtisch mit den Wordpress-RewriteRules in die .htaccess. Dabei wird auch gleich berücksichtigt, ob in der Permalinkstruktur eine Erweiterung wie .html angegeben wurde.

Fazit

Wieviel Serverlast oder Traffic durch diese Maßnahme eingespart wird, kann ich nicht sagen. Das hängt sicher auch vom Nutzungsprofil und der Konfiguration der Website ab. Aber warum sollte man solch eine einfache Möglichkeiten auslassen, um Wordpress und dem Webserver das Leben ein bißchen leichter zu machen.

Die Diskussion taucht immer wieder mal auf, wie sieht optimalerweise ein Permalink, also die Struktur der URL aus. Sollten das Datum oder die Artikel-ID enthalten sein, ist es sinnvoll Kategorien oder Tags mit aufzunehmen?

Eine allgemeingültige und endgültige Empfehlung kann es nicht geben, wenn man die unterschiedlichen Sichtweisen dazu berücksichtigt, die dann zu eher widersprüchliche Aussagen führen.

Betreibt man ein Blog im Sinne eines Tagebuches, ist sicher das Datum oder Bestandteile davon eine gute Wahl. Aus SEO-Gesichtspunkten bzw. für eine eher thematische Ausrichtung wird oft die Kategorie mit in die Permalinkstruktur aufgenommen. Für eine Webseite mit vielen Schreibern könnte auch der Autorenname eine geeignete Option sein.

Ich habe mir einfach mal die Permalink-Struktur der 33 deutschen Top-Blogs angesehen. Vielleicht läßt sich ja daraus eine Empfehlung ableiten.

Die Permalink-Struktur der 33 deutschen Top-Blogs

Zunächst stellt sich natürlich die Frage, welche sind denn die Top-Blogs in Deutschland? Auch hier kann man sich endlos streiten, wenn man will. Ich habe als erste Näherung einfach die aktuell zusammengerechnete Liste von heute, dem 24.02.2010, genommen. Die Permalinkstruktur habe ich in Gruppen zusammengefaßt, vor dem jeweiligen Blog steht der aktuelle Platz in der Top-33-Liste :

• Jahr, Monat, Tag und Artikelname (13)
  • 2. netzwertig.com
  • 3. Nerdcore
  • 4. Basic Thinking Blog
  • 10. Spreeblick
  • 12. Werbeblogger
  • 13. GoogleWatchBlog
  • 18. Die Fünf Filmfreunde
  • 19. Netzökonom (vorangstelltes ‘archive’)
  • 22. WordPress Deutschland Blog
  • 23. Lummaland
  • 25. MACNOTES.DE
  • 29. law blog (vorangstelltes ‘archives’)
  • 32. allesaussersport (vorangstelltes ‘archiv’)
• Jahr, Monat und Artikelname (5)
  • 11. Internet-Law
  • 15. Les Mads
  • 17. fscklog
  • 24. Indiskretion Ehrensache
  • 27. Alles Schall und Rauch
• Jahr und Artikelname (1)
  • 6. netzpolitik.org
• Artikelname (6)
  • 1. Stefan Niggemeier
  • 8. Caschys Blog
  • 16. Ruhrbarone
  • 30. 1x umrühren bitte (vorangstelltes ’stories’)
  • 31. Design Tagebuch
  • 33. Druckerei Blog
• Nummer und Artikelname (3)
  • 7. CARTA
  • 9. BILDblog
  • 20. UPLOAD Blog
• Artikelname und Nummer (1)
  • 5. StyleSpion
• Sonderformen (1)
  • 28. Elektrischer Reporter Kategorie (video) ? und Nummer
• Keine Permalink, Nummer als URL-Parameter (3)
  • 14. NachDenkSeiten
  • 21. MC Winkels weBlog
  • 26. Fefes Blog

Mehr als die Hälfte (57,6%) der Top-33-Blogs verwendet neben dem Artikelnamen das Datum oder einen Bestandteil davon in der URL. Bei allein fast 40% findet man das komplette Datum mit Jahr, Monat und Tag im Permalink. Gut 18% benutzen nur den Namen des Artikels als Permalink und weitere etwa 12% kombinieren dazu noch eine Nummer (Artikel-ID). Immerhin knapp 10% der Top-Blogs verwenden keine Permalinks, sondern setzen auf die Artikelnummer als URL-Parameter (?id=1234).

Erste Ableitung des Permalink-Aufbaus

Wenn man Permalinks verwendet, ist der Artikelname (in seiner Umwandlung zu einem URL-Pfad) gewissermaßen eine feste Größe. Die Einbeziehung des Datums oder von Teilen kann so schlecht nicht sein, diese Verwendet ein Großteil der Top-Blogs. Auch ganz auf Permalinks zu verzichten, hat gewisse Vorteile. Die URLs sind kurz und bleiben immer gültig, auch wenn man mal was am Artikel-Titel, dem Datum oder sonstigen Einflußfaktoren ändert.

Ich habe mir stichprobenartig noch weitere Blogs der Top-100 angesehen und zumindest keine Seite entdeckt, die etwa die Kategorie oder gar Tags in der URL verwendet. Mal davon abgesehen, daß Tags bei Wordpress bis zur Version 2.9.x nicht als Bestandteil der Permalinks funktionieren (obwohl in der Dokumentation genannt), gibt es auch noch andere Probleme.

Kategorie oder Tag im Permalink

In Wordpress kann man Artikel in mehreren Kategorien ablegen. Einem Artikel können zudem auch mehrere Tags zugeordnet werden. Verwendet man Kategorien oder Tags in Permalinks, erstellt Wordpress die die URL aus der Kategorie oder dem Tag mit der kleinsten ID. Ändert man nun die Kategoriezuordnung oder die Tags, kann sich möglicherweise auch die URL ändern.

Das ist aber erstmal nicht weiter schlimm, denn der Artikel wird auch weiterhin mit der alten Kategorie gefunden und angezeigt. Wordpress geht sogar soweit, einfach die Kategorie beim Auflösen der Permalinks zu ignorieren. Damit ergeben sich dann theoretisch beliebig viele URLs für einen Artikel.

Als Beispiel ist das auf meinem Testblog zu sehen. Die Permalink-Struktur sieht so aus:

/%category%/%postname%/

Der Artikel ist in der Kategorie “Allgemein” einsortiert, die URL sieht so aus:
http://testblog.schnurpsel.de/allgemein/hallo-welt/

Er ist aber auch mit der Kategorie “Blafasel”, “Hundekuchen” oder “Gibtesnicht” aufrufbar:
http://testblog.schnurpsel.de/blafasel/hallo-welt/
http://testblog.schnurpsel.de/hundekuchen/hallo-welt/
http://testblog.schnurpsel.de/gibtesnicht/hallo-welt/
Genau, diese Kategorien gibt es gar nicht.

Man hat damit potentiell also ganz viel bösen “Duplicate content” (DC). Da sage noch einer, die Kategorie im Permalink sei unter SEO-Gesichtspunkten empfehlenswert. ;-)

Permalink, so oder so

Letztendlich muß jeder selbst entscheiden, ob und wie er seine Permalinks gestaltet. Bei Putzlowitsch habe ich mich für das Datum entschieden, da ich dort eher im Sinne eines Tagebuchs schreibe. Hier verwende ich eine Kombination aus Artikelname und Artikel-ID, weil die sichtbare ID schnelle interne Links mit dem 123 IntLink-Plugin ermöglicht. Bei Twitter verwende ich übrigens gerne die WP-Shortlinks mit der ID als URL-Parameter, die sind schön kurz und funktionieren auch ohne Shortlink-Dienst.

Einen kleinen Hinweis daraus findet man auch im Twitter-Hilfe-Forum:

“Twitter used to shorten links automatically but we do not any longer.”

So, mal sehen, ob es stimmt :-)

Nachtrag 22:00 Uhr:
Ja, funktioniert so weit. Nur habe ich nicht bedacht, das bei einem Retweet dann eventuell die 140-Zeichengrenze überschritten wird. Das ist zwar direkt auf twitter.com nicht weiter schlimm und wird trotzdem in voller Länge angezeigt:

Im Feed und vermutlich beim Zugrifff mit den API-Funktionen wird allerdings ab 137 Zeichen abgeschnitten. Da nun der Link am Ende stand, stimmt der dann nicht mehr. So haben dann diverse Twitter-Abfrage-Bots bversucht, diesen falschen Link aufzurufen:

/ueber-kurz-oder-lang-twitter-laesst-wieder-lan

Naja, ist halt Pech. Da werde ich demnächst versuchen, die Links möglichst nicht am Ende zu platzieren. Oder ich nehme doch wieder die wordpresseigenen Kurzlinks mit der Artikel-ID.

In Wordpress kann man für schönere URLs die Permalinks aktivieren. Diese werden nur für die Struktur der Artikel-URL festgelegt, zusätzlich kann ein Präfix für Kategorien und Tags vorgegeben werden, für Seiten jedoch gibt es keine extra Einstellmöglichkeit.

Für Artikle steht eine Vielzahl von von Platzhaltern (Variablen) zur Verfügung, die bei Zusammensetzen der URL durch die jeweiligen Daten des konkreten Artikels ersetzt werden.

Auch wenn man Permalinks nur für die Artikle wirklich konfigurieren kann, wirken sich die dort gewählten Optionen auch auf die Seiten und andere URLs in Wordpress aus. Einen sichtbaren Effekt hat die Entscheidung, ob man die Permalinks mit einem Schrägstrich abschließt oder nicht. Entsprechend erhalten auch alle anderen von Wordpress generierten URLs diesen Schrägstrich oder nicht. Das gilt übrigens nur für den Schrägstrich (Slash), alle anderen Endungen wie z.B. .html werden dabei nicht übernommen.

Wordpress und Rewrite-Rules

Damit Wordpress die Permalinks wieder in konkrete Artikel- und Seiten-IDs auflösen kann, wird eine Liste von Regeln (RewriteRules) erstellt, die sequentiell abgearbeitet wird. Mit dem ersten passenden Treffer wird dann die Datenbankabfrage für einen Artikel oder eine Seite, für eine Kategorie- oder Tagübersicht oder einen Feed usw. erstellt.

Wie diese interne Liste aussieht hängt unter anderem auch davon ab, welche Struktur für die Artikel bei der Permalinkkonfiguration gewählt wird. Wordpress muß Artikel von Seiten eindeutig unterscheiden können und das funktioniert nur, wenn die Permalinks als ersten Platzhalter keinen variablen Wert wie Postname (%postnam%), Kategorie (%category%), Tag (%tag%) oder Autor (%author%) enthalten. Andernfalls werden für jede statische Seite jeweils 11 Einträge in der Liste der RewriteRules erstellt, die so aussehen:

[seite-1/attachment/([^/]+)/?$] => index.php?attachment=$matches[1]
[seite-1/attachment/([^/]+)/trackback/?$] => index.php?attachment=$matches[1]&tb=1
[seite-1/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[seite-1/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[seite-1/attachment/([^/]+)/comment-page-([0-9]{1,})/?$] => index.php?attachment=$matches[1]&cpage=$matches[2]
[(seite-1)/trackback/?$] => index.php?pagename=$matches[1]&tb=1
[(seite-1)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(seite-1)/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(seite-1)/page/?([0-9]{1,})/?$] => index.php?pagename=$matches[1]&paged=$matches[2]
[(seite-1)/comment-page-([0-9]{1,})/?$] => index.php?pagename=$matches[1]&cpage=$matches[2]
[(seite-1)(/[0-9]+)?/?$] => index.php?pagename=$matches[1]&page=$matches[2]

Das mag bei wenigen Seiten zwar kaum ins Gewicht fallen, bei hunderten oder gar tausenden Seiten aber schon. Einerseits belegen diese vielen Regeln Speicher, andererseits müssen sie jedesmal abgearbeitet werden, bei z.B. 300 Seiten mehr als 3300 Listeneinträge. Probleme kann es auch beim Anlegen und Ändern von Seiten geben, denn die Liste muß dann jedesmal neu erstellt werden.

Permalinks für statische Seiten optimieren

Wenn man viele statische Seiten verwendet oder vielleicht gar keine Artikel (Wordpress als CMS), sollte man als ersten Platzhalter (Strukturtag) in den Permalinks einen numerischen Wert wie Datum (year,monthnum,day), Zeit (hour,minute,second) oder die ID (post_id) verwenden. Die von Wordpress zur Auswahl angebotenen Möglichkeiten erfüllen diese Bedingungen:

Für Benutzerdefinierte Einstellungen wären z.B. /%post_id%-%postname%/ geeignet. Es darf auch ein fester Text vor dem ersten numerischen Wert stehen, also z.B. /news/%post_id%-%postname%/.

Mit diesen Permalinkeinstellungen werden keine extra Rules je Seite erzeugt, das spart zumindest bei Wordpressinstallationen mit sehr vielen statischen Seiten Speicherplatz und Abarbeitungszeit.

Seit kurzem unterstützt Strato das für Permalinks wichtige Modul mod_rewrite. Bisher mußte man sich da mit Tricks, wie einem vorangestellten index.php oder dem Fehler 404 Plugin behelfen. Jetzt funktioniert das einfach so, wie es von Wordpress selbst vorgesehen ist, über ein paar mod_rewrite-Regeln.
Wenn Strato jetzt noch die Datenbank-Performance verbessert, könnte man aus Wordpress-Sicht schon fast rundum zufrieden sein.

Nachtrag 09.04.2008: Seit heute findet man auch einen entsprechenden Artikel zu mod_rewrite in den Strato-FAQ.

Zunächst wird eine neue statische Seite erstellt, die z.B. “Kontakt” heißt. Hier wird der Text und Code für den Formmailer eingegeben. Die URL der Seite lautet dann beispielsweise

http://schnurpsel.de/kontakt/

Diese wird bei den Einstellungen für den DD-Formmailer als “Contact page” eingetragen.

Dann wird eine Kopie der Datei index.php aus dem Wordpress-Wurzelverzeichnis erstellt und bearbeitet.
Originale index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>

Bearbeitete index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('../wp-blog-header.php');
?>

Kleine Änderung, große Wirkung, es ist nur ein Punkt beim require hinzugekommen.
Nun wird per FTP im WP-Wurzelverzeichnis ein Unterverzeichnis /kontakt/ angelegt und die geänderte index.php dort hinein kopiert.

Das wars, jetzt kann man die Kontaktseite aufrufen und Daten absenden, sofern man sonst auch alles andere beim DD-Formmailer richtig konfiguriert hat.
Man kann das auch bei mir hier testen, unter Kontakt, wo sonst? :-)

Und zum Schluß noch ein wichtiger Hinweis: Falls man im WP-Wurzelverzeichnis eine php.ini hat, muß diese ebenfalls mit in das /kontakt/-Verzeichnis kopiert werden, denn im Unterschied zur .htaccess werden die dort gemachten Einstellungen nicht auf Unterverzeichnisse “vererbt”.

So gibt es nun also eine neue Version 0.11 des 123 IIS Permalink-Plugins, die auch mit Datenübergabe per POST oder GET funktioniert. Nebenbei habe ich gleich noch eine permanente Weiterleitung (301) der alten ‘/index.php/irgendwas’-Aufrufe eingebaut. So braucht man sich wegen alter Permalinks z.B. bei Google keine Sorgen zu machen.

Generell kann ich die Lektüre der Permalink-Codex-Seite wärmstens empfehlen. Da bekommt man einen guten Überblick, was Permalinks sind, wie sie funktionieren und was man alles damit machen kann (und was nicht). Die Seite sollte auch mal auf Deutsch bei Wordpress-Deutschland aufgenommen werden, viele Fragen im WPD-Forum drehen sich um Permalinks und wären sicher mit dieser Seite einfach beantwortet.

Das muß aber nicht bei der index.php-Variante bleiben, denn das Problem ist ein ähnliches wie bei den Strato-PowerWeb-Paketen, bei denen zwar ein Apache mit mod_rewrite läuft, dieses aber vom Kunden nicht genutzt werden kann. Wenn man es doch versucht, wird das knallhart mit einem 500er Fehler bestraft. Wie man es bei Strato doch hinbekommt, habe ich hier beschrieben.

Für den IIS ist der Ansatz ganz ähnlich. Es wird ein benutzerdefiniertes Fehlerdokument für den Fehler ‘404 Not Found’ “mißbraucht” und dieses ist einfach die ‘index.php’ im Wordpress-Wurzelverzeichnis. Was anderes macht die RewriteEngine praktisch auch nicht, bis auf einen kleinen, aber wichtigen Unterschied. Beim Fehlerdokument wird der Status auf 404 gesetzt, so das der normale Nutzer im Browser zwar keinen Unterschiede sehen würde, denn er bekommt die Seite ganz normal angezeigt. Ein Suchmaschinen-Robot würde die Seite aber wie einen “Not Found”-Fehler behandeln und nicht weiter beachten. Deshalb ist das in der Beschreibung genannte Plugin erforderlich, welches den Status wieder ordentlich zurechtbiegt.

Etwas anders liegt die Sache beim IIS. Wenn eine benutzerdefinierte Fehlerseite als URL aufgerufen wird, wird vom Webserver der Status auf ‘200 OK’ gesetzte und der Fehlerseite als Parameter der Fehlerstatus und die aufgerufene Seite mitgegeben. Hier ist dann die Fehlerseite dafür zuständig, den Status entsprechend korrekt zu setzen. Eine sehr schöne Vereinfachung gegenüber den Verrenkungen, die bei der Stratolösung nötig sind.
Die einzig wirkliche Aufgabe besteht darin, aus dem übergebenen Parameter die eigenlich aufgerufene URL dem Wordpress als REQUEST_URI unterzujubeln, da daraus dann mit den Permalinkregeln die anzuzeigende Seite ermittlet wird.

Lange Rede, kurzer Sinn, genau das macht mein neues Plugin “123 IIS Permalink“. Es ermöglich also auch unter IIS die schönen Permalinks ohne dem /index.php/… Vorspann :-)

Könnte aber sein, das es tatsächlich bereits einen Nutzer gibt. Also falls jemand das erfolgreich bei seinem Strato-Blog im Einsatz hat, würde ich mich über eine kurze Rückmeldung mit Angabe der WP-Version, z.B. hier in den Kommentaren freuen. Oder ich schalte die Kommentare direkt bei der Beschreibungsseite frei. Ja, so werd ichs machen.

Natürlich sind auch Kritik, Problembeschreibungen oder Fragen jederzeit willkommen. Ob ich daruf eingegehen kann, weiß ich allerdings nicht ;-)

Da habe ich mich gestern hier abgemüht, den komplizierten Sachverhalt der Konfiguration eines benutzerdefinierten Fehlerdokumentes darzulegen und extra noch darauf hingewiesen, das mein Plugin des Schreiben der für Strato tödlichen mod_rewrite-Regeln unterbindet, nämlich einfach dadurch, daß ich eine Leerzeile schreiben lasse. Und heute fällt es mir wie Schuppen aus den Haaren, daß ich natürlich genau an der Stelle nur einfach mein “ErrorDocument 404″ einbauen muß. Also vergeßt den ganzen Zauber mit rumgefummle in der .htaccess oder dem Website-Configurator. Es geht viel einfacher so wie hier beschrieben:
Wordpress Permalinks

Praktisch eine Plug&Play-Lösung, Plugin runterladen, aufspielen, aktivieren und fertig.

Man sollt aber tunlichst darauf achten, daß das Plugin immer aktive ist, besonders dann, wenn etwas an den Permalinkeinstellungen verändert wird. Das schreiben der WP-Rewrite-Rules passiert aber auch an anderen Stellen, so z.B einfach schon, wenn die Optionenseite ‘Permalinks’ aufgerufen wird, oder auch wenn neue statische Seiten hinzugefügt oder diese verändert werden.

Achso, das Wetter war heute ähnlich wie gestern. Sonne, Sonne, Sonne und Hitze.

Viel Spaß und Erfolg :-)