Eigenes WordPress Plugin erstel­len — objekt­ori­en­tiert mit Klassen

Jeder der schon mal tie­fer in die “tiefs­ten Tiefen” von WordPress geschaut hat, kam even­tu­ell mal auf die Idee, das System zu erwei­tern. Nun gibt es ja end­lich plus ein WordPress Plugin. Aber was, wenn die gewünschte Funktionalität even­tu­ell mal nicht so abge­deckt wird, wie man es viel­leicht gern möchte? Naja … dann gibt’s im Regelfall nur fol­gende Optionen:

• man fragt einen Bekannten, der sich mit PHP und WordPress aus­kennt, ob er einem hilft
• in ein­schlä­gi­gen Foren einen Anfrage stellen
• auf free­lan­cer Foren das Gesuch gegen Bezahlung auf­ge­ben (bäääähh )
• man setzt sich auf sei­nen Hintern und ver­sucht es selbst

Jetzt kann natür­lich jeder selbst ent­schei­den, was er / sie gern selbst machen würde. Wer Option 1 — 3 wählt, kann hier eigent­lich schon auf­hö­ren mit lesen.

Alle ande­ren ange­hen­den WordPress Profis sind herz­lich dazu ein­ge­la­den hier zu erfah­ren, wie man sich selbst ein Plugin schreibt. Und zwar auf die harte Tour: objekt­ori­en­tiert — yeah!

An wen rich­tet sich die­ses Tutorial? Wie  geht’s los?

Dieser Artikel rich­tet sich grund­sätz­lich an Personen, die bereits Kenntnisse im Umgang mit PHP haben und denen das grund­le­gende Konzept der objekt­ori­en­tier­ten Programmierung nicht unbe­kannt ist.

So, was brau­chen wir hier so? Erstmal ein Grundlagenwissen in PHP — logisch. Dann sollte man sich etwas mit dem System WordPress an sich aus­ken­nen. Hier emp­fiehlt es sich mal in den WordPress Codex rein­zu­schauen. In die­sem Codex fin­det man eine ver­hält­nis­mä­ßig gute Dokumentation dar­über, wie man sei­nen Blog erwei­tert oder eben ein WordPress Plugin auf­bauen kann. Dann brau­chen wir noch die Seite von Adam Brown — WordPress hooks data­base. Auf der Seite fin­det man sämt­li­che Hooks von WordPress inkl. Revisionen.

Hook? Captain Hook oder was??

WordPress hat die tol­len Eigenschaft, dass man sich nahezu an jeder Stelle ins System “ein­hän­gen” kann um den Ablauf sei­nen Bedürfnissen anzu­pas­sen. Es gibt zwei Arten von Hooks: Actions und Filter.

Actions

Ein Action Hook ist ein Hook, der sich zu einem bestimm­ten Zeitpunkt ins System ein­klinkt. Dabei kann man dann z.B. eine eigene PHP-Funktion auf­ru­fen. Die rea­gie­ren also auf bestimmte Aktionen des Systems.

Filter

Filter die­nen der haupt­säch­lich der Ände­rung von Texten. Erst nach die­sen Ände­run­gen wer­den sie dann z.B. in der Datenbank gespei­chert, oder angezeigt.

So, das war ein abso­lut mini­ma­ler und ober­fläch­li­cher Exkurs in die Hooks von WordPress. Detailwissen gibt es dann im WordPress Codex. Aber jetzt legen wir mal los. Unser WordPress Plugin soll mal etwas Quelltext bekommen.

Das Grundgerüst — die Klasse

/*
   Plugin Name: Mein erstes WordPress Plugin
   Plugin URI: http://www.guardian-online.de
   Description: Das ist mein allererstes WordPress Plugin
   Author: Benno Mielke
   Author URI: http://www.guardian-online.de
   Version: 0.0.1
*/

if( !class_exists( 'myPlugin' ) ) {
   class myPlugin {

      function __construct() {
         register_activation_hook( __FILE__, array( &$this, 'activate' ) );
         register_deactivation_hook( __FILE__, array( &$this, 'deactivate' ) );
      }

      function activate() {
         // hier setzen wir unsere Hooks, z.B.:
         add_action( 'edit_category_form', array( &$this, 'myHookCategory' ) );
      }

      function deactivate() {
         // hier räumen wir wieder auf, wenn das Plugin deaktiviert wird, z.B.:
         remove_action( 'edit_category_form', array( &$this, 'myHookCategory' ) );
      }

      function myHookCategory() {
         // hier kommt der Quelltext, den wir ins System bringen wollen
         echo '<h3>Mein erster Hook, yay!</h3>';
      }
   }
}

