Wozu ist dieses Plugin gut?

Das Exec-PHP Plugin führt <?php ?> Code in deinen Beiträgen, Seiten und Text-Widgets aus.

Mach schnell. Wo kann ich das Plugin runterladen?

Download Exec-PHP 4.8 hier!

Warum ist hier soviel Text?

Ich hasse coole Plugins, die schlecht dokumentiert sind. Selbst das kleinste Stück Code benötigt ein wenig Dokumentation. Der folgende Text ist ziemlich ausführlich. Überspringe einfach die Kapitel, die dich nicht interessieren. Wenn du Fragen zum Plugin hast, vergewissere dich, dass du die neuste Version benutzt und die Frage noch nicht auf dieser Seite oder in den Kommentaren der Plugin Homepage beantwortet sind. Dann - und nur dann - stell deine Frage hier.

Inhaltsverzeichnis

Einleitung Installation Benutzung Fehlerbehebung Vergangenheit, Gegenwart und Zukunft

Einleitung

Motivation

Als ich 2005 auf der Suche nach einem PHP Plugin für WordPress war, gab es kein Plugin, dass es mir erlaubte, den Code so zu schreiben, wie ich es gewohnt war. Zum Beispiel verlangten einige Plugins, dass der Code in XHTML Tags wie <phpcode> </phpcode> gekapselt wurde. Das wich von der üblichen Schreibweise für PHP Code ab, bei der einfach nur <?php ?> verwendet wird. Einige Plugins führten den Code erst aus, nachdem WordPress einige Filter wie zum Beispiel ‘texturize’ darauf angewendet hatten. Somit wurde auch der Code mit ‘texturiert’, was die Plugins dann wieder für den Codeteil des Artikels rückgängig machen mussten. Für komplexeren Code kann das auf Grund von Mehrdeutigkeiten nicht korrekt ausgeführt werden, was dann zu Parse-Fehlern führt obwohl der Code syntaktisch korrekt ist.

Features

Die Arbeitsweise von Exec-PHP

Technisch betrachtet, führt Exec-PHP PHP Code in beliebigem Text dadurch aus, dass es den gesamten Text in ?> <?php Tags kapselt und ihn and die PHP Funktion eval() übergibt. Das setzt allerdings voraus, dass der auszuführende PHP Code wiederum innerhalb von <?php ?> Tags gekapselt ist. Durch diese Arbeitsweise muss der Text nicht vom Plugin nach vorhandenen Codestücken geparst werden.

Unterschiede zu ähnlichen Plugins

Es gibt jede Menge andere PHP Plugins, die alle ein wenig anders funktionieren. Die nachfolgende Liste wurde Anfang 2007 erstellt und ist nicht vollständig und vermutlich veraltet, da einige Plugins mittlerweile aktualisiert wurden. Dementsprechend ist neben dem Pluginnamen auch die Versionsnummer angegeben.

Sniplets

Das Sniplets Plugin von John Godley sieht nach der besten Alternative zu Exec-PHP aus. Obwohl es schwerer zu konfigurieren ist, erhältst du dadurch eine höhere Sicherheit auf Grund der Arbeitsweise des Plugins.

RunPHP 0.2.2 (Mark Somerville)

Das RunPHP Plugin von Mark Somerville benutzt XHTML Tag-Syntax um Code innerhalb von HTML auszuzeichnen. Es versucht mittels Konvertierung texturierten Code wieder in seine Ursprungsform zu wandeln und unterstützt nicht die Rollen und Befugnisse von WordPress 2.x.

RunPHP 2.1.1 (James Van Lommel)

Das RunPHP Plugin von James Van Lommel erzeugt Parse-Fehler mit den meisten der unten stehenden Tests.

PHP Exec 1.7

Das PHP Exec Plugin von Priyadi Iman Nurcahyo benutzt XHTML Tag-Syntax um Code innerhalb von HTML auszuzeichnen. Es versucht mittels Konvertierung texturierten Code wieder in seine Ursprungsform zu wandeln.

EzStatic 3

Das EzStatic 3 Plugin von Owen Winkler scheitert an Test #16 (siehe unten).

Andere Plugins

Heutzutage gibt es eine unerschöpfliche Fülle ähnlicher Plugins, die ich nicht mehr alle beschreiben kann. Wenn in Exec-PHP ein Feature fehlen sollte, dann schaue dich einfach mal in einer der WordPress Plugin Datenbanken um oder frag nach, ob ich es implementiere.

Installation

Anforderungen

Du brauchst die folgende Software auf deinem Webserver um das Exec-PHP Plugin benutzen zu können:

Installation des Plugin

Falls du jemals ein WordPress Plugin installiert hast, wird die Installation ziemlich einfach für dich sein:

Fertig. Der Rest ist selbsterklärend. ;-)

Upgrade einer alten Version

Sofern nicht anders angegeben kannst du von einer früheren Version des Plugins upgraden indem du das Plugin deinstallierst und anschließend der Installationsanleitung folgst. Beachte, dass das Upgrade automatisch Einstellungen der älteren Plugin Version migriert. Aus diesem Grund ist ein Downgraden auf die vorherige Version des Plugins nicht möglich.

Upgrade von Version 2.0 oder niedriger

