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 »

Skriptkiddies sind doof

Da wurde irgendwo eine Sicherheitslücke für WordPress veröffentlicht, in diesem Fall für ein Plugin, und schon schlagen hier die Zugriffsversuche auf die betroffenen Dateien ein. Nur sind die Skriptkiddies einfach zu blöd, das auch richtig zu machen. Naja, das ist ja eben eine Eigenschaft dieser Angeber, irgendwas machen aber nichts davon verstehen. Bei WordPress liegen die Plugins in einem Unterverzeichnis plugins unter dem Verzeichnis wp-content, und nicht direkt in der Wurzel. Und diese Alibiaufrufe wie

schnurpsel.de/wordpress-23-anonym-up-to-date-bleiben-59/plugins/BackUp/Archive/Predicate.php

sind ja nun völler Unsinn. Wer hat sich denn nur sowas ausgedacht. Da kann man nur den Kopf schütteln.

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »

Neue WordPressversion 2.3.1

Seit gestern gibt es die neue deutsche Version 2.3.1 für WordPress der 2.3er Reihe. Es ist im wesenlichen ein Bugfix- und Security-Release, als wurden im wesentlichen Fehler beseitigt und Sicherheitslöcher gestopft. Neue Funktionen wird es wohl erst ab Version 2.4 wieder geben. Benutzern von WordPress 2.3 wird geraten, auf die neue Version upzudaten.
Ähmmm, da ich ja kürzlich, nachdem noch so einige stratospezifische und andere Probleme behoben werden mußte, auf Version 2.3 umgestiegen war, betrifft mich das hier ja auch, also dann mal ran und frisch upgedated. Bis gleich *wink*

Nachtrag (11:13 Uhr):
Update hat problemlos funktioniert. Bin also wieder up-to-date

Keine Kommentare »

Update durch Downgrade

Ich hatte hier bis vor kurzem ein Strato „PowerWeb A“-Paket. Nun hat Strato die Pakete erneuert. Außer das sie jetzt einen anderen Namen tragen, haben sich auch die zum gleichen Preis gebotenen Leistungen verbessert. So hat das mit dem alten „PowerWeb A“ vergleichbare Paket „PowerWeb Advanced“ jetzt immerhin 2 Datenbanken, 800MB Webspace, 80GB Traffic und ein paar weitere Zusätze. Vorher waren es nur eine Datenbank, 400MB Webspace und 50GB Traffic.

Besonders wichtig ist das Update aber für das kleinste PowerWeb-Paket, früher „XE“, jetzt „Basic“. Denn im Unterschied zum alten XE-Paket, welches ganz ohne PHP und Datenbank auskommen mußte, gibt es im neuen Einsteigerpaket „PowerWeb Basic“ endlich eine Datenbank und auch PHP. So kann nun auch mit diesem Paket ein richtiges WordPress genutzt werde :-)

So dachte ich mir, feine Sache, dann kann ich ja sicher mein altes „PowerWeb A“ mit ein, zwei Klicks auf das neue „PowerWeb Advanced“ updaten. Als flux im Kundenmenü die „Vertragsbetreuung“ aufgerufen und „Paket upgraden“ ausgewählt. Aber nichts da, ein Upgrade geht nur auf ein teureres Paket, das nächste wäre das „PowerWeb Pro“ für 9,99€, aber das will ich nicht. Dann gibt es ja noch bei „Ihr Vertrag“ den Menüpunkt „Paketwechsel (Downgrade)“, aber das wird es ja woöh nicht sein. Ich will ja nicht ein kleineres Paket, sondern nur ein bißchen mehr Leistung zum selben Preis. Naja, halt ein Update.

Ja wie nun, geht das etwa gar nicht? Auch im WP-Forum gab es bereits eine kleine Diskussion dazu. Und siehe da, es geht doch über ein „Downgrade“. Und auch nicht mit ein paar Klicks, sondern nur per Fax mit Unterschrift. Na egal, hab ich also das Fax hingeschickt, am nächsten Tag kam die Bestätigung und noch einen Tag später war die Umstellung erledigt.

Man sollte aber beachten, daß eventuell aus Sonderaktionen bestehende Vergünstigungen wegfallen und auch unbedingt vor der Umstellung alle Daten (nebst Datenbank) zu sichern sind (ein entsprechender Hinweis steht auch auf dem Fax-Formular). Und die Vertragslaufzeit beginnt dann für das neue Paket neu zu laufen.

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 »