Top
Wie man ein WordPress Plugin schreibt – RonnyDee´s Blog
fade
2150
post-template-default,single,single-post,postid-2150,single-format-standard,eltd-core-1.1.1,flow child-child-ver-1.0.0,flow-ver-1.3.7,,eltd-smooth-page-transitions,ajax,eltd-blog-installed,page-template-blog-standard,eltd-header-standard,eltd-fixed-on-scroll,eltd-default-mobile-header,eltd-sticky-up-mobile-header,eltd-dropdown-default,wpb-js-composer js-comp-ver-5.2.1,vc_responsive

Wie man ein WordPress Plugin schreibt

Nachdem es auch für mich interessant ist und quasi von Null anfange, übersetzte ich den englischen Artikel “How to write a wordpress plugin” ins deutsche und versuche die wichtigsten Punkte besonders hervorzuheben. Ich hoffe dem einen oder anderen hilft diese Anleitung, denn WordPress kann mit eigenen Plugins sehr gut erweitert werden.

Grundvorraussetzungen dafür sind natürlich ein installiertes WordPress, Kenntnisse in PHP und Zugang auf den Webserver per FTP. Als Editor verwende ich auf dem PC den kostenlosen PHP-Editor Notepad++. Dieser formatiert den Quellcode recht übersichtlich und ist einfach zu bedienen. Aber jetzt mal genug mit dem geschwaffel 🙂

 

Aufbau der Verzeichnisstruktur

WordPress-Plugins können in einer einzigen Datei oder per Verzeichnis (mit verschiedenen Dateien) definiert werden. Empfohlen wird grundsätzlich eine Verzeichnisstruktur, da man so sehr flexibel bleibt und das spätere Warten des Plugins vereinfacht.

Grundsätzlich kann man sich an folgenden Aufbau orientieren:

  • wp-plugin-name/
    • wp-plugin-name.php Die Haupt(start)datei des Plugins
    • readme.txt Eine optionale Datei die erweitere Informationen zum Plugin enthalten kann
    • post-types/ Ein Verzeichnis wenn man mit eigenen Beitragstypen arbeiten möchte
      • custom-post-type.php Die jeweilige Steuerungsdatei für den eigenen Beitragstyp
    • templates/ Ein Verzeichnis für die jeweiligen Darstellungsinformationen (Vorlagen)
      • custom-post-type-inner-metabox.php Jeder eigene Beitragstyp benötigt eine eigene Metabox-Templatedatei, damit man eine saubere Trennung zwischen Standardtypen und benutzerdefinierten Typen gewährleisten kann
    • settings.php Diese Datei enthält dann alle relevanten Einstellungen für das künftige Plugin

 

wp-plugin-name/

Dieses Ordner beinhaltet, nach der oben angeführten Struktur, alle künftigen Plugin-Dateien und soll auch über einen eindeutigen Namen verfügen. Abgelegt wird dieser dann per FTP in den Ordner /wp-content/plugins.

wp-plugin-name.php

Jedes Plugin beginnt mit einer Beschreibung und einigen Informationen über den Autor.

Nach diesen Angaben kann man beginnen die Hauptlogik des Plugins zu definieren. In diesem Fall bevorzugte Francis Yaconiello den Aufbau via Klassen. Im Grunde genommen kann man Plugins jedoch entwicklen wie man möchte, sofern man den jeweiligen WordPress Codex nicht verletzt. In diesem Beispiel wird als erstes eine Klasse namens “WP_Plugin_Template” definiert. Diese Klasse beinhaltet mehrere Methoden. Wagen wir uns einmal an den Aufbau:

Am Ende der Definition müssen wir WordPress noch mitteilen, dass nach dem korrekten Initialisieren dieser Klasse zwei WordPress Hooks (automatische bzw. definierte Abläufe seitens WordPress (Codex)) benötigt und geladen werden sollen und das Plugin verarbeitet werden soll:

Lädt man das Ganze nun bereits per FTP hoch, so kann man im WordPress-Backend im Menü “Installierte Plugins” bereits das Plugin auffinden:

wp_plugin_entwicklung_01

Im Konstrukt müssen wir dem Plugin bzw. WordPress nun mitteilen, wie unsere Struktur aufgebaut ist und was beim Initialisieren geladen werden soll. Deshalb wird in der Datei wp-plugin-name.php die Funktion “public function __construct()” von