Da sich das Verzeichnislayout geändert hat, musst du die alte Datei exec-php.php aus deinem/wp-content/plugins/ Verzeichnis manuell entfernen. Folge danach der Installationsanweisung. Falls du die alternativen Tags [?php ?] oder das alte PHP-Tagformat < ?php ?> (beachte das Leerzeichen) oder <? ?> benutzt hast, must du sämtliche dieser Tags in das Format <?php ?> migrieren. Du kannst das entweder manuell machen oder du benutzt das Search and Replace Plugin. Seit Exec-PHP Version 3.1 wird eine automatische Migration nicht mehr unterstützt.

Upgrade auf Version 4.2 oder höher

Abhängig von deiner zuvor installierten Exec-PHP Version bekommst du nach der Migration möglicherweise eine Sicherheitswarnung im Admin Menu. Lese diesen Absatz um das Problem zu beheben.

Deaktivierung des Plugin

Die Deaktivierung des Plugins wird höchstwahrscheinlich sämtliche deiner Artikel und Widgets mit PHP Code fehlerhaft anzeigen und wird vermutlich deinen PHP Code im Klartext deinen Lesern zeigen. Aus diesem Grund sollte dein PHP Code keine sensiblen Inhalte wie zum Beispiel Passwörter enthalten.

Deinstallation des Plugin

Um das Plugin zu deinstallieren, lösche einfach das exec-php Verzeichnis aus dem /wp-content/plugins/ Verzeichnis. Du brauchst das Plugin zuvor im WordPress Admin Menu noch nicht mal zu deaktivieren. Lese diesen Absatz falls du wissen willst, was mit deinem PHP Code in diesem Fall passiert.

Exec-PHP in deiner Sprache

Zur Zeit sind die englische und deutsche Übersetzung im Exec-PHP Archiv enthalten. Weitere Übersetzungen für die aktuelle Version sind für folgende Sprachen verfügbar:

Englisch (Default, ist im Exec-PHP Archiv enthalten) Deutsch (ist im Exec-PHP Archiv enthalten) Französisch (Dank an Lise) Italienisch (Dank an Gianni) Russisch (Dank an Dimox) Spanisch (Dank an Diego)

Exec-PHP übersetzen

Falls du Exec-PHP in einer Sprache haben möchtest, die nicht hier enthalten ist, lade das Exec-PHP Archiv herunter und benutze ein Tool wie poedit um die Datei languages/exec-php.pot zu übersetzen. Wenn du ganz fleißig bist, kannst du auch noch die readme.html Datei übersetzen. Falls das zuviel ist, übersetze einfach die readme-generic.html Datei. Speichere die Readme Datei unter dem Namen readme-<locale>.html ab und packe das Ganze dann zu einem Zip Archiv exec-php-<locale>.zip zusammen. <locale> steht hierbei für die Kurzform deiner Sprache. Für die deutsche Übersetzung wäre dies ‘de_DE’. Das entstehende Archiv würde dementsprechend exec-php-de_DE.zip heißen. Das Archiv sollte nicht mehr als die folgenden Dateien enthalten:

exec-php/docs/readme-<locale>.html exec-php/docs/screenshot-1-<locale>.png (optional) exec-php/docs/screenshot-2-<locale>.png (optional) exec-php/docs/screenshot-3-<locale>.png (optional) exec-php/languages/exec-php-<locale>.mo exec-php/languages/exec-php-<locale>.po (optional)

Stelle das Zip Archiv auf deiner Seite zum Download bereit und schreibe danach einen Kommentar auf die Plugin Homepage damit du in den Credits verlinkt wirst.

Sofern du auch noch für ältere Exec-PHP Versionen die Zip Archive zum Download anbieten möchtest, verlinke diese ebenfalls auf deiner Seite unter dem Namen exec-php-<locale>.<version>.zip. Also z.B. exec-php.de_DE.4.2.zip für die deutsche Lokalisierung von Exec-PHP 4.2.

Benutzung

Ausführen von PHP Code

Mit Exec-PHP kannst du PHP Code in der Kurzfassung und dem Text deiner Beiträge und Seiten (im Folgenden Artikel genannt), als auch in Text-Widgets ausführen. Um Code auszuführen, kannst du diesen wie gewohnt, in <?php ?> Tags gekapselt, eintippen.

Um Code in Artikeln oder Text-Widgets auszuführen, musst du eventuell deine Blog- und Benutzereinstellungen ändern. Um Code in Artikeln erfolgreich auszuführen, stelle die folgenden Punkte sicher:

Konfiguration

Das Plugin hat ein eigenes Konfigurationsmenu unter ‘Einstellungen > Exec-PHP’. Das Konfigurationsmenu wird nur für Benutzer angezeigt, die die ‘edit_plugins’ Befugnis haben. Diese ist üblicherweise nur den Administratoren zugewiesen. Wenn du Javascript in deinem Browser abgeschaltet hast oder du Exec-PHP mit WordPress 2.0.x laufen lässt, so wirst du gar keine oder nur Teile des Konfigurationsmenus sehen.

Das Konfigurationsmenu ist in zwei Abschnitte unterteilt, dem Einstellungsabschnitt und dem Informationsabschnitt. Im Einstellungsabschnitt kann das Plugin konfiguriert werden, während im Informatiosabschnitt angezeigt wird, welche Benutzer berechtigt sind, PHP Code auszuführen.

