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 »

GROUP BY auf ein Unique Field kann durchaus sinnvoll sein

Kürzlich hatte ich einen Beitrag zu dem Problem mit WordPress und der Sortierreihenfolge bei MySQL 5.0.51 (wie es derzeit bei Strato verwendet wird) geschrieben und mich dort über das vermeintlich unsinnige GROUP BY mit einem eindeutigen Feld (ID) ausgelassen. Für eine einfache SQL-Abfrage, wie dort beim ersten Beispiel, ist das auch durchaus richtig, da ist das „GROUP BY id“ tatsächlich sinnfrei.

Bei WordPress ab Version 2.1 wurde das dann auch geändert, hier wird dieses GROUP BY mit der ID nur noch dann eingefügt, wenn es tatsächlich benötigt wird, nämlich wenn man die Abfrage auf bestimmte Kategorien oder Tags einschränken will. Das könnte z.B. etwa so aussehen:

<?php  query_posts( $query_string.'&cat=1,2,3' ); ?>

Hier will man zum Beispiel nur Artikel anzeigen, die in Kategorie 1, 2 oder 3 enthalten sind. Wenn nun ein Artikel mehreren Kategorien zugeordnet ist, würde das dazu führen, daß dieser Artikel auch mehrmals in der Liste steht und das will man ja nicht. Genau hier bewirkt das GROUP BY id, daß jeder Artikel nur einmal auftaucht. Man hätte das zwar ebenso mit DISTINCT erreicht, aber WP macht es halt mit GROUP BY. Letztendlich ergibt sich daraus ein Problem, welches aber einer fehlerhaften Implementierung von MySQL 5.0.51 zuzuschreiben ist.

Da ich bei mir nicht mit Kategorien oder Tags in den Abfragen arbeite, war mir das bisher auch nicht klar. Erst ein Beitrag im wordpress.org Forum hat mir die Augen geöffnet (Dank an Otto42 für die erhellenden Worte :-).

Was bedeutet das nun für die Praxis? Ganz klar, das Problem kann nur durch ein Update von MySQL behoben werden, da ist dann der Webhoster in der Pflicht. Nun ist es aber nicht ganz einfach, goße Hoster wie Strato dazu zu bewegen, zumal es MySQL 5.0.53 wohl auch noch nicht gibt.
In der Zwischenzeit kann erstmal mein Plugin helfen, welches das GROUP BY id in ein GROUP BY post_date „verbiegt“. Einen kleinen Nachteil hat das aber. Wenn es zwei oder mehrere Artikel mit auf die Sekunde übereinstimmendem Veröffentlichungszeitpunkt gibt, wird nur einer von diesen dargestellt.

Keine Kommentare »