auf folgendes erweitert:

 

Eine Einstellungsseite hinzufügen

Der Aufbau der settings.php basiert in diesem Fall wieder auf Klassen:

Damit man mit diesem Plugin auch Einstellungen vornehmen kann, muss man die jeweiligen “Actions” und “Callbacks” in das Plugin bzw. in die settings.php einbinden. Deshalb wird nun innerhalb der Konstruktionsklasse “public function __construct()” folgender Code eingebunden, der den Zugriff via admin_init und add_menu erlaubt:

Dieser Code bewirkt, dass man auf die Funktionen der admin_init und add_menu zugreifen kann. Dies werden wir später noch benötigen. Damit das aber auch wirklich möglich ist, muss dies noch separat initialisiert werden. Dies kann man mit folgendem Code innerhalb der “public function admin_init()” erreichen:

Als nächstes werden einige Einstellungsfelder definiert. Diese befinden sich ebenfalls innerhalb der “public function admin_init()” Klasse. Wichtig ist dabei, dass auch hier eindeutige Namen vergeben werden, da man sonst leicht mit anderen Plugins oder mit dem WordPress Code in Konflikt geraten kann. Eine entsprechende Anleiitung dazu findet sich auf http://codex.wordpress.org/Function_Reference/register_setting

Als nächstes wird das Menü für das Backend definiert. Allerdings wird kein HTML Code in der Plugin Klasse definiert oder ausgegeben, sondern mittels einer eigenen Datei im Template Verzeichnis gesteuert. Damit wir diese aber überhaupt erst ansprechen können, müssen in der Datei settings.php innerhalb der Klasse “class WP_Plugin_Template_Settings” noch eigene Subklassen aufrufen.

Nämlich jene Klassen die das Menü erzeugen und ein Callback auslösen:

Beachte dabei, dass wir uns am Schluss die settings.php Datei aus dem Template-Verzeichnis holen. Dies erlaubt eine viel einfachere Wartung des Plugins und trennt die Darstellung von der CodeAusführung sauber. In dieser Datei, die wir im nächsten Schritt befüllen, ist darauf zu achten, dass du den gleichen Namensraum verwendest, den du auch vorher definiert hast. In diesem Fall “wp_plugin_template-group”.

Es empfiehlt sich auch in jedem Fall die WordPress Codex Seiten durchzulesen, die das Aufrufen und Speichern von Einstellungen genau beschreiben.

Folgenden HTML Code legen wir nun in der settings.php im Ordner templates/ (!) ab:

Damit es auch einen Einstellungslink innerhalb der Pluginseite (neben den Aktivieren/Deaktivieren Link) gibt, empfiehlt es sich noch folgenden Code innerhalb der Klasse “class WP_Plugin_Template” in der Datei wp-plugin-name.php direkt nach der Funktion “public static function deactivate()” einzufügen:

 

Einen Custom Post Type definieren

Da wir ja auch einen eigenen Custom Post Type für dieses Plugin benötigen (das Plugin kann zum gegenwärtigen Zeitpunkt nicht aktiviert werden, da dieser vorrausgesetzt wird), müssen wir diesen nun ebenfalls definieren. In diesem Beispiel definieren wir nur einen Typ. Dieser ist (nach unserer Struktur) im Verzeichnis post-types/ in der Datei post_type_template.php abgelegt.

In diesem Code gibt einen String bzw. Konstante namens “POST_TYPE”. Dieser String definiert den Namen dieses Custom Post Typs. Außerdem wird auch ein Array “$_meta” erzeugt. Dieses Array beinhaltet dann alle jeweiligen Felder dieses Typs.

Natürlich benötigt dieser Typ auch alle Funktionen von WordPress, damit das Ganze funktioniert (so genannte Hooks). Diese laden wir direkt darunter hinein:

Jetzt müssen wir noch eine Initialisierung zur Speicherung bzw. Verarbeitung dieses Post Typs erlauben. Dies erlauben wir mit folgenden Codezeilen wieder in derselben Datei direkt unter dem oben eingefügten Code:

Was man dabei alles laden und verarbeiten kann, sollten folgende WordPress Codex Seiten verdeutlichen:

Folgender Code erlaubt das Erzeugen dieses Custom Post Types (wieder direkt unter dem oben eingefügten Code, nach wie vor in der Datei “post_type_template.php” einfügen):