Das Exec-PHP Konfigurationsmenu

Fehlkonfiguration

Wenn die Blog- oder Benutzereinstellungen nicht korrekt sind, um PHP Code zu schreiben, so wird eine Warnung im ‘Schreiben’ oder ‘Widgets’ Menu angezeigt.

Eine Exec-PHP Warnung im 'Schreiben' Menu

Die WYSIWYG Konvertierungswarnung kann im Menu ‘Benutzer > Dein Profil’ abgeschaltet werden. Dies ist allerdings nicht empfohlen, da es dazu führen kann, dass PHP Code in Artikeln beim Speichern dauerhaft zerstört wird.

Exec-PHP Warnungskonfiguration im 'Benutzer > Dein Profile' menu

Wenn du Javascript deaktiviert hast oder du Exec-PHP mit WordPress 2.0.x betreibst, so wirst du keine Warnungen angezeigt bekommen selbst wenn deine Blog- und Benutzereinstellungen nicht für den Betrieb von Exec-PHP geeignet sind.

Ein erster Test

Um sicherzustellen, dass das Plugin richtig funktioniert, melde dich als Administrator an, mache die oben genannten Einstellungen und schreibe einen neuen Artikel mit dem folgenden Text:

<?php echo "Das ist das Exec-PHP 'Hello World'"; ?>

Dieser Code sollte immer funktionieren. Wenn du dir diesen Artikel in deinem Blog anschaust und alles funktioniert, solltest du das hier sehen:

Das ist das Exec-PHP 'Hello World'

WordPress’ XHTML Tag-Balancing

Abhängig von deinem PHP Code ist es möglicherweise notwendig WordPress’ eingebautes XHTML Tag-Balancing abzuschalten sofern der Code in Artikeln ausgeführt werden soll. Die Option kann im Menu ‘Einstellungen > Schreiben’ durch deaktivieren der Option ‘WordPress soll falsch verschachteltes XHTML automatisch korrigieren’ abgeschaltet werden. Im Zweifelsfall deaktiviere diese Option am besten. Anstatt diese Option zu deaktivieren, kann alternativ das Mime Type Plugin installiert werden. In diesem Fall muss für jeden Artikel mit enthaltenem PHP Code der Mime-Typ text/html gesetzt werden.

Schreiben von PHP Code im WYSIWYG Editor

Um erfolgreich PHP Code in Artikel zu schreiben, muss der WYSIWYG Editor im Menu
‘Benutzer > Dein Profil’ abgeschaltet werden. Es reicht nicht, den WYSIWYG
Editor eingeschaltet zu lassen und einfach nur im ‘HTML’ Tab des Editors zu arbeiten. In diesem Fall wird beim Speichern dein PHP Code dauerhaft zerstört.

Anstatt den WYSIWYG Editor in deinem Profil abzuschalten, kannst du ihn auch nur für ausgewählte Artikel mittels des Deactivate Visual Editor Plugins abschalten. Ich habe das zwar nicht getestet, es klingt aber nach einer brauchbaren Lösung.

Wenn du immer noch meinst, PHP Code mit dem TinyMCE WYSIWYG Editor schreiben zu müssen, kannst du einige TinyMCE Plugins ausprobieren, die so etwas ermöglichen sollen. Solche Experimente gehören allerdings nicht mehr in den Wirkungsbereich dieses Plugins. Aus meiner Sicht besteht ein genereller Konflikt, wenn du PHP Code mit irgendeiner Art visuellem Editor schreiben willst, da das gerenderte Aussehen deines Codes für den Editor unvorhersehbar ist. Aus diesem Grund ist es nicht geplant, das Schreiben von PHP Code im WYSIWYG Editor in absehbarer Zeit zu unterstützen.

Zulassen des Schreibens von PHP Code in Artikeln

Bevor PHP Code ausgeführt werden kann, muss der Benutzer diesen erstmal schreiben. ;-) Beim Schreiben und anschließenden Speichern von PHP Code in Artikeln kann es zur Zerstörung des Codes durch WordPress kommen, sofern der Benutzer nicht die ‘unfiltered_html’ Befugnis hat.

Das Zuweisen von Befugnissen zu Rollen oder Benutzern gehört nicht zur Funktionalität dieses Plugins. Da es keine eingebaute WordPress Funktionalität gibt, um Befugnisse zuweisen zu können, benötigst du ein Rollenmanger Plugin wie oben in den Anforderungen beschrieben.

Zulassen des Ausführens von PHP Code in Artikeln

Nach der Installation des Plugins ist das das Ausführen von PHP Code nur der Administrator Rolle gestattet. Durch das Zuweisen der ‘exec_php’ Befugnis zu einer anderen Rolle oder Benutzer wird es diesen erlaubt ebenfalls PHP Code in Artikeln auszuführen zu können.

Das Zuweisen von Befugnissen zu Rollen oder Benutzern gehört nicht zur Funktionalität dieses Plugins. Da es keine eingebaute WordPress Funktionalität gibt, um Befugnisse zuweisen zu können, benötigst du ein Rollenmanger Plugin wie oben in den Anforderungen beschrieben.

Zulassen von PHP Code in Text-Widgets

