Das Putzlowitsch Test- und SEO-Blog

Hinweis für WordPress-Plugin-Programmierer

Das einfachste Plugin für WordPress besteht nur aus einer PHP-Datei, da gibt es auch keine Probleme. Wenn man aber das Plugin modular gestaltet, eventuell noch Grafiken, Stylesheets oder JavaScript-Dateien laden will, fangen die Schwierigkeiten an.

Das Nachladen von PHP-Modulen ist noch relativ einfach, sofern sich die Dateien im selben Verzeichnis wie das Hauptmodul befinden. Da reicht ein einfaches

include( 'modul-2.php');

und man muß sich keine Gedanken über Pfade und Verzeichnisse machen.

Anders ist es bei Grafik-, CSS- oder Javascript-Dateien. Hier wird eine gültige URL benötigt, also muß man das Verzeichnis wissen, in dem sich das Plugin befindet. Und zwar nicht den absoluten Pfad auf dem Server, sondern den Pfad bezogen auf die Webseiten-Adresse. Häufig sieht man dann so etwas:

$css = get_option( 'siteurl' ).'/wp-content/plugins/my-plugin/my-style.css';

Es wird also einfach davon ausgegangen, daß Plugins immer im Verzeichnis ‚wp-content/plugins‘ liegen. Das müssen sie aber nicht, denn in WordPress ist dafür extra die Konstante PLUGINDIR vorgesehen.

Diese wird in der wp-settings.php wie folgt definiert:

if ( !defined('PLUGINDIR') )
	define('PLUGINDIR', 'wp-content/plugins'); // no leading slash, no trailing slash

Das if ( !defined(‚PLUGINDIR‘) ) läßt erahnen, daß es durchaus vorgesehen ist, hier auch vorab ein anderes Verzeichnis zu definieren. Ganau davon mache ich Gebrauch, indem ich ein abweichendes Plugin-Verzeichnis in der wp-config.php definieren. Das ist eine einfache Möglichkeit, sich ein wenig vor Angriffen auf Schwachstellen in Plugins zu schützen. Denn auch die meisten Angreifer gehen davon aus, daß sie Plugins in Verzeichnis ‚wp-content/plugins‘ liegen, sofern sie überhaupt so intelligent sind.

Wenn nun ein Plugin selbst einfach ‚wp-content/plugins‘ anstelle von PLUGINDIR verwendet, sind Schwierigkeiten vorprogrammiert. Deshalb, liebe Plugin-Programmierer, verwendet bitte immer PLUGINDIR, um Pfade zusammenzusetzen. Für das obige Beispiel könnte das etwa so aussehen:

$css = get_option( 'siteurl' ).'/'. PLUGINDIR.'/my-plugin/my-style.css';

Ich verwende z.B. folgende Funktion, damit ich auch unabhängig davon bin, in welchem Unterverzeichnis innerhalb des Pluginverzeichnisses die Dateien liegen:

// ermittelt das Pluginverzeichnis
function plw123_plugin_basedir( $file ) {
	$file = str_replace('\\','/',$file); // Windows Verzeichnistrenner "umkippen"
	$file = preg_replace('|/+|','/', $file); // doppelte Schrägstriche entfernen
	$file = preg_replace('|^.*/' . PLUGINDIR . '/|','',$file); // relativen Pfad zum Plugin-Dir ermitteln
	return '/'.PLUGINDIR."/$file/";
}

...

$pluginPath = plw123_plugin_basedir( dirname(__FILE__) );
$css = get_option( 'siteurl' ).$pluginPath.'my-style.css';
8 Kommentare »

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 »

WordPress 2.3 – Plugins oder my-hacks bei der Installation aktivieren

Bereits seit WordPress 2.1 gibt es ein vermutlich eher unbekanntes Feature, mit dem man bereits bei der Installation eines neuen, nackten WordPress benutzerdefinierte Aktionen ausführen kann. Schlüssel dazu ist eine Datei install.php, welche sich im Verzeichnis wp-content befinden muß. Ist also bei der Installation die Datei wp-content/install.php vorhanden, wird deren Inhalt noch vor den WP-eigenen Installtionsfunktionen geladen und kann damit z.B. die wp_install ersetzen.

Am einfachtesten ist es, sich die gewünschte Funktion aus der Datei wp-admin/include/updrade.php (früher wp-admin/upgrade-functions.php ) zu kopieren, die notwendigen Änderungen vorzunehmen und das dann in wp-content/install.php zu speichern.

