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 »

WordPress 2.3 – Problem ohne www bei Strato

Hintergrund

Es war mir ja schon fast am Anfang meiner Strato-Zeit aufgefallen. Die Servervariable HTTP_HOST liefert immer den Hostname mit einem vorangestellten www zurück, selbst dann, wenn der Aufruf ohne www erfolgte. Eigentlich eine eigenwillige, wenn nicht gar falsche Konfiguration des Strato-Severs, denn die Variable HTTP_HOST soll eigentlich genau das enthalten, was der Browser im HTTP-Requestheader übermittelt. Wenn ich also die Seite schnurpsel.de aufrufe, dann sollte eben das da drin stehen, und nicht etwa www.schnurpsel.de. Aber genau das passiert bei Strato (PowerWeb A und S).

Problem

Bisher stellte das auch kein Problem dar, mit dem Neuen WordPress 2.3 aber schon (deshalb war meine Seite gestern Abend auch zeitweise nicht erreichbar). Ab WordPress 2.3 ist eine Funktion integriert, die ein sogenanntes „Canonical Redirect“ ausführt. Auf das Strato-Problem bezogen bedeutet das, daß eine Weiterleitung z.B. dann stattfindet, wenn der Aufruf der Seite nicht so erfolgt, wie das in der WordPresskonfiguration eingestellt ist.
Wenn z.B in WordPress als Blog-Adresse (URL)

http://schnurpsel.de

eingetragen ist, jemand aber die Seite mit

http://www.schnurpsel.de

aufruft, wird er auf

http://schnurpsel.de

umgeleitet (und anders rum). An sich eine sinnvolle Sache, gerade unter SEO-Aspekten.

Was passiert nun aber bei Strato? Die funktion redirect_canonical schaut in HTTP_HOST nach, wie die Seite aufgerufen wurde, stellt fest, daß da ein www steht, aber das Blog ohne www konfiguriert ist. Also wird flux auf die Adresse ohne www weitergeleitet (diese Information bekommt der Browser zurück). Der ruft dann brav die Seite erneut ohne www auf, weil aber Strato das www wieder vorneran stellt, leitet redirect_canonical erneut um, der Browser ruft wieder brav ohne www auf usw. usw. Es ensteht also eine Weiterleitungs-Endlosschleife, die der Browser dann aber (hoffentlich) nach ein paar Versuchen mit einer Meldung beenden sollt. Beim Firefox sieht das dann so aus:

Fehler: Umleitungsfehler
Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.

Das alles tritt aber nur beim Blog selber auf, der Adminbereich ist davon nicht betroffen.

Lösung

Aber auch hier gibt es mit einem bißchen Basteln Abhilfe. Glücklicherweise gibt es in den Servervariablen einen Eintrag, der die tatsächlich aufgerufene Adresse enthält, nämlich SCRIPT_URI. Dieser enthält die vollständigen Aufrufadresse mit http und gegebenfalls Verzeichnis und Dateiname, z.B.

http://schnurpsel.de

Hier kann man einfach den echten Hostanamen extrahieren und der Variable HTTP_HOST zuweisen. Und schon ist die Welt wieder in Ordnung :-)

Also WordPress-Plugin sehen die paar Zeilen PHP-Code dann so aus:

<?php
/*
Plugin Name: 123 True HTTP Host
Plugin URI: http://schnurpsel.de/wordpress-23-problem-ohne-www-bei-strato-65/
Description: Setzt den wahren HTTP_HOST aus dem Request. Bei Strato wird immer www davor geschrieben.
Author: Ingo Henze
Version: 0.10
Author URI: http://putzlowitsch.de/
*/ 
$plw123thh = parse_url( $_SERVER['SCRIPT_URI'] );
if( isset( $plw123thh['host'] ) && ($plw123thh['host']!=$_SERVER['HTTP_HOST']) )
  $_SERVER['HTTP_HOST'] = $plw123thh['host'];
?>

Mann kann den Quelltext hier einfach rauskopieren, in einer Datei speichern,auf den Server in das Pluginverzeichnis kopieren und aktivieren. Oder man nimmt das fertige Plugin als ZIP-Datei.

Download: 123 True HTTP Host 0.10

Im Übrigen tritt das Problem mit der Weiterleitungs-Endlosschleife bei einer Konfiguration mit www nicht auf, allerdings funktioniert dann das redirect_canonical auch nicht, weil die Seiten ja scheinbar immer korrekt mit www aufgerufen werde.

116 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 »

WordPress ab 2.1 – Optionen für die Startseite

Wordpress Einstellungen Lesen Startseite
Ab WordPress Version 2.1 gibt es die Möglichkeit, als Startseite eine statische Seite anstelle der normalen Blogbeiträge festzulegen.
Dafür gibt es unter ‚Einstellungen‘->’Lesen‘ die Optionen für ‚Startseite‘:

(  ) Deine letzten Beitäge
(•) Eine statische Seite (unten auswählen)
        • Startseite: [Start      [▼]]
        • Beitragsseite: [Blog      [▼]]

Das ist weitestgehend selbsterklärend. Mit ‚Eine statische Seite‘ aktiviert man die statische Startseite, obwohl die durchaus auch eine gewisse Dynamik haben kann, wie ich das hier beschrieben habe. Bei ‚Startseite‘ wählt man, ja genau, die künftige Startseite aus den bisher erstellten statischen Seiten aus.

Nun möchte man aber bestimmt den Lesern auch die Blogbeiträge in der gewohnten Form präsentieren, und nicht nur auf das Archiv, den Kalender oder die Kategorien verweisen. Genau hier kommt die zweite Auswahlmöglichkeit ‚Beitragsseite‘ ins Spiel. Am besten man erstellt sich eine weitere Seite und gibt ihr z.B. den Titel „Blog“. Diese kann man nun für ‚Beitragsseite‘ auswählen und fortan wird das Blog wie sonst auf der Startseite auf eben dieser Seite angezeigt, inklusive der Möglichkeit, seitenweise vor- und zurückzublättern.

Ja, feine Sache würde ich sagen, an der Stelle mal ein Lob an die WP-Entwickler. Bin schon auf die Version 2.3 gespannt…

Weitere Artikel mit Bezug zu diesem:
9 Kommentare »