Nach der Installation ist das Ausführen von PHP Code in Text-Widgets aktiviert. Jeder User, der die ’switch_themes’ Befugnis hat, kann nun PHP Code in Text-Widgets schreiben und ausführen. Da dies eventuell ein Sicherheitsrisiko darstellt, kannst du das Ausführen von PHP Code in Text-Widgets im Konfigurationsmenu des Plugins deaktivieren.

Überblick über Tätigkeiten und ihre benötigte WordPress Konfiguration

Die folgende Tabelle zeigt, welche Einstellungen gesetzt sein müssen damit bestimmte Aktionen mit dem Plugin ausgeführt werden können:

Schreibe/Ändere PHP Code in Text von Artikeln X X   X  
Führe PHP Code in Text von Artikeln aus     X    
Schreibe/Ändere PHP Code in der Kurzfassung von Artikeln       X  
Führe PHP Code in der Kurzfassung von Artikeln aus     X    
Schreibe/Ändere PHP Code in Text-Widgets       X X
Führe PHP Code in Text-Widgets aus         X

Zur Klarstellung: Wenn ein Benutzer einen neuen Artikel schreiben und in diesem PHP Code ausführen will, so benötigt er sowohl die ‘exec_php’ als auch die ‘unfiltered_html’ Befugnis. Andernfalls wird der PHP Code beim Speichern des Artikels zerstört und der nackte PHP Code wird als Artikel angezeigt.

Um PHP Code in der Kurzfassung von Artikeln zu schreiben, benötigt der Benutzer lediglich die ‘unfiltered_html’ Befugnis.

Wenn ein Benutzer PHP Code in Text-Widgets schreiben und ausführen will, so benötigt er lediglich die ‘unfiltered_html’ Befugnis. Es gibt keine Befugnis, die das Ausführen von PHP Code in Text-Widgets beschränkt. Das bedeutet, dass jeder Benutzer, der Widgets schreiben darf (durch die ’switch_themes’ Befugnis beschränkt) auch PHP Code ausführen kann.

Blogsicherheit

Durch die Installation dieses Plugins werden Benutzer in die Lage versetzt, die volle PHP API und WordPress API benutzen zu können. Es gibt keine Limitierungen nur bestimmte Teile der APIs benutzen zu können. Damit entblößt du deine WordPress- und Webserver Installation und ermöglichst es Benutzern die Kontrolle über dein Blog, deinen Server und das ganze Internet zu übernehmen (okay, das letzte war ein Spaß). Wenn du dir nicht sicher bist, erlaube es Benutzern nicht, PHP Code auszuführen. Dies kann leicht pro Benutzer konfiguriert werden.

Sicherheitsloch

Abhängig von deiner Konfiguration, erhältst du möglicherweise einen Sicherheitsalarm, der dich auf den ‘Sicherheitsloch’ Hinweis im Konfigurationsmenu des Plugins hinweist. Dies passiert dann, wenn du Benutzer in deinem Blog hast, denen es erlaubt ist, die Artikel anderer Benutzer zu ändern (üblicherweise Editoren genannt). Sofern es dem Editor selbst nicht gestattet ist PHP Code auszuführen, dem Benutzer des zu editierenden Artikels aber schon, so kann der Editor schadhaften Code in den Artikel des anderen Benutzers einfügen.

Um dieses Problem zu beheben, führt das Exec-PHP Plugin die Befugnis ‘edit_others_php’ ein. Es ist empfohlen, entweder beide oder keine der beiden Befugnisse ‘exec_php’ und ‘edit_others_php’ einem Editor zuzuweisen. Möglicherweise ist es sinnvoll, die Editoren-Rolle in zwei unterschiedliche Editoren-Rollen zu teilen. Eine, der es erlaubt ist PHP Code auszuführen und eine nicht.

Fehlerbehebung

Inkompatibilitäten mit anderen Plugins oder Themes

Zur Zeit sind keine Inkompatibilitäten mit anderen Plugins oder Themes bekannt.

Limitierungen

Neben den vorher erwähnten Limitierungen durch den WYSIWYG Editor, sind keine weiteren Probleme bekannt.

Bugs melden

Du kannst Fehlerreports als Kommentar auf der Plugin Homepage melden. Bevor du das tust, versichere dich, dass dein PHP Script fehlerfrei in einer separaten Datei läuft. Sofern das funktioniert, versichere dich, dass dein Code nicht vom "Globals" Fehler betroffen bist. Wenn du dann immer noch meinst dass es ein Bug im Plugin ist, dann denk beim Schreiben deines Fehlerreports daran, dass WordPress nicht dazu gedacht ist mit Code in Kommentaren umzugehen. Deshalb konvertierst du deinen Code am besten in korrektes XHTML, bevor du ihn als Kommentar auf der Plugin Homepage schreibst. Du kannst gerne auch auf deinen Code verlinken oder mit mir direkt über meine Kontaktseite in Verbindung treten.

Tests um die Funktionalität des Plugins sicherzustellen

