Das Putzlowitsch Test- und SEO-Blog

Es geht doch, Kontaktformular mit POST und Permalinks

Mein 123 No Rewrite Permalink Plugin hat einen kleinen Nachteil, es können keine Formulardaten per POST an eine Permalinkseite gesendet werden. Deshalb funktionieren z.B. Kontaktformular-Plugins wie der „DD Formmailer“ nicht. Ich habe auf der Pluginseite und auch bei meiner Strato-Permalink-Konfigurationsseite darauf hingewiesen.
Angeregt durch einen Beitrag im WP-Deutschland-Forum habe ich noch mal über das Problem nachgedacht und bin auf eine recht einfache Lösung gekommen. Diese ist zumindest dann praktikabel, wenn es nur um eine oder wenige Seiten mit Formularen geht, in der Regel wird es nur eine Seite für „Kontakt“ oder ähnliches sein. Am Beispiel des schon erwähnten DD-Formmailers werde ich die erforderlichen Schritte beschreiben. Ich gehe davon aus, daß das Formmailer-Plugin bereits installiert ist.

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“.

4 Kommentare »

Der Haken am Trick

Vor einiger Zeit hatte ich das 123 IIS Permalink-Plugin vorgestellt. Durch Kommentare zum 123 No Rewrite Permalink-Plugin wurde ich auf ein Problem aufmerksam gemacht, welches sich auch beim IIS auswirkt. Erfreulicherweise kann man das beim IIS im Unterschied zum Apache-Server wieder ausbügeln, da hier die POST-Daten nicht verloren gehen.

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.

Keine Kommentare »

IIS WordPress Permalinks

Ja, es war mir schon klar, daß ich nicht der erste bin, der sich dieses Problems annimmt. Bei wordpress.org selbst ist es im Codex unter dem Titel „Using Permalinks Without mod_rewrite“ bereits angeschnitten und es gibt auch drei Lösungen dafür. Zwei gehen den Weg über ein spezielles ISAPI-Filter und eine Lösung verwendet auch den 404er Trick. Allerdings werden dort die Permalinks über ein .asp-Programm umgesetzt. Das funktioniert auch für die Oldstyle-Permalinks (WordPress 1.X), als noch alle Rewrite-Regeln in der .htaccess-Datei standen. Meine Lösung funktioniert nur bei den Newstyle-Permalinks (WordPress 2.X), bei denen nur noch die index.php angesprochen wird und die Auflösung der REQUEST_URI WP-intern erfolgt.

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.

Ein Kommentar »

Exoten

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 :-)

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »

Strato Permalink-Plugin ist der Renner

Damit hatte ich nicht gerechnet. Mein ‚123 No Rewrite Permalink‘-Plugin (unbedigt die Anleitung lesen!) erfreut sich großer Beliebtheit. In den letzten drei Tagen wurde es bereits 4 mal runtergeladen. Na gut, davon waren zwei Downloads meine Tests, denn ich prüfe natürlich immer alles vorher, ob es auch funktioniert.

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 ;-)

Keine Kommentare »