Es scheint doch tatsächlich Leute zu geben, die ernsthaft WordPress auf einem IIS (was ist das?) laufen lassen :-)
Naja, es funktioniert wohl sogar. PHP mit MySQL bekommt man da auch ans laufen, also eigentlich kein großes Ding. Wenn da nicht die Sache mit den Permalinks wäre. Denn die erfordern nun mal ein funktionierendes mod_rewrite, was es aber meines Wissens nur für den Apache-Webserver gibt. Zumindest kann der IIS von Hause aus nichts mit den entsprechenden Einträgen in der .htaccess anfangen. Und WordPress ist auch so schlau, erkennt, daß es unter einem ISS läuft und bietet dann für die Permalinks gleich nur die Form mit dem vorangestellten /index.php an. Die sehen dann z.B. so aus:
/index.php/die-wordpress-import-schnittstelle-47/
Gut, es funktioniert auch aber ist doch eher nur ein Notbehelf, eine Krücke. Schöner sieht es natürlich so aus:
/die-wordpress-import-schnittstelle-47/
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 :-)