Nachfolgend ist eine Liste der Tests, die gemacht wurden um die Funktionalität des Plugins sicherzustellen. Auf der linken Seite ist der PHP Code beschrieben, der im entsprechenden Test ausgeführt wird. Auf der rechten Seite ist die Live-Ausgabe des Exec-PHP Plugins für den Testcode. Sofern du dieses Dokument als statische HTML Datei ansiehst, wird der PHP Code natürlich nicht ausgeführt und sieht entsprechend kaputt aus. Auf Grund der Ausgabe der Tests wird diese Seite nicht als valides XHTML verifizieren. Wenn du denkst, dein Lieblings PHP Plugin ist besser als Exec-PHP, probiere alle nachfolgenden Tests aus und schaue ob es damit korrekt funktioniert.

# Code Ausgabe
1
<?php ?>

2
<?php echo "a?>1"; ?>

a?>1
3
<?php echo 'b?>1'; ?>

b?>1
4
<?php echo "a?>2"; ?>

a?>2
5
<?php echo 'b?>2'; ?>

b?>2
6
<?php?>

7
<?php echo"a?>3";?>

a?>3
8
<?php echo'b?>3';?>

b?>3
9
<?php echo"a?>4";?>

a?>4
10
<?php echo'b?>4';?>

b?>4
11
<?php echo "c";?>1";?>

c1″;?>
12
<?php echo 'd';?>1';?>

d1′;?>
13
<?php echo "c';?>2";?>

c’;?>2
14
<?php echo 'd";?>3';?>

d”;?>3
15
<?php
echo "impressive\n '";
echo 'string\' "';
echo "\n\thandling\"";
?>
impressive
’string’ ”
handling”
16
<?php if (1) { ?>
<b>Handle THIS!</b>
<?php } else { ?>
<i>Handle THAT!</i>
<?php } ?>
Handle THIS!

FAQ - Frequently asked questions

Warum funktioniert Exec-PHP nicht, wie es hier beschrieben wurde?

Wenn das Plugin nicht funktioniert obwohl die Blog- und Benutzereinstellungen richtig konfiguriert sind, dann kollidiert das Exec-PHP Plugin sehr wahrscheinlich mit einem anderen Plugin deines Blogs. Um das Problem einzukreisen, deaktiviere alle anderen Plugins außer Exec-PHP und schaue, ob Exec-PHP nun funktioniert.

Warum zerstört mir WordPress meine <?php ?> Tags nach dem Speichern des Artikels?

RTFM. Lese das hier.

Warum schlägt das Plugin mit einem eval() Fehler fehl, wenn es meinen Code ausführt?

Wenn du PHP Fehlermeldungen in der Art 'Some error in /home/minime/htdocs/blog/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()’d code on line 666' bekommst, dann ist es an der Zeit, deinen PHP Code zu reparieren. Wenn du dir nicht sicher bist, an welcher Stelle dein Code defekt ist, lasse ihn in einer separaten Datei laufen. Entferne alle Fehler und kopiere den Code anschließend wieder in deinen Artikel oder Widget. Um die Menge an Kommentaren auf der Plugin Homepage zu begrenzen, werde ich alle Fehlerreports zu diesem Problem löschen.

Wie kann ich einfach nur PHP Code anzeigen, anstatt ihn auszuführen?

Wenn du lediglich Code in deinem Blog anzeigen willst, anstatt ihn auszuführen (wie es z.B. auf dieser Seite gemacht wird), dann musst du den Code in die korrekte XHTML Schreibweise überführen. Dazu müssen die folgenden Zeichen konvertiert werden: < in &lt;, > in &gt; und & in &amp;. Du kannst diese Konvertierung auch automatisiert mittels des WP-Simplecode Plugin durchführen.

Warum erzeugt mein Newsfeed Parse-Fehler?

Nehmen wir an, dein Code funktioniert außerhalb eines Artikels. Trotzdem wirft der PHP Parser eventuell Fehler in deinem Newsfeed aus, nicht aber beim Betrachten deiner Seite. Das passiert dann, wenn du eigene Funktionen, Klassen usw. in deinem Code definiert hast. Für die Generierung deines Newsfeeds liest WordPress deine Artikel nämlich zweimal (einmal für die Zusammenfassung und einmal für den kompletten Artikel) und führt somit auch deinen Code zweimal aus. Der folgende Code würde zwar beim Betrachten deiner Seite fehlerfrei funktionieren, würde aber dazu führen, dass dein Newsfeed PHP Fehler enthält:

Article:

<?php
function hello()
{
echo 'Hello World';
}
hello();
?>

Als Grundregel kann ich nur empfehlen, alle Definitionen in separate Dateien zu speichern und auf diese mit require_once() zu referenzieren. Das obige Beispiel würde dann in zwei Teile geteilt werden, dem Artikel und die Datei.

Artikel:

<?php
require_once(get_option('home'). '/example.php');
hello();
?>

Datei (hier example.php):

<?php
function hello()
{
echo 'Hello World';
}
?>

Bitte beachte, dass require_once() den vollqualifizierten Pfad benötigt. Das ist notwendig, da der relative Pfad sich abhängig vom Kontext (z.B. Betrachten deiner Blog Homepage, Betrachten des Artikels, Anzeigen des Newsfeeds, usw.), in dem deine Seite dargestellt wird, ändert.

Warum erzeugt meine includierte Datei Parse-Fehler?