Die Routine zur Speicherung der Metabox Inhalte folgt direkt danach:

Damit wir diese Metaboxen auch sehen und befüllen können, benötigen wir wieder einen ActionHook (wiederum einfach direkt unter dem oben angeführten Code einfügen):

So… und ganz am Ende (bevor wir diese Dati bzw. Klasse schließen) benötigen wir noch die Einbindung des HTML Konstrukts für diese Datei. Aus unserer Struktur heraus liegt diese ja in dem Verzeichnis templates/ und hat in diesem Fall den Dateinamen “post-type-template_metabox.php”. Also rufen wir diese auch so auf:

Achtung: Wir geben nicht den direkten Dateinamen, also post-type-template_metabox.php an, sondern arbeiten in diesem Fall mit einem String namens %s. Dieser ergänzt den Dateinamen je nach Custom Post Type. Beim Aufruf des Types “post-type-template” rufen wir also die Datei post-type-template_metabox.php auf.

Damit wir keinen Fehler erzeugen, erstellen wir nun im Verzeichnis templates/ auch die benötigte Datei post-type-template_metabox.php mit folgendem Inhalt:

Theoretisch sollte man nun ein Plugin haben, welches

  • eine Einstellungsseite besitzt
  • einen eigenen Post Type mit Metaboxen verwendet
  • und eine eigene Logik (getrennt vom Hauptcode) aufweist

[box type=”note” width=”100%” ]Ich bin so ehrlich und sage dir… bei mir hat es nicht funktioniert. Nach dem Aktivieren des Plugins war die Seite weiß und that´s it. Als Ursache dafür gibt es einige Möglichkeiten, wie unter anderem der Umstand, dass Francis den Code nachträglich geändert/verbessert hat und dies in seiner Dokumentation leider nicht lückenlos nachgezogen hat (die Beschreibung auf seiner WordPressseite und dem Code auf Github kann man teilweise nicht ganz folgen), aber auch die Tatsache dass ich eventuell während meiner Erklärung hin und wieder vergessen habe, Teile des Codes in meine Dateien einzufügen. Auf alle Fälle funktionierte das Plugin als ich eine 1:1 Kopie der Dateien von Code auf Github vorgenommen habe. Ich werde das Ganze demzufolge noch analysieren.[/box]

 

Die Lösung (umgesetzt)

Wie das Ganze dann aber aussehen sollte, zeige ich dir hier:

wp_plugin_entwicklung_02

Das Plugin zeit nach dem Aktivieren auch den Link zu den Einstellungen (Settings) an. Wie von uns “programmiert”. Klickt man diesen Link an, kommt man zu dem unspektakulären Einstellungsfenster dieses Plugins:

wp_plugin_entwicklung_03

Diese Seite kann im Prinzip lediglich das Aufnehmen, Speichern und Anzeigen von zwei Einstellungen. Egal was du hier einfügst, es hat keine Auswirkungen auf das Plugin da wir das auch nicht so programmiert haben. Aber es zeigt, wie einfach es ist, eine Einstellungsseite zu erzeugen und letztendlich auch mit ihr zu arbeiten.

Sehen wir uns doch mal den neuen Posttype an, den wir im Administrationsmenü sehen sollten:

wp_plugin_entwicklung_04

Wichtig ist dabei zu beachten, dass die Spalten bei dir ganz anders sein können. Je nachdem welche Plugins du installiert hast. Die Spalten mit dem Zusatz “SEO” gehören z.B. alle zu dem Plugin “Yoast WordPress SEO”. Also nicht verwirren lassen. Klickt man nun auf Erstellen, so ist es möglich einige Felder (ähnlich wie beim Hauptbeitragsfenster) zu befüllen:

wp_plugin_entwicklung_05

Ganz unten sieht man auch unsere drei definierten Metaboxen für diesen Posttype:

wp_plugin_entwicklung_06

Alle Inhalte können nun gespeichert werden. Die Metaboxen (zurzeit) werden nur im Backend angezeigt.

Das ist quasi die Basis für jedes Plugin. Vielleicht hilft es ja dem einem oder anderem und freue mich natürlich auf Anregungen und Kommentare. Die Originaldateien von Francis können unter diesem Link https://github.com/fyaconiello/wp_plugin_template eingesehen werden.

No Comments

Post a Comment