Und wofür ist das nun gut?
Ich hatte ja zum Problem WP 2.3 Plugincheck geschrieben, das es bei der Neuinstallation auf Grund des Henne-Ei-Problems normalerweise nicht möglich ist, das Plagin zu aktivieren, ohne mindestens einmal die Pluginseite aufgerufen zu haben und damit bereits die Daten an wordpress.org zu senden. Das ist nun mit so einer benutzerdefinierten install.php möglich.

Download: Benutzerdefinierte install.php (als ZIP)

Diese Datei enthält nichts weiter, als die originale WP-Installationsfunktion, am Ende durch folgende Programmzeilen ergänzt:

// Automatische aktiviere von Plugins oder der my-hacks.php
// Plugins
$active_plugins = get_option( 'active_plugins' );
$active_plugins[] = 'plw123_anon_vchek.php';  // hier den Plugin-Dateiname eintragen
update_option( 'active_plugins', $active_plugins );
// my-hacks.php
// update_option( 'hack_file', 1 );

Das mit der my-hacks.php ist auskommentiert, es soll nur das Prinzip veranschaulichen.

Wie sieht nun also eine WordPress 2.3 Neuinstallation aus:

  • Wie gewohnt alle WordPressdateien auf den Server übertragen (wp-config.php nicht vergessen)
  • zusätzlich das Plugin in das Pluginverzeichnis kopieren
  • zusätzlich die benutzerdefinierte install.php in das Verzeichnis wp-content kopieren
  • WordPressinstallation wie gewohnt starten

Fertig!

Viel Spaß mit dem anonymisierten, neuen WordPress 2.3 :-)

Nachtrag: Hannes hat auch ein Plugin geschrieben, welches zusätzlich noch die Pluginliste entschlackt. Sein Plugin kann man natürlich auch mit der beschriebenen Methode gleich bei der Installation aktivieren. Dazu muß einfach nur der Name geändert werden, also an Stelle von:

$active_plugins[] = 'plw123_anon_vchek.php';  // hier den Plugin-Dateiname eintragen

entsprechend

$active_plugins[] = 'anonymous-plugin-updates.php';  // hier den Plugin-Dateiname eintragen

Und es muß auch in das Pluginverzeichnis kopiert werden, das ist ja klar.

2 Kommentare »

WP 2.3 – Anonym up-to-date bleiben – Plugin

Vorgestern hatte ich meinen Hack gegen die Übertragung einiger Daten (Blog-URL, aktive Plugins) beim neuen WP 2.3 Versionscheck vorgestellt. Nun scheint es aber eine gewisse Unsicherheit bei oder Abneigung gegen die Verwendung der, von WP selbst als veraltete bezeichneten, my-hacks.php zu geben. Deshalb habe ich das Ganze hier noch mal als Plugin verpackt.
Man bedenke aber, das man zum Aktivieren des Plugins im Backend die Plugin-Seite aufrufen muß und dadurch mindestens einmal alle Daten ungefiltert an api.wordpress.org übertragen werden.

Wenn man sein System von einer älteren WordPress-Version updatet, ist das kein Probelm. Dann kann man das Plugin einfach vor dem Update installieren und aktivieren. Bei einer Neuinstalltion müßte man aber, bevor man irgendwas anderes macht, das Plugin direkt in der Datenbank aktivieren, was ein bißchen fummelig ist. Zudem setzt man die Filterung auch außer Kraft, wenn man z.B. mit der Funktion „Deaktivier alle Plugins“ alle Plugins ausschaltet.

NEU: Auch die Pluginversion kann bei einer Neuinstallation verwendet!

Wie auch immer, hier nun das „123 Anonymer Versionscheck“-Plugin.

Download: 123 Anonymer Versionscheck 0.10

Die Funktionsweise entspricht exakt der Hack-Version. Weitere Informationen bitte dort nachlesen.

Weitere Plugins zum Thema

  • Hannes ersetzt in seinem Plugin die Updatefunktion mit einer angepaßten eigenen Version und reduziert dort auch die übertragene Pluginliste auf die notwendigen Daten.
  • Filosofo’s Tinfoil-Hat Plugin bringt gleich ein komplett neues Updatesystem mit, doktert also nicht nur an den Symptomen rum, sondern mach gleich „Nägel mit Köpfen“.

Diese Plugins lassen sich auch mit dieser Methode bereits bei der Neuinstallation aktivieren.

8 Kommentare »