Nehmen wir an, dein includierter Code funktioniert außerhalb eines Artikels und der Pfad zur Include-Datei ist korrekt. Trotzdem wirft der PHP Parser eventuell Fehlermeldungen aus, obwohl alles korrekt aussieht. Das passiert dann, wenn der Programmierer der includierten Datei angenommen hat, dass die Datei im globalen Scope ausgeführt wird und nicht das Schlüsselwort global benutzt um globale Variablen zu deklarieren. Als Beispiel schreibe folgenden Artikel:

Artikel:

<?php require_once(get_option('home'). '/example.php'); ?>

Kopiere den folgenden Code in eine neue Datei mit Namen example.php und speichere sie im Wurzelverzeichnis deines Webservers:

Datei (hier example.php):

<?php
$g_text = 'Hello World';
function hello()
{
global $g_text;
echo $g_text;
}
hello();
?>

Obwohl die Datei example.php einwandfrei ausgeführt werden kann, sofern du sie direkt aufrufst, führt dieser Test zu undefinierten verhalten, sofern du den Artikel in WordPress ansiehst, da hier die Zuweisung des Wertes zur Variablen $g_text nicht innerhalb des globalen Scopes stattfand. Das liegt an der Art und Weise wie WordPress funktioniert und kann nicht durch einen Bugfix in Exec-PHP repariert werden. Du kannst diesen Fehler umgehen, indem du den folgenden Code in deinen Artikel vor die include Anweisung einbindest oder die includierte Datei am Anfang um folgenden Code ergänzts:

global $g_text;

Selbstverständlich musst du dass für jede globale Variable machen, bei der dies nicht schon vom Programmierer selbst gemacht wurde. Du kannst natürlich auch versuchen, den Programmierer des Codes zu kontaktieren, damit er seinen Code ändert.

Funktioniert das Plugin in WordPress MU?

WordPress is nicht WordPress MU. Das Plugin ist für WordPress geschrieben aber eventuell funktioniert es ja auch mit WordPress MU. Wenn du einen Patch bereitstellst, um die Kompatibilität mit WordPress MU zu verbessern, werde ich diesen gerne in die nächste Version von Exec-PHP einbauen.

Wie wird die Plugin Homepage erstellt?

Gut das du fragst. Das ist eine gute Gelegenheit, um zu zeigen, welche Möglichkeiten das Exec-PHP Plugin bietet. Die Plugin Homepage ist ein WordPress Beitrag, der im Wesentlichen aus einem PHP Script besteht, dass durch Exec-PHP ausgeführt wird und die in der Exec-PHP Installation enthaltene readme.html liest und parst. Dadurch muss ich bei einer neuen Version des Plugins lediglich die Plugindateien auf den Webserver hochladen. Die Dokumentation wird dann automatisch auf der Plugin Homepage aktualisiert. Der komplette Code sieht wie folgt aus:

<?php
// read readme.html depending on locale; plugin translation not yet loaded
if (version_compare($wp_version, '2.6.dev') >= 0)
load_plugin_textdomain(ExecPhp_PLUGIN_ID,
false, ExecPhp_HOMEDIR. '/languages');
else
load_plugin_textdomain(ExecPhp_PLUGIN_ID,
ExecPhp_PLUGINDIR. '/'. ExecPhp_HOMEDIR. '/languages');

$doc_dir = ExecPhp_PLUGINDIR. '/'. ExecPhp_HOMEDIR. '/docs/';
$doc_filename = ExecPhp_HOME_DIR. '/docs/'. __s('readme.html', ExecPhp_PLUGIN_ID);
$content = file_get_contents($doc_filename);

// strip HTML header
$content = preg_replace('/^.*<!\-\-\s*start of content\s*\-\->/is',
'', $content);

// strip HTML footer depending whether viewing the whole post or only
// the excerpt
$pattern = '/<!\-\-\s*more\s*\-\->.*$/is';
if (is_single())
$pattern = '/<!\-\-\s*end of content\s*\-\->.*$/is';
$content = preg_replace($pattern, '', $content);

// eval readme.html to generate output of test cases
ob_start();
eval(" ?> $content <?php ");
$content = ob_get_contents();
ob_end_clean();

// adjust relative image links
$content = preg_replace('/<img\s+src\s*=\s*([\'\"])/is',
'<img src=\1'. get_option('siteurl'). '/'. $doc_dir, $content);
$content = preg_replace('/<a\s+href\s*=\s*([\'\"])\s*([^\1p]+\.png\s*\1)/isU',
'<a href=\1'. get_option('siteurl'). '/'. $doc_dir. '\2', $content);

// done
echo $content;
?>

Vergangenheit, Gegenwart und Zukunft

Neue Versionen

Neue Versionen des Plugins werden von Zeit zu Zeit veröffentlicht und können neue Features und/oder Bugfixes enthalten. Du kannst dich über die neusten Entwicklungen auf dem Laufenden halten, indem du die Kommentare der Plugin-Homepage abonnierst. Seit WordPress 2.3 wirst du auch im ‘Plugin’ Menu von WordPress über neue Versionen informiert.

Neue Versionen bringen immer Änderungen am Code mit sich und erhöhen die Versionsnummer. Bestehende Versionen können trotzdem noch nach der ursprünglichen Veröffentlichung verändert werden. Dies passiert dann, wenn lediglich die Dokumentation für das Plugin aktualisiert wurde. In diesem Fall gibt es keine Benachrichtigung auf dieser Seite.

