Das Exec-PHP Plugin führt <?php ?> Code in deinen Beiträgen, Seiten und Text-Widgets aus.
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.
<?php ?> Tags nach dem Speichern des Artikels?eval() Fehler fehl, wenn es meinen Code ausführt?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.
<?php ?> Code in der Kurzfassung und den Texten deiner Beiträge und Seiten aus<?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.
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.
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.
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.
Das RunPHP Plugin von James Van Lommel erzeugt Parse-Fehler mit den meisten der unten stehenden Tests.
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.
Das EzStatic 3 Plugin von Owen Winkler scheitert an Test #16 (siehe unten).
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.
Du brauchst die folgende Software auf deinem Webserver um das Exec-PHP Plugin benutzen zu können:
Falls du jemals ein WordPress Plugin installiert hast, wird die Installation ziemlich einfach für dich sein:
exec-php Verzeichnis nach /wp-content/plugins/Fertig. Der Rest ist selbsterklärend. ;-)
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.
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.
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.
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.
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.
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:
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>.htmlexec-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>.moexec-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.
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.
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.
Wenn die Blog- oder Benutzereinstellungen nicht korrekt sind, um PHP Code zu schreiben, so wird eine Warnung im 'Schreiben' oder 'Widgets' Menu angezeigt.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
Zur Zeit sind keine Inkompatibilitäten mit anderen Plugins oder Themes bekannt.
Neben den vorher erwähnten Limitierungen durch den WYSIWYG Editor, sind keine weiteren Probleme bekannt.
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.
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 | | |
| 2 | | 1"; ?> |
| 3 | | 1'; ?> |
| 4 | | 2"; ?> |
| 5 | | 2'; ?> |
| 6 | | |
| 7 | | 3";?> |
| 8 | | 3';?> |
| 9 | | 4";?> |
| 10 | | 4';?> |
| 11 | | 1";?> |
| 12 | | 1';?> |
| 13 | | 2";?> |
| 14 | | 3';?> |
| 15 | |
|
| 16 | |
Handle THIS! Handle THAT! |
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.
<?php ?> Tags nach dem Speichern des Artikels?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.
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 <, > in > und & in &. Du kannst diese Konvertierung auch automatisiert mittels des WP-Simplecode Plugin durchführen.
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.
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.
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.
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;
?>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.
[?php ?] and < ?php ?>, da regex fehlerhaft und zu aufwändig zu supporten war[?php ?]<?php ?> Code in deinen Beiträgen ausZu diesem Zeitpunkt sind keine weiteren Features geplant. Du kannst aber gerne per Kommentar nach neuen Features fragen.