Lerne ein WordPress Plugin zu entwickeln

In diesem Beitrag lernst Du Schritt für Schritt, wie Du ein WordPress Plugin selbst erstellen kannst. Dazu werden wir hier gemeinsam einen URL-Shortener für WordPress programmieren. Sagen wir, Du möchtest beispielsweise in Twitter auf die URL http://drwp.de/snippet/erweitere-die-body_class-funktion-um-browser-und-betriebssystem-spezifische-klassen/ verweisen. Services wie Bitly ermöglichen es Dir, dies platzsparend zu bewerkstelligen, indem sie diese URL in eine kürzere umwandeln. Mit unserem Plugin wollen wir Autoren eines WordPress Blogs die gleiche Möglichkeit bieten.

Die Ansicht unseres Plugins im Admin

Natürlich kann Dir dieses Tutorial nur einen kurzen Einstieg in die Entwicklung mit WordPress bieten. Auch die besprochenen Funktionen können nur sehr oberflächlich abgehandelt werden. Wenn Du tiefer in das System einsteigen möchtest bietet sich das Buch „WordPress für Entwickler“ an, welches Dich schnell durch die wesentlichen Bereiche des Systems leitet und mit zahlreichen Beispielen die Funktionen illustriert.

Doch für unser kleines Plugin werden wir nun Schritt für Schritt vorgehen. Im ersten Teil dieses Beitrags lernst Du, wo man die Dateien für ein Plugin ablegt, wie man dafür sorgt, dass WordPress das Plugin erkennt und was es mit den sogenannten Action- und Filterhooks auf sich hat.

Derartig gerüstet werden wir uns dann an die Entwicklung unseres Plugins machen und die dafür notwendigen Funktionen und Hooks kennenlernen. Wir werden lernen, wie man einen neuen Post Type anlegt, wie man Metaboxen in den Posteditor einfügen kann, mit benutzerdefinierten Feldern arbeitet und schließlich einen Redirect einsetzt.

Grundlagen der Plugin Entwicklung

Wahrscheinlich hast Du schon einmal per FTP ein Plugin auf Deine Seite hochgeladen und weißt, wo sich Plugins befinden. In der WordPress Standard-Einstellung ist dies das Verzeichnis wp-content/plugins/. Meistens verfügt dort jedes Plugin über ein Unterverzeichnis, in welchem es sich dann befindet. Notwendig ist das allerdings nicht. Sehr kleine Plugins, welche in einer einzigen Datei Platz finden, können auch einfach im plugins/-Verzeichnis selbst abgelegt werden. Am Ende ist das wohl Geschmackssache. Ich ziehe es vor, meine Plugins in einem Unterordner abzulegen. Das wirkt aufgeräumter und ich habe schneller eine Übersicht, wo sich welche Dateien befinden.

Der Pluginkopf

Jedes Plugin hat eine zentrale Datei, die sogenannte Root-Datei. Diese zeichnet sich dadurch aus, dass sie über einen bestimmten Dateikopf verfügt, der es WordPress ermöglicht, das Plugin als solches zu erkennen und im WordPress Admin darzustellen. Wie sieht ein solcher Pluginkopf nun aus? Beginnen wir am Besten einfach mit unserem Plugin und gestalten diesen Pluginkopf, welchen wir dann in der Datei wp-content/plugins/shorturl/shorturl.php abspeichern:

In dem Kommentar findet man nun verschiedene Angaben zu dem Plugin. Dazu gehört der Name das Plugins (Plugin Name) und die Version (Version), eine URL unter dem man weitere Informationen über das Plugin findet (Plugin URI), den Namen des Autoren (Author), sowie die Webseite des Autoren (Author URI) und eine Beschreibung des Plugins (Description).

WordPress zeigt die Informationen zu Plugins an