Historie alter Versionen

Version 4.8 (2008-07-05)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Download: Italienische Übersetzung Download: Russische Übersetzung Download: Spanische Übersetzung Anforderungen: WordPress 2.0 oder höher Feature: Support für WordPress 2.6 (Umplatzierung von wp-content)
Version 4.7 (2008-05-05)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Download: Italienische Übersetzung Download: Russische Übersetzung Download: Spanische Übersetzung Anforderungen: WordPress 2.0 oder höher Bugfix: Die Cache Instanzen in PHP4 waren keine Referenzen, was zwar ein Fehler war, aber keine bekannten Probleme verursacht hat Bugfix: Javascript funktioniert mit Single Quotes in übersetztem Text Feature: Verbesserte Performance des AJAX Aufrufs Feature: Verbesserte Fremdsprachenunterstützung innerhalb des Plugins und der Readme
Version 4.6 (2008-04-06)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Download: Russische Übersetzung Download: Spanische Übersetzung Anforderungen: WordPress 2.0 oder höher Feature: Im Falle eines AJAX Fehlers wird nun der Aufruf bis zu dreimal wiederholt Bugfix: Das Konfigurationsmenu ist jetzt gültiges XHTML
Version 4.5 (2008-03-24)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Download: Russische Übersetzung Download: Spanische Übersetzung Anforderungen: WordPress 2.0 oder höher Bugfix: Reparatur der Kompatibilität mit WordPress 2.1.x Bugfix: WYSIWYG Konvertierungsfehler wird nun auch für das Schreiben von Seiten angezeigt Änderung: Verbesserte Performance während der Plugin-Initialisierung Änderung: Entfernung von modaler AJAX-Fehlermeldung Feature: Support für WordPress 2.5 GUI
Version 4.4 (2008-01-29)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Download: Russische Übersetzung Anforderungen: WordPress 2.0 oder höher Bugfix: Kompatiblität mit WP-Shopping-Cart Plugin durch Umbenennung schlecht benamter Javascript Variablen Change: Geänderte Verzeichnisstruktur
Version 4.3 (2007-12-11)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Download: Russische Übersetzung Anforderungen: WordPress 2.0 oder höher Bugfix: Anforderungen auf WordPress 2.0 oder höher gesenkt Bugfix: Verzögerung des Ladens der übersetzten Texte für Support von Lokalisierungsplugins Feature: Die WYSIWYG Konvertierungswarnung kann nun im Profil des Benutzers abgeschaltet werden
Version 4.2 (2007-11-03)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Anforderungen: WordPress 2.2 oder höher Change: Redesign des Informationbereichs des Konfigurationsmenus Feature: Anzeige eines Sicherheitsalarms im Informationsbereich des Konfigurationsmenus Feature: Es wird nun eine Warnung im ‘Schreiben’ und ‘Widgets’ Menu ausgegeben, falls die Blog- oder Benutzereinstellungen geschriebenen PHP Code beim Speichern zerstören würden
Version 4.1 (2007-10-27)
Download: Plugin (Englische und deutsche Übersetzung) Download: Französische Übersetzung Anforderungen: WordPress 2.2 oder höher Bugfix: Die Anzeige des Konfigurationsmenus war mit einer falschen Befugnis geschützt Bugfix: Das Konfigurationsmenu ist jetzt gültiges XHTML Feature: Das Konfigurationsmenu zeigt nun an, welche Benutzer PHP Code schreiben und ausführen dürfen. Die Anzeige erfolgt mittels AJAX. Für WordPress Installationen mit vielen Benutzern sollte die Ladezeit der Seite trotzdem befriedigend sein
Version 4.0 (2007-10-25)
Download: Plugin (Englische und deutsche Übersetzung) Anforderungen: WordPress 2.0 oder höher Bugfix: Wenn die ‘exec_php’ Befugnis bei allen Rollen entfernt wird, wird die Befugnis nun automatisch wieder der Administrator Rolle zugewiesen Change: Bei einer Neuinstallationen ist nur noch die Administrator Rolle berechtigt PHP Code auszuführen Feature: Konfigurierbare Ausführung von PHP Code in Text-Widgets im Konfigurationsmenu. Dieses Feature funktioniert nur mit dem in WordPress 2.2 eingeführten Widget Support
Version 3.4 (2007-10-08)
Download: Plugin Anforderungen: WordPress 2.0 oder höher Feature: Support für PHP Code in Text-Widgets Feature: Support von Plugin Upgradebenachrichtigungen im ‘Plugins’ Menu von WordPress durch Eintragen in das offizielle WordPress Plugin Repository
Version 3.3 (2007-08-11)
Download: Plugin Bugfix: Entfernung von Leerzeichen um PHP Code Bugfix: Entfernung ungenutzter Hooks für WordPress 1.x
Version 3.2 (2007-02-10)
Download: Plugin Bugfix: Entfernung ungenutzter Konfigurationsmenu-Hooks
Version 3.1 (2007-02-09)
Download: Plugin Bugfix: Entfernung des Tag-Style Konverters weil er a) das WordPress Admin Menu sehr langsam machte und b) PCRE sich als fehlerhaft und unzuverlässig erwiesen hat. Interner Vermerk: Benutze niemals wieder PCRE! Feature: Lokalisierungssupport Feature: Funktioniert nun auch in Newsfeeds
Version 3.0 (2006-08-06)
Download: Plugin Feature: Entfernung aller alternativen PHP Tag-Styles wie [?php ?] and < ?php ?>, da regex fehlerhaft und zu aufwändig zu supporten war Feature: Entfernung von WordPress 1.x Support, da regex fehlerhaft und zu aufwändig zu supporten war Feature: Neue Verzeichnisstruktur Feature: Hinzugefügter Tag-Style Konverter Feature: Nun auch PHP Code in der Kurzfassung von Artikeln Bugfix: Durch Änderungen an der PHP Tag-Behandlung ist der Bug aus Kommentar 84 gefixt
Version 2.0 (2005-12-22)
Download: Plugin Feature: Für WordPress 2.0 ist die Ausführung von PHP Code nur Administratoren und Editoren erlaubt Feature: Support für alternative PHP Tags [?php ?]
Version 1.2 (2005-12-04)
Download: Plugin Bugfix: Test #16 funktioniert nun
Version 1.1 (2005-08-19)
Download: Plugin Bugfix: Anführungszeichen in Strings werden nun korrekt geparst
Version 1.0 (2005-08-18)
Download: Plugin Feature: Führt <?php ?> Code in deinen Beiträgen aus

