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.9 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

  1. Einleitung
    1. Motivation
    2. Features
    3. Die Arbeitsweise von Exec-PHP
    4. Unterschiede zu ähnlichen Plugins
      1. Sniplets
      2. RunPHP 0.2.2 (Mark Somerville)
      3. RunPHP 2.1.1 (James Van Lommel)
      4. PHP Exec 1.7
      5. EzStatic 3
      6. Andere Plugins
  2. Installation
    1. Anforderungen
    2. Installation des Plugin
    3. Upgrade einer alten Version
    4. Upgrade von Version 2.0 oder niedriger
    5. Upgrade auf Version 4.2 oder höher
    6. Deaktivierung des Plugin
    7. Deinstallation des Plugin
    8. Exec-PHP in deiner Sprache
    9. Exec-PHP übersetzen
  3. Benutzung
    1. Ausführen von PHP Code
    2. Konfiguration
    3. Fehlkonfiguration
    4. Ein erster Test
    5. WordPress’ XHTML Tag-Balancing
    6. Schreiben von PHP Code im WYSIWYG Editor
    7. Zulassen des Schreibens von PHP Code in Artikeln
    8. Zulassen des Ausführens von PHP Code in Artikeln
    9. Zulassen von PHP Code in Text-Widgets
    10. Überblick über Tätigkeiten und ihre benötigte WordPress Konfiguration
    11. Blogsicherheit
    12. Sicherheitsloch
  4. Fehlerbehebung
    1. Inkompatibilitäten mit anderen Plugins oder Themes
    2. Limitierungen
    3. Bugs melden
    4. Tests um die Funktionalität des Plugins sicherzustellen
    5. FAQ – Frequently asked questions
      1. Warum funktioniert Exec-PHP nicht, wie es hier beschrieben wurde?
      2. Warum zerstört mir WordPress meine <?php ?> Tags nach dem Speichern des Artikels?
      3. Warum schlägt das Plugin mit einem eval() Fehler fehl, wenn es meinen Code ausführt?
      4. Wie kann ich einfach nur PHP Code anzeigen, anstatt ihn auszuführen?
      5. Warum erzeugt mein Newsfeed Parse-Fehler?
      6. Warum erzeugt meine includierte Datei Parse-Fehler?
      7. Funktioniert das Plugin in WordPress MU?
      8. Wie wird die Plugin Homepage erstellt?
  5. Vergangenheit, Gegenwart und Zukunft
    1. Neue Versionen
    2. Historie alter Versionen
      1. Version 4.9 (2009-01-07)
      2. Version 4.8 (2008-07-05)
      3. Version 4.7 (2008-05-05)
      4. Version 4.6 (2008-04-06)
      5. Version 4.5 (2008-03-24)
      6. Version 4.4 (2008-01-29)
      7. Version 4.3 (2007-12-11)
      8. Version 4.2 (2007-11-03)
      9. Version 4.1 (2007-10-27)
      10. Version 4.0 (2007-10-25)
      11. Version 3.4 (2007-10-08)
      12. Version 3.3 (2007-08-11)
      13. Version 3.2 (2007-02-10)
      14. Version 3.1 (2007-02-09)
      15. Version 3.0 (2006-08-06)
      16. Version 2.0 (2005-12-22)
      17. Version 1.2 (2005-12-04)
      18. Version 1.1 (2005-08-19)
      19. Version 1.0 (2005-08-18)
    3. Roadmap

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:

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 Sicherheitsinformationsabschnitt. 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:

Task Deaktiviere Tag-Balancing Deaktiviere WYSIWYG Editor Weise ‘exec_php’ Befugnis zu Weise ‘unfiltered_html’ Befugnis zu Weise ‘switch_themes’ Befugnis zu
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
global $wp_version;
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_HOME_URL. '/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'. $doc_dir, $content);
$content = preg_replace('/<a\s+href\s*=\s*([\'\"])\s*([^\1p]+\.png\s*\1)/isU',
  '<a href=\1'. $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.9 (2009-01-07)
Version 4.8 (2008-07-05)
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)
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 Konvertierungswarnung 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 Sicherheitsinformationbereichs des Konfigurationsmenus
  • Feature: Anzeige eines Sicherheitsalarms im Sicherheitsinformationsbereich 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

1.041 Kommentare: Zu den Kommentaren

Antworten: Zum Antwortforumlar



Antworten