Mit Hilfe dieser Angaben kann WordPress nun die Plugin Ansicht im Admin erstellen. Wie man in dem Screenshot sieht hat man tatsächlich alle Angaben übersichtlich geordnet auf der Plugins-Seite von WordPress dargestellt.

In das System einhaken

Doch gehen wir nun an die eigentliche Arbeit und öffnen die Motorhaube des Systems. Wie binden wir nun unsere verschiedenen Funktionen in WordPress ein? Mit jedem Seitenaufruf durchläuft unser Content Management System verschiedene Etappen. So werden beispielsweise die Daten gesammelt, es wird entschieden, welche Ansicht der Webseite geladen wird, es wird der HTML-Kopf ausgegeben, der Titel, Sidebars, der Footer und so weiter. An den vielen unterschiedlichen Stationen werden sogenannte Aktionen aufgerufen. So gibt es beispielsweise die Aktion 'init', welche ausgeführt wird, nachdem das WordPress System komplett initialisiert ist, jedoch noch bevor irgendein HTTP-Header an den Client verschickt wird. Genau in diese Aktionen können wir uns als Pluginentwickler einhaken und unseren eigenen Code an bestimmten Stellen der Systemausführung einbinden. So werden wir später beispielsweise in der Aktion 'init' unseren URL-Post Type registrieren.

Um sich in eine Aktion einzubinden verwendet man den Befehl add_action(), wobei mindestens zwei Parameter erwartet werden: Die Aktion, an welche man sich bindet und eine Callback-Funktion, welche ausgeführt werden soll. Da sich eventuell mehrere Funktionen in dieselbe Aktion einhaken, kann man mit Hilfe eines dritten Parameters bestimmen, ob man weiter vorne oder weiter hinten in der Schlange eingeordnet sein möchte. Dieser Parameter wird Priorität genannt. Die Standard-Priorität liegt dabei bei 10 und je höher der Integer ist, desto weiter hinten in die Schlange reiht man sich ein. Ein vierter, ebenfalls optionaler, Parameter ermöglicht es uns anzugeben, wie viele Parameter unsere Callback-Funktion erwartet. Manche Aktionen übergeben an die Callback-Funktion Parameter, welche weitere Informationen über die gerade laufende Aktion enthalten. Die Anzahl der maximal übergebenen Parameter variiert dabei von Aktion zu Aktion und hier kann man WordPress mitteilen, wie viele man selbst maximal entgegennimmt. Der Standard-Wert liegt hierbei bei eins. Doch sehen wir uns am Besten einfach eine solche Aktion einmal näher an:

Wir haken uns also mit der Callback-Funktion us_init() in die Aktion 'init' ein und führen nun in dieser Funktion unseren Code aus, welchen wir nachher noch näher erläutern werden. Damit haben wir eigentlich schon das gesamte Rüstzeug, um uns in die Entwicklung unseres URL-Shorteners zu stürzen. Doch zuvor möchte ich noch darauf hinweisen, dass es auch Filter gibt. Diese werden wir in unserem Plugin nicht nutzen, sind aber sehr interessant. Mit Filtern können Plugins auf die Ausgabe von bestimmten Daten Einfluss nehmen. Ein bekannter Filter ist dabei 'the_content'. Filter funktionieren dabei ganz ähnlich wie Aktionen, übergeben aber immer mindestens einen Parameter, nämlich den zu filternden Content, welcher auch zurückerwartet wird. Die entsprechende Funktion, um einen Filter zu nutzen ist dabei add_filter( $filtername, $callback, $priority, $args ).

Doch schmeißen wir uns nun einfach in die Schlacht um unseren URL-Shortener.

Entwicklung unseres URL-Shorteners

Wir möchten dem Administrator einer WordPress Seite die Möglichkeit geben, URLs zu kürzen oder zumindest zu maskieren. Dazu soll auf der linken Seite ein Navigationspunkt „Kurz-URLs“ erscheinen, wo alle URLs aufgelistet sind. Ganz ähnlich wie auch bei Beiträgen soll er dann neue anlegen können. Auf der URL-Bearbeiten-Seite soll er einmal einen Titel anlegen können, die Kurz-URL definieren, sowie in einem Feld die eigentliche URL angeben. Das Ganze werden wir erreichen, indem wir einen neuen Post Type anlegen. Sie wissen ja, es gibt Beiträge und Seiten. Dies sind unterschiedliche Post Types. Wir werden nun mit „Kurz-URLs“ einen weiteren solchen Post Type zur Verfügung stellen. Den entsprechenden Code dafür haben Sie schon kennengelernt:

Einen neuen Post Type registrieren

Um einen neuen Post Type zu registrieren, müssen wir uns in die Aktion 'init' einhaken. In unserer Callback-Funktion melden wir diesen neuen Typen nun an, indem wir auf register_post_type()zurückgreifen. Diese Funktion erwartet zwei Parameter, zum einen einen eindeutigen Bezeichner. Für Beiträge ist dieser Bezeichner „post“ und für Seiten „page“. Wir wählen den Bezeichner „url“ für unseren Post Typen. Der zweite Parameter besteht aus einem umfangreichen Argumenten-Array, mit welchem man den Post Typen näher bestimmen kann. Hier kann man mehr als zwanzig Einstellungen vornehmen. Wir begnügen uns allerdings damit, nur vier Einstellungen zu definieren und ansonsten die Standard-Einstellungen zu belassen. Auf der entsprechenden Seite im Codex finden sich die weiteren Möglichkeiten, welche Du hast.

Was für Einstellungen nehmen wir also vor?

• label:
  Das label bezeichnet den Klarnamen unseres Post Typen, welcher beispielsweise auch links in der Admin-Navigation angezeigt wird.
• public:
  Hiermit machen wir klar, dass dieser Post Type öffentlich einsehbar ist. Dies bedeutet zum einen, dass im WordPress Admin ein Menüpunkt für diesen Post Typen erstellt wird und zum anderen, dass man diesen Typen über das Frontend aufrufen kann. Dazu verwenden wir den Boolean true.
• supports:
  Hier legen wir fest, dass dieser Typ über einen Titel verfügen soll ('title'). Mit 'editor' würde der Texteditor eingeblendet, mit 'thumbnail' würde das Einfügen eines Beitragsbildes unterstützt und so weiter. Wenn Du mehr als eines dieser Elemente unterstützen möchtest, kannst Du diese als Array hinterlegen. Ein Beispiel: array( 'title', 'editor' ) unterstützt nun sowohl einen Titel als auch den Beitragseditor.
• 'rewrite':
  Mit diesem Parameter legen wir fest, wie die URL-Struktur zu diesem Post Typen aussieht. Würden wir hier keine Einstellung vornehmen, so würde die Struktur über den Post Typen Bezeichner generiert. Die URL-Struktur wäre demnach beispielsweise http://example.com/url/hallo-welt/. Wir wollen unsere Kurz-URL allerdings über http://example.com/e/hallo-welt/ erreichen. Dazu ändern wir den Rewrite-Slug entsprechend.

Und schon ist unser Post Typ fertig definiert und erscheint als Menüpunkt links im Admin. Wenn Du nun eine neue Kurz-URL erstellst, wirst Du folgendes Interface antreffen:

Die bisherige Kurz-URL Ansicht im Admin

Du kannst lediglich den Titel angeben und rechts das Ganze Speichern und Veröffentlichen. Du siehst unter dem Titel den Permalink zum Beitrag? Genau das wird am Ende unsere maskierte URL sein. Mit einem Klick auf „Bearbeiten“ kannst Du diesen Link nun bearbeiten. Veröffentliche die Kurz-URL doch einmal spaßeshalber und klicke auf Ansicht. Derzeit wird dieser Post Type noch so dargestellt, als wäre er ein Blogbeitrag. Du könntest in Deinem Theme nun auch eine single-url.php anlegen und die Ansicht abändern. Schaue Dir dazu einfach mal ein wenig den Code aus der single.php ab. Das ist allerdings nicht unser Thema, da wir hier ein Plugin schreiben möchten.

Kehren wir deshalb zurück. Was fehlt uns nun noch? Irgendwo muss die URL hinterlegt werden können, auf welche der Besucher schließlich umgeleitet werden soll.

Eine Metabox einfügen

Um dies zu erreichen werden wir nun eine sogenannte Metabox einfügen. Diese wird unterhalb der Titel-Leiste angezeigt werden und ein Input-Feld enthalten, in welche der Administrator dann die URL einträgt, auf welche der Besucher weitergeleitet wird.

Solche Metaboxen können in der Aktion 'add_meta_boxes' hinzugefügt werden. Der Code sähe demnach folgendermaßen aus:

In unserer Callback-Funktion verwenden wir add_meta_box(). Diese Funktion erwartet eine ID, einen Titel, eine Renderfunktion und den Posttypen, für den sie angezeigt werden soll, wobei dieser optional ist. Als ID übergeben wir 'us_url'. Als Titel einfach „Kurz-URL“ und als Renderfunktion haben wir die Funktion us_meta_box_url_render() angegeben, welche wir später noch erstellen werden. Außerdem erklären wir WordPress, dass wir diese Box nur auf den Seiten des Post Typs 'url' anzeigen möchten.

Damit haben wir eine Metabox registriert und müssen uns nun daran machen, diese auch zu rendern. Dafür haben wir die Funktion us_meta_box_url_render() bestimmt:

Die Renderfunktion muss im Wesentlichen einfach den HTML-Code ausgeben, welcher in der Box erscheinen soll, also eigentlich nur unser Input-Feld für die URL. Wir machen es uns allerdings nicht ganz so einfach. Zunächst fügen wir ein verstecktes Eingabefeld ein, welches einen Sicherheitscode enthält. Mit Hilfe dieses Codes stellen wir sicher, dass die Abfrage tatsächlich aus dem Admin heraus erfolgt. Dazu nutzen wir das sogenannte Nonces-Konzept von WordPress. Das versteckte Feld wird dabei über die Funktion wp_nonce_field() erzeugt. Ein Nonce besteht aus einer wirren, nur zeitlich begrenzt gültigen Zeichenfolge, welche einer bestimmten Aktion zugeordnet ist. Den Namen dieser Aktion können wir frei wählen und müssen diese als ersten Parameter übergeben. Im zweiten Parameter legen wir dann den Namen des Input-Feldes selbst fest. Wenn es später an das Speichern der URL geht werden wir diese Zeichenfolge schließlich validieren müssen. Belassen wir es hier für den Moment dabei zu sagen, wir tun dies, um die Sicherheit unserer Applikation zu erhöhen.

Danach geben wir nun aber tatsächlich einfach das HTML aus mit unserem Eingabefeld. Einzig interessant ist hierbei, wie wir den Wert des Input-Feldes ausgeben. Die Adresse der Webseite wird als eine sogenannte Metainformation abgespeichert. Man kann einzelne Posts mit diesen Metadaten anreichern. Um an die jeweilige Information zu einem bestimmten Post zu kommen verwendet man dabei get_post_meta(). An diese Funktion muss die ID des Posts übergeben werden, sowie der Schlüssel hinter welchem sich die Information verbirgt. Als dritten Parameter übergeben wir true. Wenn sich hinter diesem Schlüssel sowieso nur eine Information verbirgt (es können auch mehrere sein), so wollen wir schlicht nur diese eine zurückerhalten. Der Parameter wird „Single“ genannt. Wenn wir mehrere Informationen hinterlegt haben, so würden wir, setzten wir den Parameter auf false (was der Standard ist), einen Array mit sämtlichen Informationen erhalten. Verwende einfach true, es gibt nur sehr wenige Anwendungsfälle, in welchen Du mehrere Informationen hinter dem gleichen Schüssel versammeln willst.

Wie auch immer, wir werden später also die URL als Metainformation ausgeben und erhalten diese mit get_post_meta(). Woher haben wir eigentlich die Post ID genommen? Wenn Du in den Code schaust, siehst Du, dass an unsere Renderfunktion ein Post-Objekt übergeben wird. Mit $post->ID erhalten wir dabei die ID des Posts.

So ganz haben wir aber noch nicht alles geklärt. Schauen wir uns noch einmal schnell die entsprechende Zeile an:
<?php echo esc_attr( urldecode( get_post_meta( $post->ID, 'url', true ) ) ); ?>

Wir verstehen get_post_meta() und $post->ID, doch was macht eigentlich esc_attr() genau? Diese Funktion enkodiert die Zeichen <, >, &, “ und ‚. Man benutzt diese Funktion beispielsweise, wenn man unbekannte Texte in HTML-Attributen ausgibt, da insbesondere die Anführungszeichen schnell dazu führen, dass das Attribut sonst ungültig wird. Nun wird man zwar in URLs selten Anführungszeichen finden, aber man weiß ja nie, was so alles in dieser Zeile eingegeben wird. Die Funktion urldecode() nutzen wir, da wir später während des Speicherprozesses die URL mit Hilfe von urlencode() ein wenig bearbeiten müssen.

Mit diesen simplen Schritten haben wir nun also unsere Metabox registriert und unterhalb der Titelzeile in unserem Post Type dargestellt. Doch, unser Input-Feld, welches die Metainformation enthält, funktioniert noch nicht, beziehungsweise, wenn Du auf „Speichern“ klickst, so wird der Inhalt dieses Feldes leider noch nicht abgespeichert. Ein letzter Schritt ist deshalb notwendig, damit wir alle notwendigen Daten für unser Plugin sammeln können.

Metainformationen speichern

Jedes Mal, wenn Du auf Speichern oder Veröffentlichen klickst wird die Aktion 'save_post' aufgerufen. Genau in diese werden wir uns einhaken, um die URL aus unserem Input-Feld als Metainformation unserem Post anzuhängen. Dazu erstellen wir die Callback-Funktion us_save_post(), an welche die aktuelle Post ID übergeben wird:

Du siehst zunächst einmal eine relativ große IF-Bedingung, denn wir möchten zunächst prüfen, ob wir auch tatsächlich eine Metainformation abspeichern wollen. Du erinnerst Dich noch an das Nonce-Konzept? Wie versprochen werden wir zunächst einmal prüfen, ob die Zeichenkette übergeben wurde und danach, ob diese Kette auch korrekt ist. Zur Prüfung übergeben wir die Zeichenkette und den Namen der Aktion (welchen wir ja zuvor schon bei der Erstellung des Nonces angegeben hatten) an die Funktion wp_verify_nonce(). Sollte die Zeichenkette korrekt sein, wird die Funktion true zurückgeben, andernfalls false. Danach prüfen wir, ob die URL überhaupt über $_POST mit übergeben wird und mit current_user_can() prüfen wir, ob der aktuelle Benutzer das Recht hat den bestimmten Post zu editieren. Schließlich verhindern wir mit Hilfe von wp_is_post_revision() noch, dass wir unnötigen Datenmüll anhäufen, indem wir auch Revisionen des Posts die URL als Metainformation anhängen. In dieser großen IF-Bedingung prüfen wir also, ob wir die Metainformation abspeichern möchten und wenn nicht beenden wir schlicht die Ausführung unserer Callback-Funktion.

Bevor wir uns nun an das Speichern der URL machen zerlegen wir diese zunächst in ihre Einzelteile, um diese gegebenenfalls zu reinigen. Vielleicht möchte der Administrator ja auf http://google.de/search?q=“WordPress für Entwickler“ verlinken. In diesem Fall müssten wir die Anführungsstriche URL-konform in %22 umwandeln und die Leerzeichen in %20.

Doch wie speichern wir jetzt eigentlich tatsächlich unsere URL? Dies können wir mit Hilfe von update_post_meta() erledigen. Die URL für den Post speichern wir hier unter dem entsprechenden Schlüssel 'url'. Wie oben schon erwähnt können wir mit Hilfe von get_post_meta() nun auf diese Information zurückgreifen. Und schon sind alle notwendigen Daten abgespeichert.

Einen Redirect anlegen

Damit sind wir jetzt eigentlich soweit, die Funktionalität unseres Plugins abzuschließen. Das einzige, was uns nun noch fehlt ist unser Redirect. Wenn also ein Besucher unsere Kurz-URL aufruft, so möchten wir ihn auf die im benutzerdefinierten Feld 'url' hinterlegte URL weiterleiten. Wenn wir derzeit auf die entsprechende URL kommen, so sehen wir bisher den Titel des Posts, ganz so als handele es sich um einen Blogbeitrag. Wie und wo richten wir also unseren Redirect ein?

Bei der Einrichtung des neuen Post Types hatte ich Dich schon darauf aufmerksam gemacht, dass Du in Deinem Theme auch ein neues Template mit dem Dateinamen single-url.php anlegen könntest und in diesem die Beiträge vom Typ „url“ gesondert gestalten könntest. Das heißt dass WordPress mit jedem Seitenaufruf prüft, welches Template gerade gewählt werden sollte. Und – wie könnte es anders sein? –, genau hier wird natürlich auch eine bestimmte Aktion ausgeführt: 'template_redirect'. Diese Aktion wird ausgeführt, bevor das jeweilige Template von WordPress gewählt wird. Bisher sind allerdings noch keine HTTP-Header verschickt, so dass wir hier einen Redirect einsetzen könnten und die Ausführung des WordPress Systems einfach abbrechen:

Gehen wir den Code kurz durch. Zunächst prüfen wir mit is_singular( 'url' ), ob wir gerade eine Kurz-URL aufrufen. Wenn der Besucher stattdessen beispielsweise nur eine Beitragsseite aufrufen würde, so gäbe diese Funktion false zurück und wir würden die Ausführung unserer Funktion abbrechen.

Danach holen wir unsere URL mit Hilfe von get_post_meta() die URL, auf welche wir verweisen werden. Die ID des Posts erhalten wir dabei, wenn wir get_the_ID() verwenden. Sollte keine URL hinterlegt sein, so brechen wir die Exekution unserer Funktion ab.

Schließlich nutzen wir wp_redirect(), um den Redirect auf unsere Lang-URL zu erzeugen. Als ersten Parameter übergeben wir dabei die URL und als zweiten den Statuscode 301, mit welchem der Redirect ausgestattet wird.

Schluss

Etwas mehr als einhundert Zeilen Code reichen also in WordPress aus, das System doch um eine relativ eindrucksvolle Funktion zu erweitern: Einen URL-Shortener beziehungsweise URL-Maskierer. Mit diesem kleinen Tutorial ist natürlich nur ein kleiner Bruchteil der Möglichkeiten, welche WordPress Dir bietet, abgedeckt. Wenn Du Blut geleckt hast, solltest Du Dir auf jeden Fall einmal den WordPress Codex näher ansehen. Eine strukturierte und umfassendere Einführung in das Thema der WordPress Programmierung bietet auch das Buch „WordPress für Entwickler„. Auf über 300 Seiten werden dabei die wesentlichen Konzepte der WordPress Programmierung anhand zahlreicher Beispiele umfassend erläutert.

Hier ist noch einmal der komplette Code unseres „URL-Shortener“-Plugins zusammengefasst:

Viel Spaß beim Entwickeln und nicht vergessen: Code is poetry.