Also eigent­lich sollte der Aufbau bis­her nicht son­der­lich ver­wun­der­lich sein. Jeder der schon mal etwas mit objekt­ori­en­tier­ter Programmierung zu tun hatte, müsste mit dem Klassenprinzip ver­traut sein. Aber fan­gen wir trotz­dem mal oben an …

Der Kommentarblock

Der Kommentarblock ist rela­tiv wich­tig — auch im Aufbau. Hier liest das System die Grundinformationen aus, wel­che spä­ter in der Über­sichts­seite der Plugins erschei­nen. Also über­nehmt die­sen Block so und ändert ein­fach die Informationen.

Die Klasse an sich

… und es beginnt hier mit einer klei­nen “Sicherheitseinrichtung”. Die Zeile

if( !class_exists( 'myPlugin' ) ) { 

prüft, ob unsere Klasse schon mal exis­tiert. Wobei … eigent­lich falsch aus­ge­drückt. Es wird hier geprüft, ob unsere Klasse noch nicht (man achte auf das !) exis­tiert — in dem Fall wird sie “ange­legt”. Es reicht ja, wenn sie ein­mal exis­tiert und nicht 100.000 Mal. Macht ja kei­nen Sinn.

Danach kom­men die OOP-typischen Methoden und Attribute, Funktionen und Variablen, oder wie auch immer Wir haben einen Konstruktur in Zeile 14, eine Art zwei­ten Konstruktur in Zeile 19, mit dem wir unsere Hooks am System anmel­den, einen nicht auf den ers­ten Blick erkenn­ba­ren Destruktor in Zeile 24, mit dem man wie­der auf­räu­men sollte (Hooks deak­ti­vie­ren, Datenbankeinträge ent­fer­nen etc.), und in Zeile 29 haben wir end­lich die erste eigene Plugin-Funktion, die auch tat­säch­lich mal etwas “sinn­vol­les” für uns macht — näm­lich eine Ausgabe in der Kategorie-Ansicht im Backend.

Der Konstruktor

Der Konstruktor dürfte auf den ers­ten Blick etwas selt­sam aus­se­hen. Es sind nur zwei Funktionen vorhanden:

register_activation_hook( ... );
register_deactivation_hook( ... );

Die Funktion register_activation_hook()

Diese Funktion dient dazu, dem WordPress System mit­zu­tei­len, wel­che Methode aus­ge­führt wer­den soll, wenn das WordPress Plugin akti­viert wird. Erst danach kön­nen die eigent­li­chen Hooks grei­fen. In unse­rem Fall rufen wir activate() auf, um unsere Hooks am System anzumelden.

Die Funktion register_deactivation_hook()

Hier haben wir quasi das Gegenteil der Funktion register_activation_hook(). Wird das WordPress Plugin dak­ti­viert, wird die Funktion auf­ge­ru­fen, die als Parameter über­ge­ben wurde. In dem Fall ist das deac­tivate() — unser Pseudo-Destruktor.

So weit so gut. Aber was jetzt?

Jetzt kommt noch ein klei­ner, aber sehr ent­schei­den­der Teil: wir müs­sen unse­ren Konstruktor irgend­wie auf­ru­fen. Denn schließ­lich wol­len wir ja unsere tol­len Funktionen am System anmel­den. Dazu fügen wir am Ende der Datei, direkt hin­ter der schlie­ßen­den Klammer der ers­ten if–Abfrage, fol­gen­den Quelltext ein:

if( class_exists( 'myPlugin' ) ) {
   $myPluginObject = new myPlugin();
}

if( isset( $myPluginObject ) ) {
   add_action( 'init', array( &$myPluginObject, 'activate' ) );
}

Was pas­siert hier noch? Eigentlich auch wie­der nicht viel Aufregendes: wir instan­zi­ie­ren (super tol­les Wort ), erstel­len ein neues Objekt aus unse­rer Klasse. Damit ist ja bekannt­lich der impli­zite Konstruktor-Aufruf ver­bun­den. Somit sind wir am System mit unse­rem WordPress Plugin registriert.

Mit der nächs­ten Zeile set­zen wir einen Hook auf ‘init’. Dieser Hook greift dann, wenn das WordPress System gela­den wird. Tjoa … und dann kön­nen wir unser Plugin schön ver­wen­den und erwei­tern. Das Einzigste was noch zu erle­di­gen ist: die PHP-Datei muss in den Ordner wp-content/plugins

Wer hierzu noch spe­zi­elle Fragen hat, kann sich selbst­ver­ständ­lich bei mir mel­den. In die­sem Sinne wün­sche ich euch happy coding Doods

Update!

Ein Dank gilt Frank, der mich auf eine Kleinigkeit auf­merk­sam gemacht hat: ober­halb des Konstruktors war eine pro­tec­ted Variable namens myOp­ti­ons defi­niert. Diese hat hier nichts ver­lo­ren und wurde ent­fernt