Roadmap

Zu diesem Zeitpunkt sind keine weiteren Features geplant. Du kannst aber gerne per Kommentar nach neuen Features fragen.

Für Neugierige: Eine Liste aller Plugins, die dieses Blog am Laufen halten, findest du hier.

Für die Wagemutigen: Eine Liste aller von mir geschriebenen Plugins, findest du hier.

Über diesen Artikel

Author: Sören

Veröffentlicht: 18. August 2005

Kategorie: Bloggen

778 Kommentare: Zu den Kommentaren

Antworten: Zum Antwortforumlar


Thanks Soren for the reply, but I still trying to get it to work

1) I don’t see warning in the write page
2) I have logged in as administrator with User Level 10
3) I’m using the Test PHP code

And still it doesn’t work. I’m not sure where I’m getting it wrong.

I have tried deactivating other plugin, but it wouldn’t work.

Raghu

Kommentar #417

Veröffentlicht: 04. August 2008

Thank you so much. You’ve just made my life so incredibly easier!

Ryan Gannon

Kommentar #418

Veröffentlicht: 04. August 2008

Raghu,

1) Why should there be a warning? If you are doing fine, there shouldn’t.
2) Is the post written by Administrator, too?
3) Please correct the PHP code to valid PHP and see if it saves correctly.

Sören

Kommentar #419

Veröffentlicht: 04. August 2008

Hi - Great Plugin

I am trying to use this plugin to run a script to generate a HTML table in a wordpress page. It works fine, except that the table includes some links to websites. Unfortunately the generated code is then post processed by something that turns converts some special characters:
> becomes &gt
<a href="http://www.winscombe-rugby.co.uk">Winscombe RFC</a>

Can this be prevented, as it stops the link being displayed as a link.
Thanks in advance

maxweld

Kommentar #420

Veröffentlicht: 09. August 2008

Hmm - that post did not work as it also converted some of the characters in the post. Perhaps you could look at the website. Viewing the source of the page will demonstrate the problem.
Thanks

maxweld

Kommentar #421

Veröffentlicht: 09. August 2008

Hi,

I encountered a problem where javascript array syntax are undesirably escaped. For example:

foo[0] = ‘foo’;

will render fine. But

var foo = new Array();
foo[0] = ‘foo’;

turns into foo[0] = ‘foo’;
double quote gives something similar. Is this a known bug? I’m using Wordpress 2.6 + exec php 4.8

Thanks

ChoChoPK

Kommentar #422

Veröffentlicht: 11. August 2008

Uh, I meant “turns into turns into foo[0] = & #8216;foo& #8217;;”

but without the space after &.

ChoChoPK

Kommentar #423

Veröffentlicht: 11. August 2008

Error with php-exec 4.8 Wordpress 2.6.1 (visual editor is NOT switched on) :
“Parse error: syntax error, unexpected T_ECHO in /opt/www/logghel/web/www.lucasnet.be/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()’d code on line 4″

I used the same php-script for 1.5 years now throughout many wordpress versions, and it never gave me an error-code. But with the latest Wordpress-update (2.6.1) I got the error. Could it be an imcompatibilty error?

By the way, thanks for your excellent work on this plugin !!!

LucasX

Kommentar #424

Veröffentlicht: 16. August 2008

Ein kleinerer (aber störender Fehler): bei Einfügen von PHP Code (include) in einer statischen Seite werden ca. 30 Leerzeilen vor dem Code produziert, der Code selbst produziert aber gute Ergebnisse. Wenn ich den selben Content via iframe einlese, habe ich diese Leerzeilen nicht. Alle anderen HTML Formatierungen werden korrekt dargestellt

Tom

Kommentar #425

Veröffentlicht: 19. August 2008

I accidentally removed the ability exec_php from the administrator role using the Role Manager plugin, and no other role has the ability to reinstate it. How can I solve this?

Brendon Patubo

Kommentar #426

Veröffentlicht: 22. August 2008


Antworten



You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser