Ein WordPress Plugin erstellen lernen

Mit diesem großen, deutschen Nachschlagewerk ein eigenes WordPress Plugin programmieren lernen

Online-Zugriff
  • Alle Inhalte aus dem Einsteiger-eBook.
  • Plus 16 weitere Kapitel (siehe Index unten).
  • Plus: jeden Monat aktualisiert.
  • Derzeitiger Stand: Mai 2018.
€ 47,00 / jährlichAlles auf einmal und immer aktuell!
eBook + APIs
  • Einsteiger-eBook + 11 ergänzende Kapitel zu verschiedenen APIs.
  • Im epub-, mobi- und PDF-Format (druckbar).
  • Passend für WordPress 4.9 und höher.
  • Zuletzt aktualisiert im Dez. 2017.
€ 37,00 / einmaligals Sofort-Download
Einsteiger eBook
  • Die ersten drei Kapitel als Einsteiger-eBook.
  • Erhältlich im epub-, mobi- und PDF-Format (druckbar).
  • Passend für WordPress 4.9 und höher.
  • Zweite Auflage vom Jan. 2017.
  • Zuletzt aktualisiert im Feb. 2017.
€ 17,00 / einmaligals Sofort-Download
WordPress Programmierer kniend mit iPad

Das WordPress-Entwickler Buch

Ein WordPress Plugin erstellen eBook Cover

WordPress ist weltbekannt. Millionen Seiten nutzen es. Aber nicht jeder kennt die Details. Deswegen möchte ich Sie mit meinem Buch dabei unterstützen, Ihre WordPress-Kenntnisse auf die nächste Stufe zu heben und Sie auf dem Weg zum Profi zu begleiten.

Ich biete Ihnen mehrere Optionen:

  1. Die ersten zwei Kapitel können Sie gratis auf dieser Seite lesen (Los geht’s!).
  2. Kapitel drei befindet sich zusätzlich im eBook, welches sich seit zwei Jahren auf dem Markt befindet und mittlerweile in der zweiten Auflage vorliegt.
  3. Die ersten drei sowie alle weiteren Kapitel können Sie mit einer im großen, deutschen Nachschlagewerk lesen. Und zwar ständig aktualisiert. Dazu ist eine Anmeldung im Mitgliederbereich notwendig.

Im Mitgliederbereich veröffentliche ich jeden Monat ein weiteres Kapitel. Da der Wert damit natürlich auch steigt, erhöht sich auch der Preis jeden Monat.
Je früher Sie dabei sind, desto mehr sparen Sie. Und zwar dauerhaft. Denn der günstige Preis bleibt für die Dauer Ihrer Mitgliedschaft bestehen.

Der Autor

Servus. Mein Name ist Florian. Ich bin Diplom Ingenieur (FH) für Medientechnik und Medieninformatik. Vielleicht haben Sie schon einmal einen Artikel von mir gelesen. Zum Beispiel in der WordPress-Zeitschrift von entwickler.de (Leseprobe). Mittlerweile kann ich auf mehr als 17 Jahre Erfahrung in der PHP-Programmierung zurückblicken. In dieser Zeit konnte ich bereits vielen Kunden bei interessanten Projekten ausführend zur Seite stehen. Im Jahre 2011 habe ich mich auf die WordPress Entwicklung spezialisiert. Seitdem sind viele WordPress Plugins und Themes entstanden, die bei vielen Kunden rund um die Welt im Einsatz sind.

Folgen Sie mir mir auf Twitter. Oder bleiben Sie in Kontakt durch den WordPress Entwickler Newsletter. Exklusiv nur für die Devs unter Ihnen.

Erfolgreich ein WordPress Plugin erstellen – Leseprobe

— Dies ist eine Leseprobe —

  • Kapitel 1 und 2 sind direkt auf dieser Seite lesbar.
  • Kapitel 3 (Hooks) befindet sich zusätzlich im Buch.
  • Alle weiteren Kapitel (inklusive alle Teile aus dem Buch) finden Sie im Mitgliederbereich. Welche Kapitel das
    sind, können Sie dem Index unten entnehmen.

Sie können das Buch hier kaufenOder Sie werden Mitglied

Tragen Sie sich zum WordPress Entwickler-Newsletter ein, wenn Sie darüber informiert werden möchten, wenn neue Kapitel erscheinen:


Erfolgreich ein WordPress Plugin erstellen

Schritt für Schritt ein eigenes WordPress Plugin programmieren

Dipl. Ing. (FH) Florian Simeth

0.1. Impressum

Copyright: © 2015-2018 Dipl. Ing. (FH) Florian Simeth

Dipl. Ing. (FH) Florian Simeth
Fürbergring 13
94259 Kirchberg i. Wald
Web: wp-plugin-erstellen.de
E-Mail: florian@wp-plugin-erstellen.de

Umschlaggestaltung:
Joachim Ciliox, AnzeigenSpezialist.de

Satz und Layout:
Florian Simeth

Umschlagbild:
© Michael Rosskothen – Fotolia.com

1 Auflage; Januar 2015

2 Auflage; Januar 2017

3 Auflage; Kontinuierliche Aktualisierung 2018

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.

Ebenso wurden die in diesem Buch angegebenen Internet-Adressen und -Dateien vor Drucklegung geprüft (Stand: Januar 2015). Der Verlag, die Autoren und Übersetzer übernehmen keine Gewähr für die Aktualität und den Inhalt dieser Adressen und Dateien und solcher, die mit ihnen verlinkt sind.

Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind möglicherweise eingetragene Warenzeichen. Der Verlag und die Autoren richten sich im Wesentlichen nach den Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.

Bei den in diesem Buch abgebildeten Firmenlogos, Anzeigen, Anzeigenausschnitten, Internetseiten und Produktabbildungen handelt es sich ausschließlich um Anschauungsbeispiele. Es wird ausdrücklich darauf hingewiesen, dass eine Vervielfältigung und Nutzung zu anderen Zwecken nicht gestattet ist.

Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

0.2. Index

  1. 0.1. Impressum
  2. 0.2. Index
  3. 0.3. Zu Anfang
    1. 0.3.1. Dank
    2. 0.3.2. Vorwort
    3. 0.3.3. Einführung
    4. 0.3.4. Wer soll dieses Buch lesen?
    5. 0.3.5. Was Sie benötigen
    6. 0.3.6. Was dieses Buch beinhaltet
    7. 0.3.7. Die Struktur dieses Buches
    8. 0.3.8. Der Quellcode
    9. 0.3.9. Fehler im Quellcode
  4. 1. Kapitel 1 – Der Überblick
    1. 1.1. Was ist ein WordPress Plugin?
    2. 1.2. Vorteile von Plugins
    3. 1.3. Wo man Plugins findet
    4. 1.4. Die beliebtesten Plugins
    5. 1.5. Wie Plugins mit WordPress interagieren können
    6. 1.6. Wann Plugins geladen werden
    7. 1.7. Wie man Plugins installiert und aktiviert
    8. 1.8. Plugins mit dem Editor bearbeiten
    9. 1.9. Plugin-Typen
  5. 2. Kapitel 2: Ein Leitfaden zur Plugin-Entwicklung
    1. 2.1. Eine Plugin-Datei erstellen
    2. 2.2. Der richtige Plugin-Name
    3. 2.3. Der Kopfbereich
    4. 2.4. Lizenzverträge
    5. 2.5. Coding Standards
    6. 2.6. Dokumentations-Standards
    7. 2.7. Präfixe
    8. 2.8. Datei- und Verzeichnisstruktur
    9. 2.9. Die ersten Codezeilen
  6. 3. Kapitel 3 – Hooks
    1. 3.1. Filter und Aktionen
    2. 3.2. Actions
    3. 3.3. Filter
    4. 3.4. Art der Übergabe von Funktionen
    5. 3.5. Filter und Actions finden
    6. 3.6. Einfaches Beispiel mit Hooks: Drafts for Friends
  7. 4. Kapitel 4 – Plugin Integration
    1. 4.1. Top- und Second-Level Menüs
    2. 4.2. Metaboxen
    3. 4.3. Die Settings API
    4. 4.4. Die Options API
    5. 4.5. Widgets API
  8. 5. Kapitel 5 – Plugin Sicherheit
    1. 5.1. Nonces
    2. 5.2. Benutzerrechte
    3. 5.3. Rollen
    4. 5.4. Filtern: Validieren und Säubern
    5. 5.5. Superglobale Variablen
    6. 5.6. Formulare
    7. 5.7. Sichere Datenbankmanipulationen
    8. 5.8. Sicherheit im Allgemeinen
  9. 6. Kapitel 6 – Internationalisierung
    1. 6.1. Allgemeine Sprachdatei-Funktionen
    2. 6.2. Übersetzungsfunktionen
    3. 6.3. Platzhalter in Übersetzungen
    4. 6.4. Übersetzung von Javascript-Inhalten
    5. 6.5. Übersetzungsdateien erstellen
    6. 6.7. Portable-Object- (PO) und Message-Object- (MO) Dateien
    7. 6.8. Software- und Web-Tools zur Übersetzung
    8. 6.9. Eine PO-Datei erstellen
  10. 7. Kapitel 7 – Benutzer und Rechte
    1. 7.1 Benutzer-Handling
    2. 7.2 Benutzer-Metadaten
    3. 7.3 Benutzerdaten in Multisite-Umgebungen
    4. 7.4. Weitere Benutzerfunktionen
  11. 8. Kapitel 8 – Shortcode API
    1. 8.1. Einen Shortcode erstellen
    2. 8.2. Standardwerte von Shortcode Attributen
    3. 8.3. Einen Shortcode entfernen
    4. 8.4. Alle Shortcodes löschen
    5. 8.5. Existenz eines Shortcodes prüfen
    6. 8.6. Inhalte auf Shortcode prüfen
    7. 8.7. Shortcodes aus einem Inhalt entfernen
    8. 8.8. Shortcodes umwandeln
    9. 8.9. Weitere Shortcode-Funktionen
    10. 8.10. Anmerkungen zu den Shortcodes
  12. 9. Kapitel 9 – Grundlagen für HTTP-Abfragen
    1. 9.1 Helfer-Funktionen
    2. 9.2 Verbindungsmethode testen
    3. 9.3 Fortgeschrittene Konfigurationsmöglichkeiten
    4. 9.4 Mögliche Stolpersteine bei der Arbeit mit der HTTP-API
    5. 9.5 Beispiele
  13. 10. Kapitel 10 – Daten Zwischenspeichern: Die Transient API
    1. 10.1 set_transient()
    2. 10.2 get_transient()
    3. 10.3. delete_transient()
    4. 10.4 Hinweise und Notizen
  14. 11. Kapitel 11 – Benutzerdefinierte Artikeltypen
    1. 11.1. Benutzerdefinierten Artikeltypen erstellen
    2. 11.2. Capabilities in benutzerdefinierten Artikeltypen
    3. 11.3. Post Type entfernen
    4. 11.4. Hilfsfunktionen für benutzerdefinierte Artikeltypen
    5. 11.5. Frontend-Loop mit benutzerdefinierten Artikeltypen
  15. 12. Kapitel 12 – Benutzerdefinierte Taxonomien (Taxonomy API)
    1. 12.1. Taxonomien registrieren
    2. 12.2. Taxonomien entfernen
    3. 12.3. Registriertes Taxonomie zurückgeben
    4. 12.4. Registrierte Taxonomien zurückgeben
    5. 12.5. Taxonomie für ein Objekt erstellen
    6. 12.6. Taxonomie von Objekt entfernen
    7. 12.7. Hilfsfunktionen für Taxonomien
    8. 12.8. Taxonomien im Frontend
  16. 13. Kapitel 13 – Benutzerdefinierte Ausdrücke (Terms API)
    1. 13.1. Einen neuen Term erstellen
    2. 13.2. Überprüfen ob ein Term existiert
    3. 13.3. Anzahl der Terme einer Taxonomie ausgeben
    4. 13.4. Term aus der Datenbank auslesen
    5. 13.5. Term anhand verschiedener Daten lesen
    6. 13.6. Terme einer Taxonomie auslesen
    7. 13.7. Hierarchisch gelistete Kind-Terme auslesen
    8. 13.8. Eltern und Kind Beziehung von Termen
    9. 13.9. Term löschen
    10. 13.10. Term aktualisieren
    11. 13.11. Alle Objekte eines Terms zurückgeben
    12. 13.12. Term-Objekt-Verbindungen
    13. 13.13. Arbeiten mit Termen im Frontend
    14. 13.14. Ausnahmefall: Kategorien und Schlagwörter
  17. 14. Kapitel 14 – CSS und JavaScript API
    1. 14.1. CSS- und JS Hooks
    2. 14.2. JavaScript
  18. 15. Kapitel 15 – Cronjobs
    1. 15.1. Crojob anlegen/planen
    2. 15.2. Cronjob entfernen
    3. 15.3. Prüfen, ob ein Cronjob geplant wurde
    4. 15.4. Eigene Zeitintervalle festlegen
    5. 15.5. Einzelnen Cronjob planen
    6. 15.6. Cronjob neu planen
  19. 16. Kapitel 16 – Rewrite API
    1. 16.1. So funktioniert ein Rewrite
    2. 16.2. Eine neue Rewrite Regel anlegen
    3. 16.3. Neue Rewrite Variablen anlegen
    4. 16.4. Rewrite-Variablen abrufen
    5. 16.5. Rewrite-Variablen setzen
    6. 16.6. Rewrite-Variable entfernen
    7. 16.7. Rewrite-Cache leeren
    8. 16.8. Plugin fertigstellen (Zwischenkapitel)
    9. 16.9. Eine neue Permalink-Struktur anlegen
    10. 16.10. Eine Permalink-Struktur entfernen
    11. 16.11. Url zur Post-ID auflösen
  20. 17. Kapitel 17 – Metadata API
    1. 17.1. Metadaten anlegen
    2. 17.2. Metadaten updaten
    3. 17.3. Metadaten auslesen
    4. 17.4. Metadaten löschen
    5. 17.5. Metadaten anhand einer Meta-ID bearbeiten
    6. 17.6. Helfer-Funktionen
    7. 17.7. Meta-Schlüssel registrieren
  21. 18. Kapitel 18 – Database API
    1. 18.1. Wichtige Klassen-Parameter
    2. 18.2. Wichtige Klassen-Methoden
    3. 18.3. Eine Verbindung aufbauen und schließen
    4. 18.4. Datenbank auswählen
    5. 18.5. Beispiel
    6. 18.6. Weitere Datenbank-Methoden
  22. 19. Kapitel 19 – Best Practices
    1. 19.1. Konsequenz im Layout
    2. 19.2. Errorhandling
    3. 19.3. Nützliche WordPress Funktionen die kaum jemand kennt

0.3. Zu Anfang

0.3.1. Dank

Melanie, danke, dass du mir den Mut gemacht hast, dieses Buch zu schreiben.

0.3.2. Vorwort

Vielen Dank, dass Sie sich für dieses Buch entschieden haben. Ich gehe davon aus, dass Sie von WordPress bereits Vieles gehört haben. Es ist mittlerweile zum weit verbreitetsten System zur Verwaltung von Webseiten geworden. Knapp ein Viertel aller Internetseiten werden via WordPress bereitgestellt. So zumindest die Aussage der Redaktion von w3techs.com, die regelmäßig Umfragen zu allen gängigen Web-Technologien durchführt
1. Kein anderes System hat mehr Marktanteil. Und dem kann man ruhig Glauben schenken, wenn man bedenkt, dass mittlerweile Größen wie CNN, The New York Times oder eBay WordPress erfolgreich einsetzen.

Dreizehn Jahre lang steht WP, wie WordPress oft kurz genannt wird, nun schon zum Download bereit. Im Januar 2004 gab es Matt Mullenweg für die globale Verwendung frei. Es entstand aus dem Weblogsystem b2/cafelog, welches zur damaligen Zeit nicht mehr weiterentwickelt wurde. Daraus ließe sich ableiten, dass WordPress lediglich ein Blogging-System wäre. Über die Jahre hat sich allerdings sehr viel getan.

Da WordPress als Open-Source verfügbar ist, wurde es nicht nur für Unternehmen, sondern auch für jeden Individualisten einfach, eine Website zu erstellen und zu bearbeiten. Letztlich war genau das auch die Intention von Matt: Eine Website soll von jedem sehr einfach und kostengünstig erstellt und verwaltet werden können. Die konstante Weiterentwicklung, die sehr starke Verbreitung und nicht zuletzt die Unterstützung der gesamten Community haben dazu geführt, dass aus WP ein umfangreiches Content-Management-System, kurz CMS, geworden ist.

Mittlerweile existieren mehr als 48.000 Plugins (Stand: Januar 2017) alleine in der kostenlosen Plugin-Datenbank auf wordpress.org. Zum Vergleich: Anfang 2014 waren es noch 28.000. Dem Ideenreichtum der Benutzer scheinen keine Grenzen gesetzt zu sein. Dazu kommt, dass auch der kommerzielle Plugin-Markt (also alle nicht-kostenlos erhältlichen Plugins) stetig wächst. 2016 gab es 1,48 Milliarden Downloads
2. Das entsprach einem Wachstum von 34%. Tendenz steigend.

WordPress macht es einem Entwickler aber auch wirklich einfach, Erweiterungen zu programmieren. Doch auch nach dreizehn Jahren gibt es ein großes Problem: Die Dokumentation ist noch immer unvollständig und auf Deutsch nicht verfügbar. Inhalte zum Thema „WordPress Plugin erstellen“ lassen sich zwar auch kostenlos im Netz finden. Diese sind jedoch oft weit verstreut, in kleine Code-Schnipsel zerteilt und nicht selten einfach so alt, dass sie in einem neuen Plugin gar nicht mehr funktionieren würden. Deshalb möchte ich mit diesem Buch einen Einblick in die WordPress-Plugin-Programmierung geben.

Viel Spaß beim Coden!

0.3.3. Einführung

WordPress ist wohl deshalb so populär, weil es kostenlos ist. Die Open-Source Software lässt sich herunterladen, verändern oder weiterverbreiten. Und mindestens genauso einfach ist es, die Funktionalität durch Plugins zu erweitern.

Ein sehr früher Meilenstein in der Entwicklung von WordPress war, dass es schon in Version 1.2, die bereits vier Monate nach der ersten Version veröffentlicht wurde, die Möglichkeit der Erweiterung durch Plugins vorsah. Dadurch war es möglich, WordPress so zu modifizieren, dass es den eigenen Vorstellungen entsprach. Der große Vorteil dabei war, damals wie heute, dass der eigentliche Quelltext von WordPress (kurz: der „Core“, engl. für „Kern“) dabei nicht angetastet werden musste.

Für Plugin-Entwickler ist eine solche Konstellation unglaublich effizient. Denn man muss sich nur noch auf die Programmteile konzentrieren, mit denen man sich persönlich auskennt. So lässt sich zum Beispiel die Funktion
wp_mail() ganz einfach nutzen, um Mails zu versenden. Es ist nicht unbedingt nötig, zu wissen wie die Funktion intern arbeitet. Dennoch ist es aber auch möglich, direkt in das Verhalten von
wp_mail() einzugreifen, ohne die Grundfunktion an sich zu verändern.

Auch wenn die kostenlose Plugin-Datenbank auf wordpress.org eine schier unendliche Masse an Erweiterungen bereitstellt, werden Sie bald feststellen, dass es Plugins gibt, die nicht mehr funktionieren, nicht mehr weiterentwickelt werden oder nicht genau den Funktionsumfang haben, den Sie gerade benötigen. Es liegt also nahe, sich ein eigenes Plugin oder zumindest eine Abwandlung eines vorhandenen Plugins selbst zu programmieren.

0.3.4. Wer soll dieses Buch lesen?

Dieses Buch wurde in erster Linie für Webentwickler geschrieben, die in Zukunft mit WordPress arbeiten und eigene Plugins erstellen wollen. Es soll die Entwicklung Plugins von Grund auf beschreiben, setzt aber auch ein bestimmtes Vorwissen (siehe unten) voraus.

Es kann aber auch dazu benutzt werden, das eigene Wissen zu erweitern. Egal ob man haupt- oder nebenberuflich bereits mit WordPress zu tun hat oder hatte. Es kann nie schaden, zu wissen was „unter der Haube“ steckt und wie man letztlich so eingreifen kann, dass die „Maschine“ genau das tut, was man gerne möchte.

Oder Sie sind ein Blogger der sich dafür interessiert, wie die eigene Bloggingplattform tickt und wie man sie selbst anpassen kann. Wer weiß, vielleicht schreiben Sie eines Tages sogar selbst in die Online-Dokumentation von WordPress und erklären den Lesern die einzelnen Funktionen. Auch das kann ein Anreiz sein und ist im übrigen gar nicht so abwegig. Schon 2015 – auf dem WordCamp in Köln – saß ich in einem Vortrag in dem erwähnt wurde, dass viele zukünftige Programmierer heute direkt von WordPress zu PHP kommen.

Letztlich ist es ein Buch für all diejenigen, die WordPress selbst erweitern möchten.

0.3.5. Was Sie benötigen

Dieses Buch setzt voraus, dass Sie bereits im Besitz eines Webservers oder eines einfachen Webspeicherplatzes sind, auf dem WordPress installiert ist. Dass die 5-Minuten-Installation so einfach ist, dass auch der Laie damit zurechtkommt, dürfte sich längst herumgesprochen haben. Viele Webhoster bieten mittlerweile auch automatische Installationsroutinen an. Damit lässt sich WordPress noch schneller und oft in weniger als ein paar Sekunden installieren.

Um alles etwas einfacher zu gestalten, wäre es von Vorteil, wenn Ihre WP-Installation auf Ihrem lokalen Rechner läuft (localhost). Das macht es Ihnen leichter, ein Plugin zu entwickeln. Mit den kostenlosen Tools MAMP (für Mac OS X), WAMP (für Windows) oder LAMP (für Linux) ist das in wenigen Augenblicken geschehen. Natürlich funktioniert das auch mit virtuellen Maschinen. Auch hierfür existieren Anwendungen wie „Local by Flywheel“. Aber das wissen Sie ja sicherlich bereits.

Das Herz dieses Buches bilden die großen und kleinen Code-Ausschnitte (kurz: Schnipsel). Fast alle Schnipsel sind in PHP geschrieben und oft mit HTML ausgezeichnet. Sie sollten deshalb zumindest einfachen PHP-Code lesen und schreiben können. Sie müssen jedoch kein Guru im Umgang mit PHP sein. Ich werde versuchen, schwierigen Code soweit es geht so zu beschreiben, dass Sie ihn verstehen können.

Ab und an werden Sie ebenfalls auf Datenbankabfragen stoßen, die allesamt mit MySQL beschrieben werden. Grundkenntnisse in der Syntax dieser Sprachen helfen Ihnen, mehr zu verstehen.

Dies gilt auch für die Abschnitte, die Javascript-Inhalte behandeln. Die Stichwörter hier sind jQuery sowie AJAX.

0.3.6. Was dieses Buch beinhaltet

Während der Entstehung dieses Buches stand WordPress 4.1 in den Startlöchern. Mittlerweile sind wir bei Version 4.7 angekommen. Bis Ende 2016 erschienen ungefähr drei Hauptversionen pro Jahr die immer wieder neue Möglichkeiten mit sich brachten. Mullenweg hat sich dann allerdings von diesem Release-Zyklus verabschiedet und den Fokus auf drei Dinge gelegt: Design, Editor und REST-API.

Die REST-API fand in Version 4.4 Einzug in den Core. Sie enthielt zum ersten mal die Infrastruktur, die dann in Version 4.7 noch um die so genannten Content-Endpoints erweitert wurde. Damit war es zum ersten Mal möglich, WordPress-Inhalte über eine Schnittstelle abzurufen oder zu verändern. Das ermöglicht z.B. das Abrufen von Daten über externe Software. Auch ist es damit möglich, WordPress headless (also kopflos) ohne Frontend zu betreiben oder das Frontend in einer komplett anderen Technologie (z.B. mit React) zu betreiben.

In den letzten Jahren wurden viele PHP-Funktionen zu so genannten APIs (engl. für Application Programming Interface) zusammengefasst und viele – wie z.B. die REST-API – kamen neu hinzu. Sie sollen den Umgang mit WordPress erleichtern und stellen gleichzeitig sicher, dass sie auch noch in zukünftigen Versionen funktionieren werden.

In den letzten zwei Jahren habe ich viele Rezensionen von meinen Käufern gesammelt. Eine Rezension ist mir dabei im Kopf geblieben. Der Verfasser meinte, dass das eBook für ihn zu sehr eine Funktionsreferenz als ein Lernbuch sei. Diese Meinung habe ich – bis jetzt – zwar nur einmal gehört, dennoch habe ich mir die Frage oft selbst gestellt:
„Ist es wirklich zu sehr eine Funktionsreferenz? Und wenn ja: kann ich es anders machen? Oder anders gefragt: muss
ich das überhaupt?“

Diese Frage hat sich über die letzten zwei Jahren dann selbst beantwortet. Und zwar aus einer ganz anderen Schiene heraus. Ich war auf der Suche nach guten WordPress Entwicklern. Fast alle von ihnen schworen darauf, WordPress zu kennen und ein guter Entwickler zu sein. Letzteres war dabei immer der Fall. Erstens leider nicht. Herausfinden konnte ich das, weil ich einigen Entwicklern eine Testaufgabe gab. Sie sollten einen UNIX-Zeitstempel relativ zur aktuellen Zeit lesbar zu machen. Ich wollte also darstellen, dass z.B. ein Zeitstring von einem Kommentar so dargestellt wird:

geschrieben vor x Sekunden

oder

geschrieben vor x Minuten

oder

geschrieben vor x Stunden.

Je nachdem, was für den Menschen besser lesbar wäre.

Fast alle Entwickler schrieben dafür ihre eigene PHP-Funktion. Dabei wäre es so einfach gewesen. In WordPress gibt es die Funktion nämlich schon. Sie nennt sich
human_time_diff().

Aus diesem Grunde werde ich weithin in diesem Buch versuchen, so viele interne WordPress-Funktionen wie möglich zu beschreiben. Natürlich mit möglichst ausführlichen Beispielen.

Aus Erfahrung weiß ich, dass gerade viele der kleineren Code-Schnipsel auch in Zukunft noch voll funktionsfähig sein werden. Mein erstes, kostenloses und ins WordPress-Plugin-Verzeichnis eingetragenes Plugin ging online, als Version 3.3 aktuell war. Ohne irgendetwas zu verändern, funktioniert es noch heute tadellos. Zwar handelt es sich dabei nur um ein sehr kleines Script, der Grund, warum es heute noch funktioniert, ist vermutlich aber ein anderer: Einmal eingeführte Funktionen werden bei einem Versionssprung von WordPress nicht einfach entfernt. Stattdessen wird versucht, dem Entwickler eine Fehlermeldung anzuzeigen, die auf den Missstand hinweist.

0.3.7. Die Struktur dieses Buches

Ich habe das Buch gedanklich in zwei Bände geteilt. Der erste Band liegt Ihnen gerade vor und gibt im Kapitel 1 einen Überblick über das Arbeiten mit WordPress und geht in Kapitel 2 in einen allgemeinen Leitfaden zur Plugin-Entwicklung über.

Kapitel 3 bespricht die sogenannten Hooks. Das Verständnis der Hooks ist Voraussetzung für die Programmierung von Plugins mit WordPress und ist damit ein ideales Grundgerüst für den Start.

Angefangen mit dem Kapitel „Plugin-Integration“ werde ich im zweiten Band, alle gängigen APIs beschreiben. Von der Dashboard-Widget API, über die HTTP-API bis hin zur Rewrite-, Shortcode- und Widget-API. Diese Kapitel können in der Reihenfolge gelesen werden, wie Sie sie benötigen, wohingegen die Kapitel im ersten Band jeweils aufeinander aufbauen.

0.3.8. Der Quellcode

Während Sie im Buch lesen, können Sie entweder den Quellcode der einzelnen Code-Schnipsel direkt abtippen oder ganz einfach kopieren, indem Sie dem jeweiligen Link folgen. All diese Inhalte finden Sie auf Github. Sie sind frei erhältlich und können jederzeit kostenlos von Ihnen benutzt werden. Beachten Sie, dass ich keinerlei Verantwortung für die Richtigkeit der Code-Schnipsel übernehmen kann, falls diese in den produktiven Einsatz gelangen sollten.

0.3.9. Fehler im Quellcode

Ich versuche, möglichst alle Inhalte fehlerfrei zu halten. Aber natürlich ist niemand perfekt. Wenn Sie einen Fehler im Buch oder in einem Quellcode finden, lassen Sie es mich bitte wissen. In Zeiten von eBooks sind diese relativ schnell ausgebessert. Somit steigt nicht nur die Qualität dieses Buches. Zusätzlich ersparen Sie einem anderen Leser vielleicht eine stundenlange Fehlersuche.

Sie glauben, Sie haben einen Fehler gefunden? Sicherlich haben Sie bereits einen Github Account, der es Ihnen erlaubt, diesen selbst zu beheben oder Kommentare zu hinterlassen. Ansonsten schreiben Sie bitte direkt an florian@florian-simeth.de.

Vielen Dank!

1. Kapitel 1 – Der Überblick

1.1. Was ist ein WordPress Plugin?

Ein Plugin ist ein in PHP geschriebenes Skript, welches die Funktionalität von WordPress erweitert oder ein bestimmtes Verhalten modifiziert. Einfacher ausgedrückt ist ein Plugin eine Datei (oder eine Sammlung von Dateien), welche – nach Aktivierung – WordPress um einen bestimmten Funktionsumfang erweitert. Dabei kann die Komplexität sehr stark variieren. So existieren Plugins mit nur zwanzig Zeilen Code genauso wie ganze E-Commerce Erweiterungen mit mehreren hundert Dateien. Da fast keine Beschränkungen existieren, verwundert es nicht, dass täglich neue Plugins in die kostenlose Plugin-Datenbank aufgenommen werden.

1.2. Vorteile von Plugins

  1. Keine Anpassung von WordPress notwendig.
    Nicht jede Website ist gleich. Jede hat ihr gewisses Etwas, hat eigene Funktionen und Erweiterungen.
    Und genau deshalb erlaubt WordPress das Aktivieren von Plugins per Mausklick. Sie erlauben nämlich, in die
    bereits bestehenden Funktionen einzugreifen, ohne das Grundgerüst von WordPress, der sogenannten „Core“,
    bearbeitet werden muss. Das wäre auch viel zu umständlich. Denn wenn Sie mehrere Websites betreiben oder
    administrieren, würden Sie schon bald die Übersicht verlieren. Darüber hinaus würden mit einem Update alle
    Änderungen verloren gehen. Und ohne Updates entgehen Ihnen womöglich viele zusätzliche, neue Funktionen sowie
    Fehlerbehebungen.
  2. Vorhandenes effektiv nutzen.
    Wie oben beschrieben und wie Sie weiter unten noch detaillierter sehen werden bringt WordPress schon
    sehr viele Funktionen mit. Sie müssen also das Rad meist nicht neu erfinden. Viele wichtige Routinen sind
    bereits integriert und müssen nicht neu entwickelt werden. Sie wollen beispielsweise, dass ein Benutzer sich
    selbst registrieren lassen kann? Nichts leichter als das! WordPress erlaubt das Registrieren von neuen Benutzern
    und schickt ihnen auf Wunsch sofort eine E-Mail mit Bestätigungslink zu.
  3. Trennung von Design und Code.
    Sicherlich ist Ihnen das sogenannte MVC-Modell (Model, View, Controller) bekannt. Danach werden die
    Daten (Model) vom Design (View) und dem eigentlich verarbeitenden Code (Controller) strikt getrennt. Somit
    besteht die Möglichkeit, dass ein Designer sein Layout selbst entwirft und einbindet. Im Gegensatz dazu kann der
    Entwickler seinen Code programmieren, ohne in das Design eingreifen zu müssen. WordPress ist fast genauso
    aufgebaut. Zumindest lassen sich Designvorlagen (so genannte „Themes“) genauso wie die Erweiterungen (also die
    „Plugins“) trennen.
  4. Update-Fähigkeit direkt über das Dashboard.
    WordPress hat einen Update-Mechanismus integriert. Zumindest für WordPress selbst, die Erweiterungen
    und die Themes, die über das offizielle WordPress.org-Archiv vertrieben werden. Sie können diesen Mechanismus
    aber auch für Ihre eigenen Zwecke „missbrauchen“ und Ihr Plugin anderweitig verkaufen. Updates lassen sich dann
    genauso einspielen. Sie müssen dem System lediglich mitteilen, wo sich die neue Datei befindet und wo sie
    heruntergeladen werden kann. Das Upgrade auf eine neue Version übernimmt dann WordPress für Sie.
  5. Einfache Plugin-Entwicklung.
    Im Großen und Ganzen können Sie sofort loslegen. Für ein einfaches Plugin reicht bereits eine einzige
    PHP-Datei. Wenn die Datei einen Fehler verursacht und WordPress dadurch unbenutzbar wird, brauchen Sie sie nur
    umzubenennen. WordPress deaktiviert das Plugin dann automatisch für Sie. Somit haben Sie eine voll
    funktionsfähige Sandbox-Umgebung, in der Sie nach Belieben testen können. Das bedeutet auch: Sie müssen nicht
    zig-tausend verschiedene Dateien und Codezeilen durchwühlen, um den Fehler zu finden. Zur Not lassen sich alle
    Plugins zu jeder Zeit deaktivieren. Damit kann man oft im Voraus schon ausschließen, ob irgendwelche Plugins
    nicht zueinander passen.
  6. Hilfsbereitschaft.
    WordPress besteht seit nunmehr 13 Jahren. In dieser Zeit haben sich viele Entwickler mit dem System
    beschäftigt und sind auf Hürden gestoßen, über die Sie vielleicht sogar selbst einmal stolpern werden. Eine
    kurze Websuche führt in der Regel sofort zur gewünschten Lösung. Denn im Web gilt: Es gibt niemanden der nicht
    schon einmal das gleiche oder zumindest ein ähnliches Problem hatte. In den vergangenen Jahren haben sich
    mehrere Hunderte von Blogs mit WordPress beschäftigt. Das ist Ihr persönlicher Vorteil. Denn wer mit einem
    Blogging-System arbeitet, betreibt meist selbst eines und teilt seine Erfahrungen öffentlich. Ein großer
    Pluspunkt bei Open-Source-Projekten.

1.3. Wo man Plugins findet

In der Regel kann man im gesamten Internet auf WordPress-Plugins stoßen. Viele davon sind kostenlos, einige wiederum nicht. Wie aber bei jedem anderen Download sollten Sie vorher sicherstellen, dass Sie der Website, die den Download bereitstellt, vertrauen können.

Die unglaublich schnelle Verbreitung von WordPress führte dazu, dass es auch für Hacker immer attraktiver wurde. In der Vergangenheit gerieten so auch bösartige Themes und Plugins in Umlauf. Sie zerstören die WordPress-Installation oder spionieren sensible Daten aus.

Als beste Quelle kann die WordPress-eigene Plugin-Datenbank uneingeschränkt empfohlen werden. Wie schon erwähnt umfasst sie mehrere zehntausend kostenlose Plugins die allesamt – zumindest beim initialen Upload – von einem Community-Mitglied gesichtet wurden. Man findet die Datenbank unter
http://wordpress.org/plugins/.

Alle dortigen Plugins stehen übrigens für den privaten und kommerziellen Gebrauch kostenlos zur Verfügung.

Weitere kostenpflichtige Plugins, die ebenfalls vor dem Veröffentlichen geprüft wurden, findet man zum Beispiel bei http://codecanyon.net/category/wordpress oder http://www.mojo-code.com/categories/wordpress/.

1.4. Die beliebtesten Plugins

Wie überall gibt es auch unter den WordPress Plugins im offiziellen Archiv eine Statistik die zeigt, wie oft ein Plugin heruntergeladen wurde. Hier die aktuelle Liste zum Stand Anfang 2017:

  1. Akismet – rund 55 Mio. Downloads
    Akismet ist ein Webservice, der alle Kommentare vorher auf Spam überprüft. Das hält zum einen natürlich die
    Anzahl von Spamkommentaren sehr gering, ist allerdings datenschutztechnisch nicht die beste Lösung. Da Akismet
    Daten wie Name, IP-Adresse und den Kommentartext zu amerikanischen Servern schickt, ist dieses Plugin in
    Deutschland nicht zu empfehlen. Sie sollten vorher rechtlich abklären, ob Sie ein solches Plugin nutzen können.
  2. Contact Form 7 – rund 46 Mio. Downloads
    Wie der Name schon sagt, dreht sich bei Contact Form 7 alles um Kontaktformulare. Diese lassen sich durch das
    Plugin relativ komfortabel selbst zusammenstellen.
  3. Yoast SEO – rund 40 Mio. Downloads
    Yoast SEO ist – wie der Name schon sagt – ein SEO Plugin. SEO steht dabei für Search Engine
    Optimization
    . Auf deutsch in etwa „Suchmaschinenoptimierung“. Es nutzt interne WordPress-Hooks um das
    beste aus WordPress herauszuholen.
  4. All in One SEO Pack – rund 32 Mio. Downloads
    Das „All in One SEO Pack“ Plugin hat sich der Suchmaschinenoptimierung (kurz SEO für engl. Search Engine
    Optimization) verschrieben. Es erstellt zum Beispiel XML Sitemaps, die sich später bei diversen Suchmaschinen
    hinterlegen lassen. Es bietet aber auch noch viele andere Möglichkeiten.
  5. Jetpack – rund 32 Mio. Downloads
    Jetpack ist ein Plugin von WordPress.com. Es beinhaltet mehrere kleine Plugins, die sich einzeln aktivieren
    lassen. Zum Beispiel ein Social-Sharing Plugin, Statistiken oder ein Bildoptimierungs-Plugin.

Bei den Download-Zahlen sind im Übrigen auch alle Update-Downloads eingeschlossen. Deswegen geben die Statistiken immer solche Ausschläge, wie im Bild unten zu sehen:

Abb. 1.4: Download-Statistiken des Akismet-Plugins. Bei Updates steigt die Downloadzahl sehr schnell an.
Abb. 1.4: Download-Statistiken des Akismet-Plugins. Bei Updates steigt die Downloadzahl sehr schnell
an.

Im Umkehrschluss heißt das auch, dass über „künstliche“ Updates (also Updates, die eigentlich keine Fehlerbehebungen und/oder neue Features beinhalten) die Downloadzahlen erhöht werden können.

1.5. Wie Plugins mit WordPress interagieren können

Im Moment existieren 18 verschiedene APIs, die nur danach schreien in Ihrem Plugin verwendet zu werden. Hier eine Liste davon:

  1. Dashboard Widget API
    Das Dashboard ist die Startseite im WordPress-Backend, die erscheint, wenn ein Benutzer sich einloggt.
    Die Dashboard-Widget-API erlaubt es Ihnen, kleine Widget-Bereiche zu integrieren. Sie werden oft dazu benutzt,
    aktuelle Inhalte wie News oder Statistiken) kurz und knackig darzustellen.
    Abb. 1.5.: Dashboard Widgets sind rot markiert
  2. HTTP API
    Sicherlich wissen Sie, dass es in PHP mehrere Möglichkeiten gibt, HTTP-Anfragen zu verschicken. Aber
    nicht jeder Webserver unterstützt jede einzelne Möglichkeit. Die Aufgabe der HTTP-API ist es nun, alle Optionen
    zu testen und dann diejenige auszuwählen, die funktioniert. So können Sie mit nur einer einzelnen Funktion
    Inhalte einer externen URL abrufen, ohne sich um die technischen Details kümmern zu müssen.
  3. File Header API
    In WordPress haben bestimmte Dateien (z.B. Plugins) einen sogenannten Header. Er besteht oft aus
    PHP-Kommentaren, die wiederum Meta-Informationen enthalten, die von der File-Header-API eingelesen werden
    können.
    Abb. 1.5.b: File Header einer Plugin-Datei
  4. Filesystem API
    Ursprünglich wurde die Filesystem API dazu entwickelt, den Update-Mechanismus von WordPress selbst zu
    vereinfachen und die Rechte auf dem Webserver zu überwachen. Mittlerweile lässt es sich aber auch in Plugins
    ganz einfach nutzen. Auch hier liegen die Vorteile auf der Hand: Man benutzt einige wenige ausgewählte
    Funktionen oder Methoden für Dateioperationen auf verschiedenen Hosts. Entweder über das Dateisystem selbst,
    FTP, Sockets oder SSH. WordPress wählt automatisch die richtige Methode aus.
  5. Metadata API
    Die Metadata-API erlaubt den Zugriff auf Metadaten über einen standardisierten Weg. Über die get_metadata()
    Funktion lässt sich der Wert eines Schlüssels zu einem Objekt abrufen. WordPress nutzt diese Funktion intern zum
    Beispiel um Metadaten zu Kommentaren, zu Beiträgen oder aber auch für Benutzer abzuspeichern.
  6. Options API
    Ähnlich wie die Metadata-API hilft auch die Options-API, bestimmte Daten in der Datenbank abzulegen.
    Dies wird vor allem dann wichtig, wenn ein Plugin Daten speichern muss, die später wieder abgerufen werden
    müssen. Alle Daten werden in der dafür vorgesehen wp_options Datenbank gespeichert.
  7. Plugin API
    Die wohl mächtigste aller APIs ist die Plugin-API. Sie erlaubt nahezu in jede von WordPress vorgegebene
    Funktion einzugreifen. Dies geschieht einerseits durch Filter oder aber durch Actions. Zusammen werden sie
    „Hooks“ genannt. „To hook into something“ bedeutet auf Deutsch in etwa: „in etwas einhaken“.
  8. Quicktags API
    Vielleicht kennen Sie ja bereits den Editor von WordPress, mit dem Sie ganz leicht Texte erstellen
    können. Er unterteilt sich in einen so genannten Rich-Text Editor (der Microsoft-Word-ähnliches bearbeiten
    erlaubt) und einen Quellcode-Editor (der den Quelltext hinter dem Rich-Text Editor anzeigt). Die Quicktags-API
    erlaubt es Ihnen, zusätzliche Buttons in den Quellcode-Editor zu integrieren.
    Abb. 1.5.c: Quicktags Editor von WordPress
  9. Rewrite API
    Bei der Benutzung von WordPress ist Ihnen sicherlich schon der Menüpunkt „Permalinks“ unter den
    Einstellungen aufgefallen. Dort haben Sie selbst die Möglichkeit, die URL-Struktur Ihres Blogs zu verändern.
    Diese Veränderungen in der Struktur der URLs nennt man „Rewrite Rules“. Die Rewrite-API erlaubt es Ihnen also,
    die URL zu verändern, indem neue Regeln hinzugefügt oder entfernt werden. So kann aus der URL http://meine-testseite.de?max=muster
    folgendes werden: http://meine-testseite.de/max/muster/.
  10. Settings API
    Die Settings API sollten Sie nicht mit der Options-API verwechseln. Dies geschieht sehr oft, da die
    Begriffe im Deutschen fast das gleiche bedeuten. Mit der Settings-API gibt WordPress Ihnen die Möglichkeit,
    ganze Einstellungs-Formulare zu erstellen, die Sie wiederum auf eigens dafür vorgesehenen Einstellungsseiten
    anzeigen lassen können. In der Regel benutzt man die Options- zusammen mit der Settings-API um Formulare zu
    erstellen und deren Inhalte in der Datenbank abzulegen.
    Abb. 1.5.d: Eingefelder werden durch die Settings API erstellt
  11. Shortcode API
    Die Shortcode API versammelt ein paar einfach zu benutzende Funktionen, um sogenannten Macro-Code im
    Texteditor verwenden zu können. Fügt man beispielsweise den Code [gallery] im Editor ein,
    generiert WordPress daraus einen HTML-Code, der eine Galerie erscheinen lässt. Nützlich ist das vor allem dann,
    wenn komplexer HTML-Code vom Benutzer selbst eingefügt werden soll, dieser den eigentlichen Code aber nicht
    kennt oder kennen soll.
    Abb. 1.5.e: Aus einem Shortcode im Editor (links) wird eine HTML-Galerie im Frontend (rechts).
  12. Theme Modification API
    Diese API enthält nützliche Hooks, die es den Themes erlauben, Daten zu speichern und zu verändern. Da
    es sich rein um Theme-Einstellungen handelt, soll diese API nur am Rande erwähnt werden.
  13. Theme Customization API
    Zugegeben: Die Auswahl der API-Namen ist nicht immer glücklich gewählt. Auch hier sind die Namen
    ähnlich, bedeuten aber nicht das gleiche. Im Gegensatz zur Theme Modification API (die rein zum
    Speichern von Daten gedacht ist) erlaubt es die Theme Customization API, die Oberfläche (z.B. zum
    Verändern der Farbgebung) im Administrationsbereich zu ergänzen.
    Abb. 1.5.f: Der rote Bereich zeigt en, die durch die Theme Customization API eingefügt wurden.
  14. Transient API
    „Transient“ bedeutet auf Deutsch „flüchtig“. Gemeint ist damit ein flüchtiger Speicher, der für eine
    bestimmte Zeitspanne vorgehalten wird. Zum Einsatz kommt die Transient API zum Beispiel dann, wenn Daten über
    die HTTP-API abgerufen werden. Meist wird davon ausgegangen, dass sich die abgerufenen Daten für eine gewisse
    Zeit nicht verändern. Die Transient API speichert den erhaltenen Rückgabewert zusammen mit einem Zeitstempel in
    der Datenbank, wo er zum Abruf bereit steht. Durch das Laden des bereits vorliegenden Ergebnisses des
    Transienten umgeht man den erneuten Aufruf der HTTP-API, da dieser mitunter sehr lange dauern kann. Läuft der
    Zeitstempel des Transienten ab, kann eine erneute Verbindung über die HTTP-API aufgebaut werden. Der Wert wird
    erneut zwischengespeichert und der Prozess beginnt von vorne.
    Abb. 1.5.g: Das Zwischenspeichern erspart einen erneuten Request
  15. Widgets API
    Wenn Sie schon längere Zeit mit WordPress arbeiten, kennen Sie sicherlich die Widget-Einstellungsseite.
    Per Drag & Drop lassen sich die Widgets in eine Seitenleiste ziehen. Die Widgets API erlaubt es Ihnen,
    eigene Widgets zu erstellen.
    Abb. 1.5.h: Widgets können per Drag&Drop zu einer Seitenleiste hinzugefügt werden.
  16. XML-RPC API
    Der Begriff steht für „Extensible Markup Language Remote Procedure Call“ und meint dadurch den
    Funktionsabruf von entfernter Stelle. Diese API ist also eher eine Art Schnittstelle, die dazu benutzt werden
    kann, Daten von der eigenen WordPress-Installation zu lesen oder zu schreiben. Ab Version 3.4 wurde es erstmals
    möglich, z.B. über die iPad-App neue Beiträge in den eigenen Blog hochzuladen, ohne die Website besuchen zu
    müssen.
  17. Pluggable Functions
    Auf Deutsch lässt sich der Begriff etwa so übersetzen: „überschreibbare Funktionen“. Diese Funktionen
    können – wie der Name schon sagt – komplett überschrieben werden, indem man sie im eigenen Plugin neu definiert.
    Seit geraumer Zeit werden keine neuen überschreibbaren Funktionen mehr zu WordPress selbst hinzugefügt. Sie
    haben nämlich einen gravierenden Nachteil: Überschreiben zwei voneinander unabhängige Plugins die gleiche
    Funktion, wird ein fataler Fehler von PHP ausgegeben und WordPress kann nicht mehr ausgeführt werden. Zwar lässt
    sich das programmiertechnisch umgehen, aber man setzt notgedrungen eines der beiden Plugins außer Gefecht.
    Mittlerweile erlauben Filter und Hooks ebenfalls den Eingriff in die Funktionen, ohne sie direkt überschreiben
    zu müssen. Sie sollten deshalb die „Pluggable Functions“ nur im äußersten Notfall überschreiben.
  18. REST-API (Representational State Transfer)
    Seit Version 4.4 sind die REST-API und seit Version 4.7 auch die so genannten Content-Entpoints im Kern
    integriert. Somit können Entwickler mit dem System von außen über das JSON-Format interagieren. Beispielsweise
    lassen sich Inhalte erstellen, lesen und überschreiben. Und zwar über Client-Seitiges Javascript oder aus
    anderen, externen Anwendungen. JSON ist im übrigen ein offenes Datenformat, standardisiert und von Menschen
    (relativ) gut lesbar.

Wie Sie sehen, bietet WordPress bereits eine große Zahl von Funktionen, Klassen und Methoden, die Sie fast sorglos benutzen können.

1.6. Wann Plugins geladen werden

Die Reihenfolge sieht in etwa so aus (gekürzt):

  1. Aufruf einer Seite (z.B. Startseite, index.php).
  2. Das eigentliche Bootstrapping (Starten von WordPress) beginnt.
  3. Die Umgebungs- und Konfigurations-Variablen werden geladen (wp-config.php).
  4. Alle Funktionen werden geladen (wp-settings.php).
  5. Die Datenbankverbindung wird aufgebaut.
  6. Der Object-Cache wird gestartet.
  7. MU (Must-Use) Plugins werden geladen und Teile davon eventuell ausgeführt.
  8. Netzwerkweite Plugins werden geladen und Teile eventuell ausgeführt.
  9. Plugins werden geladen und Teile davon eventuell ausgeführt.
  10. Die Übersetzungsdateien werden geladen.
  11. Das Theme wird geladen.
  12. Der Inhalt wird geladen.

Wie Sie sehen, werden Plugins in einem sehr frühen Stadium eingehängt. Sie können also schon in der Startphase nützlich eingreifen.

1.7. Wie man Plugins installiert und aktiviert

Alle Plugins lassen sich ganz bequem im Menüpunkt „Plugins“ verwalten. Ob Sie diesen Menüpunkt sehen können, hängt von einigen Punkten ab:

  1. Zu allererst müssen Sie eingeloggt sein und den Administrationsbereich aufrufen.
  2. Sie benötigen Administrationsrechte.
  3. Im Falle einer Multisite-Installation sehen Sie nur eine ausgewählte Liste von Plugins. Sie können neue Plugins
    nur dann installieren, wenn Sie sich im Administrationsbereich des Netzwerks befinden.

Zur Installation gibt es mehrere Möglichkeiten:

Abb. 1.7.: Plugins lassen sich suche oder hochladen
Abb. 1.7.: Plugins lassen sich suche oder hochladen
  1. Sie suchen nach einem Plugin über die WordPress-Oberfläche und installieren es direkt von dort. Es wird das
    WordPress.org Plugin-Archiv durchsucht.
  2. Sie laden ein Plugin direkt über das Upload-Formular hoch. Das funktioniert jedoch nur, wenn der Webserver dies
    unterstützt. Darüber hinaus muss sich das Plugin innerhalb eines ZIP-Archivs befinden.
  3. Sie greifen über FTP auf den Ordner wp-contents/plugins/ zu und kopieren dort die neuen
    (unkomprimierten) Plugin-Dateien hinein.

Egal welchen Weg Sie gewählt haben, in jedem Fall wird das neu hochgeladene Plugin dann im Menüpunkt „Plugins“ angezeigt und steht zur Aktivierung bereit. Sie haben dann die Möglichkeit, das Plugin zu aktivieren, zu deaktivieren, zu löschen, zu aktualisieren oder zu bearbeiten.

Abb. 1.7.b: Plugins aktivieren/deaktivieren/löschen
Abb. 1.7.b: Plugins aktivieren/deaktivieren/löschen

1.8. Plugins mit dem Editor bearbeiten

WordPress bietet seit geraumer Zeit auch die Möglichkeit, die Dateien eines Plugins direkt über die Weboberfläche zu bearbeiten. Dazu klicken Sie im Menü auf „Plugins“ und anschließend auf „Editor“. Sie können dann das gewünschte Plugin sowie die zu bearbeitende Datei auswählen.

Abb. 1.8.: Der Plugin-Editor. Er sollte aus Sicherheitsgründen deaktiviert werden.
Abb. 1.8.: Der Plugin-Editor. Er sollte aus Sicherheitsgründen deaktiviert werden.

Ich rate allerdings von diesem Vorgehen ab. Und zwar aus mehreren Gründen:

  • Zum einen bietet der Editor keine Syntax-Hervorhebung (engl. auch „syntax highlighting“).
  • Zum anderen gibt es keinen „Rückgängig“-Button. Speichern Sie Ihre Änderungen ab, sind z.B. versehentlich
    gelöschte Zeilen unwiderruflich verloren.
  • Wenn sich ungewollt Fehler einschleichen, kann das dazu führen, dass die komplette Website nicht mehr erreichbar
    ist. Sie müssen die Plugin-Datei oder den Plugin-Ordner dann via FTP umbenennen, damit WordPress es automatisch
    deaktiviert.

Darüber hinaus benötigt der Webserver-Benutzer Schreibrechte auf die einzelnen Dateien, damit Änderungen überhaupt abgespeichert werden können. Ist dies nicht der Fall, können Sie sich lediglich den Quelltext ansehen.

Tipp
Ich empfehle nachfolgende Codezeile in die Datei wp-config.php aufzunehmen, um den Editor aus dem Menü
komplett verschwinden zu lassen. So hat eine dritte Person, die sich vielleicht unrechtmäßig Zugang zu Ihrer
Administrationsoberfläche verschafft hat, keine Möglichkeit, Daten von Plugins zu bearbeiten oder einzusehen.

<?php
define( 'DISALLOW_FILE_EDIT', true );
?>

1.9. Plugin-Typen

WordPress bietet nicht nur die Installation von „normalen“ Plugins, es ermöglicht auch das Einbinden anderer Plugin-Arten. Diese wären:

  • Must-Use Plugins
    Must-Use oder kurz MU-Plugins sind Pflicht-Plugins und befinden sich im Verzeichnis wp-content/mu-plugins/.
    Sie werden immer ausgeführt und können nicht über die Administrationsoberfläche deaktiviert
    werden. Die einzige Möglichkeit, sie zu deaktivieren besteht darin, die Dateien aus dem eben angesprochenen
    Verzeichnis zu löschen.Das mu-plugins-Verzeichnis wird übrigens nicht automatisch angelegt. Sie
    können es aber manuell erstellen, wenn Sie es benötigen.
    Beachten Sie, dass MU-Plugins in Unterordnern nicht erkannt werden. Installieren Sie z.B. ein Plugin unter
    wp-content/mu-plugins/mein-plugin/mein-plugin.php wird es nicht erkannt. Sie können natürlich
    jederzeit weitere Unterordner erstellen. Jedoch muss die initiale Datei unter wp-content/mu-plugins/mein-plugin.php
    liegen.
  • Drop-In Plugins
    Wie schon weiter oben erwähnt erlaubt es WordPress, bestimmte Funktionen komplett zu überschreiben.
    Gemeint sind hier nicht die „Pluggable Functions“, wohl aber andere Bereiche, die man austauschen möchte. So ist
    es beispielsweise möglich, die PHP-Klasse für den Datenbankzugriff auszutauschen, um WordPress dazu zu zwingen,
    eine alternative Datenbankart zu benutzen.
    Hier die einzelnen Möglichkeiten von Drop-In-Plugins:

    • advanced-cache.php
      Erweiterter oder Alternativer Cache.
    • db.php
      Definition einer eigenen Datenbank-Klasse.
    • db-error.php
      Eigene Datenbankfehlermeldungen.
    • install.php
      Wird zusätzlich ausgeführt, wenn die WordPress-Installations-Routine ausgeführt wird.
    • maintenance.php
      Wird ausgeführt wenn sich WordPress im Wartungsmodus befindet (z.B. bei Updates).
    • object-cache.php
      Integration eines eigenen, externen Object-Caches (z.B. Redis oder Memcached).
    • sunrise.php
      Wird unter anderem für das Domain-Mapping benötigt (nur bei einer WordPress-Multisite-Installation unter
      der Verwendung mehrerer unterschiedlicher Domains).
    • blog-deleted.php
      Wird ausgeführt, wenn ein Blog gelöscht wird (nur bei einer WordPress-Multisite-Installation).
    • blog-inactive.php
      Wird ausgeführt, wenn der Blog inaktiv ist (nur bei einer WordPress-Multisite-Installation).
    • blog-suspended.php
      Wird ausgeführt, wenn ein Blog eingestellt wurde (nur bei einer WordPress-Multisite-Installation).

2. Kapitel 2: Ein Leitfaden zur Plugin-Entwicklung

Bevor man starten kann, müssen einige Dinge geklärt werden. Ansonsten stoßen Sie später auf Probleme, die sich im Zweifelsfall nur kompliziert ausmerzen lassen. Geklärt werden muss, welchen Namen das Plugin erhalten soll, welche Dateien enthalten sind und dadurch natürlich auch, welche Struktur die beste ist. Beginnen wir mit dem Namen.

2.1. Eine Plugin-Datei erstellen

Ein einfaches WordPress-Plugin kann bereits aus einer einzigen Datei bestehen. Erstellen Sie die Datei mein-plugin.php und kopieren Sie sie in das Unterverzeichnis
/wp-content/plugins/ Ihrer WordPress Installation.

<?php
/*
Plugin Name: Mein erstes Plugin
Plugin URI: http://beispiel.de/plugins/mein-plugin
Description: Dies ist mein erstes WordPress Plugin
Version: 1.0
Author: Max Mustermann
Author URI: http://beispiel.de
License: GPLv2
*/
?>

Auf Github ansehen

Ihr WordPress-Plugin taucht jetzt bereits in der Liste der Plugins auf.

Abb. 2.1: Mein erstes WordPress Plugin
Abb. 2.1: Mein erstes WordPress Plugin

Wie Sie sehen, werden automatisiert bereits zwei Links erstellt. Einmal der Link auf Ihren Namen (hier: Max Mustermann) und zum zweiten der Link „Besuch die Plugin-Seite“ mit dem Link, der in der PHP-Datei als „Plugin URI“ definiert wurde. Es gibt die Möglichkeit, hier noch weitere Links hinzuzufügen. Dazu aber später mehr.

Sie können das Plugin bereits aktivieren und deaktivieren. Es wird nur nichts passieren, da noch kein Code hinterlegt wurde.

Da ein Plugin meistens aus mehreren Dateien besteht, sollten Sie darüber nachdenken, das Plugin eher in ein Unterverzeichnis zu packen. In unserem Beispiel wäre also folgender Pfad zur Datei sinnvoll und sogar empfohlen:
/wp-content/plugins/mein-plugin/mein-plugin.php.

Die meisten Plugin-Entwickler haben es sich angewöhnt, das Verzeichnis so zu benennen, wie die Hauptdatei. Sie sollten sich an den de-facto Standard halten und genauso verfahren.

2.2. Der richtige Plugin-Name

Viel wichtiger ist der Name des Plugins. In der Praxis hat es sich als nützlich erwiesen, das Plugin so zu benennen, dass man schnell erkennen kann, was es tut. Hier einige Beispiele:

  • Redirect if not logged in
    Erlaubt das automatisierte Weiterleiten, wenn ein Benutzer aktuell nicht eingeloggt ist.
  • Purple Heart Rating
    Erlaubt das Bewerten von Blogartikeln (Rating).
  • WP-Super Cache
    Ein Cache-Plugin. Erlaubt es, WordPress Seiten als HTML-Seiten zu hinterlegen, damit diese beim
    nächsten Seitenaufruf schneller geladen werden (caching).

Wohingegen folgende Plugin-Namen nicht so eindeutig sind:

  • Locus
  • Kalooga
  • Beeline

Hätten Sie gewusst, dass „Locus“ dafür benutzt werden kann, einzelne Artikel in einem Widget aufzulisten? Die Problematik ist, dass viele Entwickler dazu tendieren, coole Namen zu vergeben. Leider ist das Auffinden solcher Plugins später sehr schwierig.

Die beste Möglichkeit ist, das Plugin-Verzeichnis von WordPress nach ähnlichen Plugins zu durchsuchen, um eine Idee für einen Plugin-Namen zu bekommen. Stellen Sie sich selbst immer eine Frage:
Was würden Sie selbst in eine Suche eingeben, damit Ihr Plugin gefunden werden kann?

Ihr Plugin-Name sollte darüber hinaus einzigartig sein. Sie bekommen später sonst Schwierigkeiten, wenn ein anderes Plugin den gleichen Namen benutzt. So ist es zum Beispiel nicht möglich, ein Plugin mit gleichem Namen im offiziellen WordPress-Plugin-Verzeichnis hochzuladen.

Planen Sie ein Wetter-Plugin, sollte das Wort „Wetter“ oder der englische Pendant „weather“ im Namen enthalten sein. Ein guter Name wäre zum Beispiel „Wetterstation für WP“. Zusätzlich haben Sie dann auch gleich den passenden Namen für Ihren Plugin-Ordner sowie der Plugin-Datei:
/wp-content/plugins/wp-wetterstation/wp-wetterstation.php.

Folgendes hat sich bewährt:

  • Benutzen Sie weder im Verzeichnis- noch im Dateinamen Umlaute, Leerzeichen oder sonstige Sonderzeichen.
  • Wechseln Sie nicht zwischen Groß- und Kleinschreibung. Schreiben Sie immer alle Datei- und Verzeichnisnamen
    klein.
  • Trennen Sie einzelne Wörter nicht mit einem Unter-, sondern lieber mit einem Bindestrich (siehe Beispiel
    oben).

2.3. Der Kopfbereich

Die einzige Voraussetzung einer Plugin-Datei ist der Kopfbereich (engl. „Header“), der durch einen PHP-Kommentarblock gekennzeichnet wird und einige Infos über das Plugin selbst enthalten muss. Diese Informationen werden „Metadaten“ genannt und werden später über die File-Metadata-API abgerufen. Wie weiter oben bereits angedeutet, lässt sich das Plugin dann schon aktivieren bzw. deaktivieren.

<?php
/*
	Plugin Name: Mein erstes Plugin
*/
?>

Auf Github ansehen

Lediglich der Plugin-Name ist ein Muss. Alle anderen Felder sind optional, sollten aber, falls möglich, dennoch ausgefüllt werden.

Möglich sind folgende Werte, wobei die Anordnung keine Rolle spielt:

  • Plugin Name
  • Plugin URI
    Ein Link auf die Plugin-Seite. In den meisten Fällen ist das ein Link auf die Plugin-Seite bei
    wordpress.org. Wenn Sie das Plugin nicht kostenlos in der Datenbank bei WordPress anbieten, kann dies natürlich
    auch jede andere Webseite-URL sein.
  • Description
    Eine Kurzbeschreibung des Plugins in etwa einem Satz.
  • Version
    Die aktuelle Versionsnummer des Plugins. WordPress nutzt diesen Wert, um ihn mit der Version in der
    WordPress-Plugin-Datenbank abzugleichen. Ist der Wert kleiner als der im Verzeichnis vorhandene, bietet
    WordPress ein Update an.
  • Author
    Der Name des oder der Plugin-Autoren (ggf. durch Komma getrennt).
  • Author URI
    Ein Link auf eine persönliche Webseite des Autors. Manchmal wird auch nur auf den Twitter-Account oder
    ähnliche Profile im Web verlinkt. Der Link wird dann mit dem Namen des Autors auf der Plugin-Seite im WordPress
    Administrationsbereich angezeigt (siehe Abb. 2.1.).
  • License
    Die Kurzform eines Plugin-Lizenzvertrags und dessen Versionsnummer (z.B. GPLv2).
  • Domain Path
    Hier kann der Pfad zur Textdomain angegeben werden. Dieser Wert ist ebenfalls optional und muss nur dann
    angegeben werden, wenn sich die Sprachdateien (Erkennbar an der Endung *.mo) in einem anderen Pfad
    befinden. Geben Sie beispielsweise /translations/ als Wert an, wird im Plugin-Unterverzeichnis
    /translations nach den Dateien gesucht. Wird der Wert nicht angegeben, so wird WordPress ihn
    automatisch auf den Pfad des Plugin-Verzeichnisses setzen.
  • Network
    Dies ist eine Einstellung, die die Multisite-Funktion von WordPress betrifft. Definieren Sie Network:
    true
    , so lässt sich das Plugin nur netzwerkweit aktivieren.
  • Text Domain
    Ein einzigartiger Bezeichner, der für Übersetzungen benutzt wird. WordPress baut aus diesem Bezeichner den
    Dateienamen der Übersetzungsdatei zusammen. Ich empfehle, den Dateinamen dazu zu benutzen. Befindet sich Ihr
    Plugin also beispielsweise unter /wp-content/plugins/wp-wetterstation/wp-wetterstation.php, so
    könnten Sie wp-wetterstation als Text Domain nutzen. Mit diesem Bezeichnet sucht WordPress nun im
    Pfad, der in Domain Path angegeben wurde, nach der Datei wp-wetterstation-[de_DE].mo.
    Wobei [de_DE] mit dem jeweils eingestellten Sprachcode ersetzt wird.

2.4. Lizenzverträge

Wie in jeder PHP-Datei besteht auch die Möglichkeit, mehrere Kommentarblöcke einzubinden. Daher empfiehlt es sich, dort auch gleich den Lizenztext anzugeben. Das hat den Vorteil, dass der Anwender sofort sehen kann, was er mit dem Plugin machen darf und was nicht.

WordPress selbst unterliegt der GNU General Public License (kurz GPL). Damit ist es den Endnutzern (Privatpersonen, Organisationen sowie Firmen) gestattet, die Software zu nutzen, zu studieren, zu verbreiten (also zu kopieren) und zu verändern.
3

Das wiederum bedeutet, dass Sie eine Lizenz wählen sollten, die sich mit der GPL vereinbaren lässt.

Als Beispiel hier die GPLv2:

<?php
/*
Copyright (C) [Jahreszahl] [Name des Autors / der Autoren] (E-Mail: [E-Mail Adresse(n)])

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

*/
?>

Auf Github ansehen

2.5. Coding Standards

Die sogenannten Coding-Standards sorgen dafür, dass der Quellcode jeder einzelner Datei von WordPress gleichbleibend ist. Als Programmierer kennen Sie den Missstand vielleicht: Jeder Entwickler hat seinen eigenen Programmierstil. Das wiederum bedeutet, dass nicht jeder Ihren Code ohne weiteres lesen kann.

Um den Code von WordPress zu vereinheitlichen, wurden die Coding-Standards geschaffen. Das soll die Qualität, insbesondere aber die Verständlichkeit und die Wartbarkeit erhöhen.

Im sogenannten Core Contributor
Handbook
sind alle Coding Standards zusammengefasst. Sie existieren nämlich nicht nur für PHP, sondern auch für HTML-, CSS- und JavaScript.

https://make.wordpress.org/core/handbook/best-practices/coding-standards/

Sich an die Coding-Standards zu halten, ist kein Muss. Ich habe schon Plugins eingereicht, die sich nicht daran gehalten haben. Und sie wurden immer ohne Wenn und Aber angenommen. Trotzdem: Guten und vor allem einheitlichen Code zu schreiben, hilft nicht nur Ihnen selbst, sondern auch der Community rund um WordPress. Der Vorteil ist, dass jeder von jedem lernen kann. Noch besser aber ist, dass jeder den Quellcode schnell lesen kann. Ob man ihn dann versteht ist natürlich eine andere Sache. Dafür sind dann Kommentare gut. Vorausgesetzt man versteht sie. Falls sie überhaupt vorhanden sind, gibt es auch für Kommentare – interessanterweise – eigene Regeln. Dazu gehört zum Beispiel die richtige Kommasetzung.

Natürlich möchte ich hier keinen Englisch-Unterricht anzetteln, deswegen stelle ich nur die gängigsten PHP-Standards kurz vor. Im nächsten Kapitel geht es dann allein um die Dokumentationen.

2.5.1. Einfache und doppelte Anführungszeichen

PHP erlaubt es Ihnen, Strings mit doppelten oder einfachen Anführungszeichen zu definieren. Das oben genannte Handbuch empfiehlt die Nutzung von einfachen Anführungszeichen, falls möglich. Im Grunde ersparen Sie sich das Escapen aller doppelten Anführungszeichen in einem etwaigen HTML Code. Dadurch wird der Quelltext einfacher zu lesen. Einen gigantischen Geschwindigkeitsvorteil haben Sie dadurch allerdings nicht.
4

Erklärung:
„Escaping“ bedeutet, dass besondere Zeichen in PHP – meist mit einem Backslash (\)- maskiert werden, da
sie sonst fehlerhaft interpretiert werden würden (siehe Beispiel B2 unten).

<?php
$url = 'http://beispiel.de';

// B1: Nicht empfohlen:
echo "<a href='$url'>Dies ist eine URL</a>";

// B2: Nicht empfohlen
echo "<a href=\"$url\">Dies ist eine URL</a>";

// B2: Empfohlen:
echo '<a href="'. $url .'">Dies ist eine URL</a>';

?>

Auf Github ansehen

2.5.2. Einrückung

Richtige Tabulatorsprünge sind hier gefragt. Keine Leerzeichen. Viele Programme lassen sich über das Menü so einstellen. Eine Ausnahme gibt es da nur bei solchem Code, der durch Leerzeichen lesbarer wird.

<?php

// Nicht empfohlen
$mein_array = array(
	'foo'  => 'wert1',
	'foo12' => 'wert2',
	'foo34' => 'wert3',
	'foo567' => 'wert4',
);

// Empfohlen:
$mein_array = array(
	'foo'    => 'wert1',
	'foo12'  => 'wert2',
	'foo34'  => 'wert3',
	'foo567' => 'wert4',
);
?>

Auf Github ansehen

2.5.3. Klammern

Auch die Klammern müssen angesprochen werden. Gerade sie werden von fast jedem Programmierer anders benutzt. Hier also die von WordPress vorgegebenen Regeln:

  • Klammern sollten immer in der gleichen Zeile wie die Anweisung selbst stehen.
  • Bei langen Blöcken sollte am Ende immer ein Kommentar auf das Ende hinweisen.
  • Ultralange If-Else Blöcke sollten in eigene Funktionen ausgelagert werden.

Ein Beispiel:

<?php
// Nicht empfohlen:
if( $c1 )
{
	action1();
}
elseif( $c2 )
{
	action2();
}
elseif( $c3 )
{
	action3();
}
else
{
	action4();
}

// Empfohlen:
if ( $c1 ){
	action1();
} elseif ( $c2 ) {
	action2();
} elseif ( $c3 ) {
	action3();
} else {
	action4();
} // End of condition check
?>

Auf Github ansehen

2.5.4. Leerzeichen

Leerzeichen sollten immer nach Kommas und auf beiden Seiten von logischen Operationen stehen. Außerdem sollten Leerzeichen am Ende jeder Zeile entfernt werden.

<?php
// Nicht empfohlen
if($c1){
	action(true);
}

// Empfohlen
if ( $c1 ) {
	action( true );
}
?>

Auf Github ansehen

Weitere Beispiele, wie Leerzeichen benutzt werden sollen, finden Sie unter https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#space-usage.

2.5.5. Formatierung von SQL-Anweisungen

SQL-Anweisungen können schon manchmal sehr lang und dadurch unübersichtlich werden. Aus diesem Grund empfiehlt WordPress folgende Regeln:

  • Lange Zeilen sollten auf mehrere kürzere Zeilen umgebrochen werden.
  • Die „ausführenden“ Teile einer SQL-Anweisung sollten immer groß geschrieben werden. Zum Beispiel eine UPDATE
    oder SELECT Anweisung.
  • Der Sicherheit wegen sollten Variablen immer escaped werden. Das gelingt am besten mit der $wpdb->prepare()
    Funktion. Darüber hinaus übernimmt die Funktion die Quotierung und das Type-Casting für SQL-Anfragen.

Beispiel aus dem offiziellen Handbuch:

<?php
global $wpdb;

// Das einzelne Anführungszeichen am Ende sorgt für Probleme bei der SQL-Abfrage
$var = "dangerous'";

// Diese Funktion sollte einen Integer-Wert zurückgeben.
$id = some_foo_number();

$wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id ) );
?>

Auf Github ansehen

Zur Erklärung: %s wird als String-,
%d hingegen für Integer-Platzhalter benutzt. Die Werte selbst müssen nicht separat mit Anführungsstrichen versehen werden. Die
prepare() Funktion übernimmt dies automatisch.

Alternativ kann die Funktion
esc_sql() genutzt werden. Sie muss aber für jede Variable in der SQL-Abfrage einzeln aufgerufen werden und ist daher eher unpraktisch für Anfragen, die mehrere Variablen enthalten:

<?php
$name   = esc_sql( $name );
$status = esc_sql( $status );

$wpdb->get_var( "SELECT etwas FROM tablenname WHERE foo = '$name' and status = '$status'" );
?>

Auf Github ansehen

2.5.6. Datenbank-Abfragen

Man sollte es tunlichst vermeiden, die Datenbank von WordPress manuell abzufragen. Die Nutzung vorhandener WordPress-Methoden (in der globalen Variable
$wpdb) sorgt dafür, dass Ihre Plugins auch mit zukünftigen Versionen kompatibel bleiben, ohne dass Sie sie verändern müssen.

2.5.7. Reguläre Ausdrücke

Zur Vereinheitlichung sollten nur die zu Perl kompatiblen regulären Ausdrücke (PCRE) Anwendung finden. Das bedeutet, dass nur die
preg_* Funktionen von PHP benutzt werden sollten. Seit 5.3.0 sind die POSIX Regex-Funktionen (
ereg_*) ohnehin als veraltet markiert und geben bei Verwendung eine Warnung aus.5

Des Weiteren soll der Suchmuster-Modifikator
/e nicht verwendet werden (dieser ist ab PHP 5.5.0 ebenfalls als veraltet markiert 6).

2.5.8. PHP-Öffnungs-Tags

Verwenden Sie immer <?php sowie ?> und nicht etwa die Kurzform davon (
<? bzw.
?>). Dieser sogenannte Short-Tag ist nicht unbedingt bei jedem Webhoster aktiviert, was wiederum zu Problemen führen kann.

Tabu sind überdies natürlich auch die PHP-ASP Tags <% und
%>. Sie wurden ab Version 7.0.0 von PHP entfernt und stehen nicht mehr zur Verfügung.

// Nicht empfohlen:
<% ... %>
<? ... ?>
<?= $var ?>

// Empfohlen
<?php ... ?>
<?php echo $var; ?>

2.5.9. Namenskonvention

Hier trennt sich erneut die Spreu vom Weizen, denn WordPress empfiehlt, alle Variablen und Funktionen klein zu schreiben. Dies steht im Gegensatz zu vielen PHP-Büchern, die genau das Gegenteil fordern: den sogenannten camelCase-Style.

<?php
// Nicht empfohlen:
function einSchoenerName( $eineVariable ) { ... }

// Empfohlen:
function ein_schoener_name( $eine_variable ) { ... }
?>

Einzig die Klassen-Bezeichnungen stellen eine Ausnahme dar. Hier sind Großbuchstaben ausdrücklich erlaubt. Allerdings müssen Wörter auch mit einem Unterstrich voneinander getrennt werden.

<?php
// Nicht Empfohlen:
class WalkerCategory extends Walker { ... }
class walker_category extends Walker { ... }
class walker_Category extends Walker { ... }

// Empfohlen:
class Walker_Category extends Walker { ... }
?>

Dateinamen sollten ebenso immer klein geschrieben werden. Einzelne Wörter werden mit Bindestrichen voneinander getrennt:

// Nicht empfohlen:
meinErstesPlugin.php
mein_erstes_plugin.php

// Empfohlen:
mein-erstes-plugin.php

Für Klassen gibt es wiederum eigene Regeln für die Dateinamen:

// Nicht empfohlen:
mein-klassenname.php
class.mein-klassenname.php

//Empfohlen:
class-mein-klassenname.php

Das vorangestellte
class- kann jedoch entfallen, wenn sich die Klassen-Dateien in einem separaten Unterordner befindet:

/classes/mein-klassenname.php

2.5.10. Selbsterklärender Code

true und
false erlauben es uns, zwischen zwei verschiedenen Zuständen einfach zu unterscheiden. Trotzdem sind sie nicht immer von Vorteil. Gerade, wenn sie sich in der Parameterliste von Funktionen befinden.

<?php
// Nicht empfohlen:
function fahren( $fahrzeugart, $schnell = true ){ ... }

...

fahren( 'Pkw' );
fahren( 'Pkw', true );
fahren( 'Pkw', false )
?>

Im obigen Beispiel wird jedem schnell bewusst, dass man eigentlich nicht weiß, was true oder
false im Funktionsaufruf bedeutet. Stattdessen wäre folgender Ansatz lesenswerter:

<?php
// Empfohlen:
function fahren( $fahrzeugart, $geschwindigkeit = 'schnell' ){ ... }

...

fahren( 'Pkw' );
fahren( 'Pkw', 'schnell' );
fahren( 'Pkw', 'langsam' )
?>

Alternativ könnte man auch Arrays nutzen:

<?php
// Empfohlen:
function fahren( $fahrzeugart, $options = array() ){ ... }

...

fahren( 'Pkw' );
fahren( 'Pkw', array(
	'geschwindigkeit' => 'schnell',
) );

fahren( 'Pkw', array(
	'geschwindigkeit' => 'langsam',
) );
?>

2.5.11. Ternärer Operator

Der ternäre Operator ist ein ideales Werkzeug, um
if/else Anweisungen auf eine Zeile zu verkürzen. Auf der anderen Seite kann es manchmal ein bisschen zu kompliziert werden. Man sollte immer überlegen, ob der eigene Code durch kurze Zeilen lesbar bleibt oder nicht. Im Zweifel sollte man
if/else-Blöcke lieber komplett ausschreiben.

Zudem ist eine Überprüfung auf true meist besser als eine Überprüfung auf false.

<?php
// Nicht empfohlen: Überprüfung auf false
$existiert = ( ! empty( $wert ) ) ? true : false;

// Empfohlen: Überprüfung auf true
$existiert = ( empty( $wert ) ) ? false : true;
?>

Davon abgesehen, dass es natürlich auch noch einfacher geht:

<?php
$existiert = ! empty( $wert );
?>

Ab PHP 7 gibt es auch den so genannten Null Coalesce Operator:

Anstatt:

<?php
$title = isset( $field['title'] ) ? $field['title'] : 'alternative';
?>

Lässt sich nun auch folgendes schreiben:

<?php
$title = $field['title'] ?? 'alternative';
?>

2.5.12. Yoda-Bedingungen

Klingt komisch, stimmt aber: Die Bedingungen nach „Yoda“ haben tatsächlich etwas mit DEM Yoda aus der Star-Wars-Filmreihe zu tun.

<?php
// Nicht empfohlen
if ( $himmel == 'blau' ) eine_funktion();

// Empfohlen
if ( 'blau' == $himmel ) eine_funktion();
?>

Haben Sie es durchschaut? Die empfohlene Überprüfung spricht sich so: „Wenn blau Himmel, dann
…“
. Also in etwa so, wie Meister Yoda spricht. Zuerst klingt das natürlich etwas witzig und man fragt sich, warum man das so macht. Das Ganze hat aber einen sehr guten Hintergrund: Vergisst man nämlich einmal ein Istgleich-Zeichen bei einer if-Bedingung, wird in der
nicht empfohlenen Schreibweise der Variablen $himmel der Wert blau zugewiesen:

<?php
// Ein Istgleich-Zeichen wurde vergessen. $himmel wird 'blau' zugewiesen.
if ( $himmel = 'blau' ) eine_funktion();
?>

Das Problem dabei ist, dass die if-Abfrage (meist unbeabsichtigt) immer true ergibt, die Funktion eine_funktion() also immer ausgeführt wird. Der Code gibt also keinen Fehler zurück und funktioniert einwandfrei, während hingegen der Yoda-Style einen PHP-Parse-Error erzeugen würde:

<?php
// Empfohlen: Hier wird das Script gestoppt
if ( 'blau' = $himmel ) eine_funktion();
?>

Weitere nützliche Code-Stile finden Sie z.B. hier: http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html. Sie sind aber nicht Bestandteil des Core Contributor Handbuchs von WordPress und sind daher nur am Rande erwähnt.

2.6. Dokumentations-Standards

Nicht nur beim Code, sondern auch bei der Dokumentation gibt WordPress im Handbuch einige Regeln vor. Plugin-Entwicklern wird nahegelegt, sich daran zu halten, da auf diese Weise nicht nur einem selbst, sondern auch anderen Programmierern geholfen wird, sich schnell zurecht zu finden.

Im Grunde orientiert sich das WordPress Dokumentations-Schema direkt an dem von PHPDoc (http://www.phpdoc.org). Während das Core Contributor Handbuch von WordPress jedoch nur Ergänzungen oder Abänderungen bespricht, findet man bei Github weitere Empfehlungen und Vorschläge zur Dokumentation der eigenen PHP-Scripte:
https://github.com/phpDocumentor/fig-standards/blob/master/proposed/phpdoc.md.

2.6.1. Tipps zur Dokumentation

  1. Es sollte zu jeder Zeit klar sein, was eine Funktion macht, wann sie ausgeführt wird und warum.
    Dies gilt natürlich auch für WordPress Actions sowie Filter, die wir später besprechen werden.
  2. Weiter wird empfohlen, das @since-Tag zu benutzen. Es gibt an, ab welcher Version eine Klasse, eine
    Funktion oder eine Datei im eigenen Plugin existiert. Das hilft übrigens später ungemein, wenn Sie für Ihre
    eigenen Plugins Support leisten müssen.
  3. Benutzen Sie das Minuszeichen (-) um Aufzählungen zu generieren.
  4. Wenn Sie Codebeispiele angeben möchten, rücken Sie jede Code-Zeile mit jeweils 4 Leerzeichen ein. Vor und nach
    dem Code-Block muss sich eine Leerzeile befinden.

2.6.2. Funktionen und Methoden

Der Dokumentationsblock von Funktionen und Klassen sollte wie folgt aussehen:

  • Zusammenfassung
    Ein Einzeiler der beschreibt, was die Funktion/Klasse tut. Der Satz muss mit einem Punkt enden und darf
    keine HTML-Codes enthalten.
  • Beschreibung
    Eine ausführliche Beschreibung der Funktion, Methode, Klasse. Endet ebenfalls mit einem Punkt und darf
    – außerhalb von Codebeispielen – keine HTML-Tags enthalten.
  • @since
    Gibt die Versionsnummer mit einer optionalen Beschreibung an. Sie sollte dreistellig sein. Mehrere
    @since-Blöcke sollte es geben, sobald signifikante Änderungen durchgeführt wurden.
  • @access
    Soll nur bei Methoden in Klassen benutzt werden. Und auch nur dann, wenn die Methode als
    private markiert ist.
  • @see
    Beschreibt eine Funktion, eine Methode oder eine Klasse, auf die aufgebaut oder verweisen wird.
    Alternativ kann hier auch eine URL eingegeben oder auf einen Cook verweisen werden ({@see
    'save_post}
    .
  • @deprecated
    Bedeutet „veraltet“ und wird nur angegeben, wenn die Klasse, die Funktion oder die Methode nicht mehr
    verwendet werden soll. Dahinter wird die dreistellige Versionsnummer angegeben, ab welcher Version sie als
    veraltet markiert wurde. Zum Schluss ist noch eine kurze Beschreibung sinnvoll, die angibt, welche Funktion
    stattdessen Verwendung finden soll.
  • @link
    Wurde früher für das Setzen von Links benutzt. Dies ist in PHPDoc jedoch mittlerweile veraltet. Man
    sollte stattdessen das @see verwenden, welches ebenfalls auf URLs verweisen kann.
  • @global
    Listet alle globalen Variablen auf, die innerhalb der Funktion bzw. der Methode zur Anwendung kommen.

Code-Schnipsel:

<?php
/**
 * Zusammenfassung
 *
 * Beschreibung.
 *
 * @since x.x.x
 * @since x.x.x Änderung Y.
 * @deprecated x.x.x Benutze stattdessen neuer_funktionsname().
 * @access (für Methoden nur wenn als privat markiert)
 *
 * @see Function/method/class relied on
 * @global Typ $var Kurzbeschreibung.
 *
 * @param  Typ $var Beschreibung.
 * @param  Typ $var Optional. Beschreibung.
 *
 * @return Typ Beschreibung.
 */
 ?>

Beispiel

<?php
/**
 * Lässt das Fahrzeug fahren.
 *
 * Legt den ersten Gang des Fahrzeugs ein und beschleunigt.
 *
 * @since 1.0.3
 *
 * @see   Fahrzeug::fahren()
 *
 * @param object $fahrzeug Eine Klasse des Typs Fahrzeug.
 * @param int    $gang Optional. Der Gang der eingelegt werden soll.
 *
 * @return float Geschwindigkeit
 */
function fahren( $fahrzeug, $gang = 1 ) {

	$fahrzeug->gang_einlegen( $gang );

	return $fahrzeug->geschwindigkeit();
}

?>

Auf Github ansehen

2.6.3. Klassen

Klassen-Eigenschaften sollten wie folgt deklariert werden:

  • ZusammenfassungDer Satz sollte mit einem Punkt enden.
  • @sinceGibt die Versionsnummer mit einer optionalen Beschreibung an. Sie sollte dreistellig
    sein.
  • @accessGibt an, ob eine Eigenschaft als private, protected oder public markiert wurde.
  • @varWie @param.

Code-Schnippsel:

<?php
/**
 * Zusammenfassung.
 *
 * @since x.x.x
 * @access (private, protected, or public)
 * @var Typ $var Beschreibung.
 *
 */
 ?>

Beispiel:

<?php
class Meine_Klasse {
	/**
	 * Prüft ob Motor gerade läuft.
	 *
	 * @since  1.0.0
	 * @access private
	 * @var bool $running
	 */
	private $running = false;
}
?>

Auf Github ansehen

2.6.4. Einbinden von Dateien

Dateien, die mit include oder
require eingebunden werden, sollten durch eine kleine Kurzbeschreibung ergänzt werden.

<?php
/**
 * Kurzbeschreibung.
 */
 require_once( ABSPATH . '/dateiname.php' );
?>

2.6.5. Hooks (Actions & Filter)

Wenn Sie eigene Filter (apply_filters) oder Actions (
do_action) in Ihrem Plugin nutzen, so sollten diese dort kommentiert werden, wo sie Anwendung finden.

  • Zusammenfassung
    Sollte mit einem Punkt enden.
  • Beschreibung
    Falls nötig eine ausführliche Beschreibung der Aktion oder des Filters. Endet ebenfalls mit einem
    Punkt.
  • @since
    Gibt die Versionsnummer mit einer optionalen Beschreibung an. Sie sollte dreistellig sein.
  • @param
    Wenn eines der Parameter ein Array übergibt, sollte dieses mittels der PHPDoc Hash-Annotation
    beschrieben werden.
  • @ignore
    Gibt an, ob ein Hook nur für interne Zwecke Verwendung finden sollte.

Achtung:
@return wird nur bei Filtern angegeben. Sie geben immer den ersten Eingangsparameter zurück. Actions haben keinen Rückgabewert.

<?php
/**
 * Zusammenfassung.
 *
 * Beschreibung.
 *
 * @since x.x.x
 *
 * @param array $args {
 *      Kurzbeschreibung
 *      @type type $var Description.
 *      @type type $var Description.
 * }
 * @param  Typ $var Beschreibung.
 */
 do_action( 'mm_tue_etwas', $array, $boolean );
 ?>

Filter und Actions werden in der Regel öfter als nur einmal angewendet. Ist das der Fall, muss nicht immer der komplette PHPDoc-Block wiederholt werden. Stattdessen ist es besser, den kompletten Block nur beim ersten Vorkommen zu dokumentieren und dann darauf zu verweisen.

<?php
/** Diese Aktion wurde in Pfad/zur/dateiname.php bereits dokumentiert. */
do_action( 'mm_tue_etwas', $array, $boolean );
?>

2.6.6. Kommentare

Kommentare, die direkt im PHP Code angegeben werden, sollten wie folgt dokumentiert werden.

<?php
// Einzeiliger Kommentar.

/**
 * Dieser Kommentar ist lang genug, dass
 * er sich über mehrere Zeilen erstreckt.
 */
?>

2.6.7. Dokumentation von Dateien

Im Kopfbereich einer Datei sollte die Dokumentation wie folgt aussehen:

  • Zusammenfassung
    Sollte mit einem Punkt enden und zusammenfassen, welchen Zweck die aktuell vorliegende Datei erfüllt.
  • Beschreibung
    Falls nötig eine ausführliche Beschreibung der Datei. Endet ebenfalls mit einem Punkt.
  • @since
    Gibt die Versionsnummer mit einer optionalen Beschreibung an. Sie sollte dreistellig sein.
  • @see
    Beschreibt eine Funktion, eine Methode oder eine Klasse, auf die aufgebaut wird. Alternativ kann hier
    auch eine URL eingegeben werden.
  • @package
    Ein sogenanntes Package kann dazu verwendet werden, verwandte Elemente zu gruppieren.
  • @subpackage
    Werden dazu benutzt, Elemente in Untergruppen einzuteilen. Oft werden hier auch die PHP Namespaces
    angegeben.
<?php
/**
 * Zusammenfassung.
 *
 * Beschreibung.
 *
 * @since x.x.x
 * @see URL
 *
 * @package WordPress
 * @subpackage Komponent
 */
 ?>

2.6.8. Konstanten

  • Zusammenfassung
    Sollte mit einem Punkt enden.
  • @since
    Gibt die Versionsnummer mit einer optionalen Beschreibung an. Sie sollte dreistellig sein.
  • @var
    Angabe von Typ und Beschreibung.
<?php
/**
 * Kurzbeschreibung.
 *
 * @since x.x.x
 * @access (private, protected, or public)
 * @var Typ $var Beschreibung.
 *
 */
 ?>

Beispiel:

<?php
class Meine_Klasse {
	/**
	 * Wert für den Start.
	 *
	 * @since  1.0.0
	 * @access public
	 * @var int
	 */
	const START = 0;
}
?>

Auf Github ansehen

2.6.9. Häufig verwendete PHPDoc-Blocks in WordPress

  • @access
    Benutzung: public, private oder protected
    Definiert die Zugriffssteuerung auf Funktionen und Methoden. @access private bedeutet, dass die
    Funktion/Methode nicht dokumentiert werden soll, da sie nicht für den öffentlichen Einsatz erstellt wurde.
  • @deprecated
    Benutzung: x.x.x Neuer Funktionsname
    Gibt an, ab welcher Version des Plugins die Funktion für veraltet erklärt wurde. Sollte dreistellig sein.
  • @global
    Benutzung: [Typ] $GLOBALS['varname']
    Gibt an, ob eine globale Variable verwendet wurde.
  • @internal
    Benutzung: [Beschreibung]
    Kann für interne Anmerkungen benutzt werden.
  • @ingore
    Benutzung: steht für sich allein.
    Wenn das aktuelle Element komplett übersprungen werden soll (d.h. nur interne Nutzung).
  • @link
    Benutzung: [URL]
    Sollte nicht mehr benutzt werden, da veraltet. Nutzen Sie stattdessen @see.
  • @method
    Benutzung: [Typ] [Beschreibung]
    Gibt eine magische Funktion innerhalb einer Klasse an.
  • @package
    Benutzung: [Paketname]
    Spezifiziert ein Paket, zu dem die Funktionen und Konstanten gehören.
  • @param
    Benutzung: [Typ] $varname [Beschreibung]
    Parameter einer Funktion oder einer Methode.
  • @return
    Benutzung: [Typ] [Beschreibung]
    Dokumentiert den Rückgabewert einer Funktion oder einer Methode.
  • @see
    Benutzung: [Elementname]
    Referenziert eine andere Methode, Funktion oder Klasse, auf die aufgebaut wird. Alternativ kann auch eine URL
    als Verweis angegeben werden.
  • @since
    Benutzung: x.x.x [Beschreibung]
    Dokumentiert, ab wann eine Funktion/Methode/Klasse zum Plugin hinzugefügt wurde. Sollte dreistellig sein.
  • @subpackage
    Benutzung: [Name]
    Spezifiziert eine Komponente, zu der alle Funktionen und Methode gehören.
  • @todo
    Benutzung: [Beschreibung]
    Beschreibt zukünftige Änderungen.
  • @type
    Benutzung: [Typ] [Beschreibung]
    Wird für die Typenbezeichnungen von Array-Werten benutzt.
  • @uses
    Benutzung: klasse:methode() oder klasse::$variable oder funktionsname().
  • @var
    Benutzung: [Typ] [Beschreibung]
    Datentyp für eine Klassenvariable sowie eine kurze Beschreibung dieser.

2.7. Präfixe

Sie haben genau drei Möglichkeiten, Ihr neues Plugin zu programmieren. Zum einen können Sie nur mit PHP-Funktionen arbeiten (auch klassische, traditionelle oder prozedurale Programmierung genannt), Sie entwickeln objektorientiert und nutzen für alle Funktionen dann Klassenmethoden oder Sie benutzen PHP-Namespaces.

Nutzen Sie ersteres, sollten Sie es sich angewöhnen, alle Funktionen mit einem Präfix zu versehen. So wird aus der Funktion
meine_funktion() jetzt
mm_meine_funktion(). Als Präfix können Sie nutzen, was Sie wollen. Jedoch sollte am Anfang keine Zahl stehen und je mehr Buchstaben Sie benutzen, desto besser. Achten Sie auch darauf, dass Sie immer das gleiche Präfix nutzen, sonst wird es bei größeren Projekten schnell kompliziert. In unserem Beispiel nutzen wir für das Präfix die Initialen
mm, was letztlich für Max Mustermann steht.

Aber warum macht man das? WordPress definiert intern selbst sehr viele Funktionen ohne sie in Klassen zu verpacken. Das führt letztendlich dazu, dass Sie den gleichen Namen nicht mehrfach verwenden dürfen und können.

Es könnte Ihnen also irgendwann einmal in den Sinn kommen, eine
get_post Funktion zu erstellen weil Sie vielleicht noch nicht allzu sehr mit dem Core vertraut sind und nicht wissen, dass die Funktion in WordPress bereits existiert. Sie erhalten dann einen PHP-Fatal Error mit dem Hinweis, dass die Funktion bereits deklariert wurde.

Besser ist es natürlich, eine Funktion mit dem Namen
mm_get_post zu erstellen, die dann die gewünschten Aktionen ausführt, die Sie benötigen. Und natürlich, nur sofern nicht bereits eine WordPress-interne Funktion existiert, die dasselbe macht.

Mit (globalen) Variablen und Klassennamen sollten Sie genauso verfahren. Ein gutes Beispiel hier ist die globale Variable
$post. Definieren und überschreiben Sie diese Variable führt das möglicherweise zu unvorhersehbaren Ergebnissen. WordPress geht immer davon aus, dass sie existiert.

Übrigens sollten Sie auch Javascript Variablen, Funktionen und CSS-Klassen mit einem Präfix versehen. Alternativ – wie oben beschrieben – können Sie auch Namespaces nutzen.

Der Einfachheit halber – und soweit möglich – nutze ich in diesem Buch den prozeduralen Programmierstil.

2.8. Datei- und Verzeichnisstruktur

Wie bereits im Kapitel über die Coding
Standards
angedeutet: Sie sind kein Muss. Genauso wenig, wie die nachfolgenden Datei- und Ordnerstruktur, die ich Ihnen ans Herz legen möchte. Die empfohlene Struktur soll Ihnen jedoch dabei helfen, den Code sauber, nachvollziehbar und strukturiert zu gestalten.

Ich selbst habe schon sehr viele Strukturen ausprobiert: eine Herangehensweise, die nur Funktionen nutzt und welche, die nur objektorientiert arbeiten. In beiden Fällen ist und war es immer von Vorteil, eine gewisse Ordnerstruktur zu haben.

Das bedeutet zuerst einmal: Im Plugin-Ordner selbst sollten sich nur drei Dateien befinden:

  1. Die primäre Plugin-Datei, die von WordPress gesucht, gefunden und ausgeführt wird,
  2. eine mögliche uninstall.php-Datei und
  3. die readme.txt, die genauere Informationen zum Plugin sowie eine kurze Beschreibung, eine FAQ oder
    ähnliches enthält.

Alle anderen Dateien sollten in separat dafür vorgesehenen Ordnern abgelegt werden. Ein Beispiel:

  • /mein-plugin/
    • mein-plugin.php
    • (uninstall.php)
    • readme.txt
    • /assets
      • /js – JavaScript-Dateien
      • /css – CSS-Dateien
      • /images – Bilder
      • /languages – Sprachdateien
    • /includes (oder /classes) – einzelne PHP-Dateien

Aus Performancegründen sollten Sie bestimmte Bestandteile Ihres Plugins in einzelne PHP-Dateien auslagern, anstatt den gesamten Code in eine einzelne Datei zu schreiben. Beispielsweise lassen sich mit

<?php
if( is_admin() ){
	require_once( "meine-zusaetzliche-datei.php" );
}
?>

nur Dateien laden, die im Backend-Bereich von WordPress nötig sind.

2.9. Die ersten Codezeilen

Nachdem der Kopfbereich einer Plugin-Datei (
mein-plugin.php) angelegt wurde, kann mit der Entwicklung begonnen werden.

Sehr oft werden Sie jedoch eine Pfadangabe zu bestimmten Dateien oder Verzeichnissen benötigen. Dazu gehören zum Beispiel andere PHP-Dateien, die per
include oder require eingebunden werden.

Eine unvorteilhafte Idee ist es deshalb, diese Pfadangaben „hart“ in den Quellcode zu programmieren. Schließlich kann WordPress auch so konfiguriert werden, dass Pfade anders lauten als bei Ihnen.

WordPress bringt schon einige sehr gute Funktionen mit, die Sie benutzen können, um Pfade zu konstruieren. Diese sind nachfolgend aufgeführt.

2.9.1. Lokaler Plugin-Pfad

Ein lokaler Pfad ist nichts anderes als ein „Link“ auf eine Datei auf einem Rechner. Nützlich genau dann, wenn Sie eine PHP-Datei per
include einfügen möchten. Denn nichts ist wohl unterschiedlicher als der lokale Pfad einer WordPress-Installation. Um den aktuellen Pfad zu Ihrem Plugin herauszufinden, können Sie folgende Funktion nutzen:

<?php
$mm_pfad = plugin_dir_path( __FILE__ );
?>

Die PHP-Konstante __FILE__ gibt dabei den aktuellen Pfad Ihrer
mein-plugin.php-Datei zurück. Die Funktion
plugin_dir_path() filtert dann lediglich den Dateinamen weg und hängt am Ende einen Slash (
/) an. In der Variable $pfad wäre also ein möglicher Rückgabewert der folgende:

/var/www/mm/wordpress/wp-content/mein-plugin/

Um also eine weitere PHP-Datei per require einzufügen, könnten Sie wie folgt vorgehen:

<?php
$mm_pfad = plugin_dir_path( __FILE__ );

require $mm_pfad . 'includes/zweite-datei.php';
?>

Das bedeutet, dass die Datei
/var/www/mm/wordpress/wp-content/mein-plugin/includes/zweite-datei.php eingebunden wird.

Da der Pfad zum Plugin-Verzeichnis öfter benötigt wird, empfiehlt es sich, eine eigene Konstante anzulegen.

<?php
define( 'MM_PLUGIN_DIR_PATH', plugin_dir_path( __FILE__ ) );

require MM_PLUGIN_DIR_PATH . 'includes/zweite-datei.php';
?>

Auf Github ansehen

Auch hier gilt: Vergessen Sie bei Variablen und Konstanten nie, das von Ihnen festgelegte Präfix anzufügen.

2.9.2. Plugin-URL

Neben dem Pfad zum Plugin-Verzeichnis ist mitunter auch die genaue URL interessant. Sie dient beispielsweise der Darstellung von Bildern.

<?php
$mm_plugin_url = plugins_url( $path, $plugin );
?>

Die Funktion erfordert zwei Parameter:

  • $path (string)
    Eine eventuelle Pfadangabe.
  • $plugin (string)
    Die Pfadangabe, auf die sich $path beziehen soll.

Beispiel

<?php
$mm_plugin_url = plugins_url( '', __FILE__ );
?>

Dabei könnte folgendes ausgegeben werden:

http://beispiel.de/wp-contents/plugins/mein-plugin

Zu beachten ist, dass die
plugins_url()-Funktion am Ende keinen Slash anhängt. Um dies dennoch zu tun, können Sie die Funktion trailingslashit() benutzen. Außerdem wäre es auch hier sinnvoll, eine eigene Konstante zu definieren.

<?php
$mm_plugin_url = trailingslashit( plugins_url( '', MM_PLUGIN_DIR_PATH ) );
?>

Die Ausgabe wäre dementsprechend:

http://beispiel.de/wp-contents/plugins/mein-plugin/

Ohne Parameter gibt die Funktion die URL zum Plugin-Verzeichnis zurück, in dem alle Plugins liegen:

<?php
$mm_plugin_url = plugins_url();
// ergibt: http://beispiel.de/wp-contents/plugins
?>

Bei Angabe eines Pfades wird dieser angehängt:

<?php
$mm_plugin_url = plugins_url( 'images/mein-bild.jpg', MM_PLUGIN_DIR_PATH );
// ergibt: http://beispiel.de/wp-contents/plugins/mein-plugin/images/mein-bild.jpg
?>

2.9.3. Weitere Funktionen für Pfade und URLs

2.9.3.1. plugin_dir_url( $file )

Ähnlich wie
plugins_url() gibt diese Funktion die URL zum Plugin-Verzeichnis zurück. Eine Pfadangabe ist nicht möglich.
Achtung: Hier wird am Ende wieder ein finaler Slash angehängt. Als
$file muss der Pfad zum Plugin angegeben werden.

<?php
$mm_plugin_dir_url = plugin_dir_url( __FILE__ );
// ergibt: http://beispiel.de/wp-contents/plugins/mein-plugin/
?>
2.9.3.2. plugin_basename( $file )

Gibt den Pfad relativ zum Plugin-Verzeichnis zurück. Achtung: Auch diese Funktion hängt am Ende
sowie am Anfang keine Slashes an. Als $file muss der Pfad zum Plugin angegeben werden.

<?php
$mm_plugin_basename = plugin_basename( __FILE__ );
// ergibt: mein-plugin/mein-plugin.php
?>
2.9.3.3. admin_url( $path = “, $scheme = ‚admin‘ )

Gibt die URL zum Administrationsverzeichnis zurück. Ein Slash wird am Ende angehängt. Der Parameter
$path erlaubt das Anhängen eines Pfades relativ zur URL. Der Standardwert für $scheme ist
admin. Er gibt der URL einen genauen Kontext. Möglich sind darüber hinaus https,
http, login, login_post, relative oder natürlich null.

<?php
$mm_admin_url = admin_url();
// ergibt: http://beispiel.de/wp-admin/
?>
2.9.3.4. site_url( $path = “, $scheme = null )

Gibt die URL zur aktuellen WordPress-Installation zurück. Dieser Wert stimmt mit der Angabe unter „Einstellungen“ » „Allgemein“ » „WordPress Adresse (URL)“ überein. Der Parameter
$path erlaubt das Anhängen eines Pfades relativ zur URL. Der Standardwert für $scheme ist
null.

<?php
$mm_site_url = site_url();
// ergibt: http://beispiel.de
?>
2.9.3.5. content_url( $path = “ )

Gibt die URL zum wp-content Verzeichnis zurück.
Achtung: Auch hier wird kein Slash am Ende angehängt. Der Parameter
$path erlaubt das Anhängen eines Pfades relativ zur URL.

<?php
$mm_content_url = content_url();
// ergibt: http://beispiel.de/wp-content
?>
2.9.3.6. includes_url( $path = “ )

Gibt die URL zum wp-includes Verzeichnis zurück.
Achtung: Auch hier kein Slash am Ende. Der Parameter
$path erlaubt das Anhängen eines Pfades relativ zur URL.

<?php
$mm_includes_url = includes_url();
// ergibt: http://beispiel.de/wp-includes
?>
2.9.3.7. wp_upload_dir( $time = null )

Gibt ein Array mit folgenden Werten zurück:

  • path
    Absoluter Pfad zum wp-content Verzeichnis. Falls „Organisiere Uploads in monats- und
    jahresbasierten Ordnern“
    unter „Einstellungen“ » „Medien“ aktiviert wurde, wird am Ende noch das
    Jahr sowie der Monat als Zahl angehängt. Wird $time im Format YYYY/MM angegeben,
    wird jeweils der Ordner für dieses Datum zurückgegeben. Falls $time null ist, wird die
    Zahl des aktuellen Jahres inklusive Monat zurückgegeben.
  • url
    Verhält sich wie die path-Angabe mit dem Unterschied, dass die URL zurückgegeben wird.
  • subdir
    Das Unterverzeichnis, falls „Organisiere Uploads in monats- und jahresbasierten Ordnern“
    aktiviert wurde. Beispiel: /2014/01.
  • basedir
    Der Pfad ohne subdir.
  • error
    Wird auf false gesetzt, wenn alles ok ist. Ansonsten gibt WordPress hier eine Fehlermeldung zurück,
    falls kein wp-content-Verzeichnis existiert oder es nicht angelegt werden konnte.

Beispiel:

<?php
$mm_wp_upload_dir = wp_upload_dir();

/**
 * $mm_wp_upload_dir ist ein Array und enthält folgenden Schlüssel und Werte:
 *	path     => /var/www/mm/wordpress/wp-content/uploads/2014/01
 *	url      => http://beispiel.de/wp-content/uploads/2014/01
 *	subdir   => /2014/01
 *	basedir  => /var/www/mm/wordpress/wp-content/uploads
 *	baseurl  => http://beispiel.de/wp-content/uploads
 *	error    => false
 */
?>
2.9.3.8. home_url( $path = “, $scheme = null )

Gibt zurück, was unter „Einstellungen“ » „Allgemein“ » „Seiten-Adresse (URL)“ angegeben wurde. Der Parameter
$path erlaubt das Anhängen eines Pfades relativ zur URL. Der Standardwert für $scheme ist
null.

<?php
$mm_home_url = home_url();
// ergibt: http://beispiel.de
?>

Beachten Sie, dass diese Funktion in den meisten Fällen dasselbe zurückgibt wie
site_url. Nur wenn die Startseite in einem anderen Verzeichnis als die WordPress-Installation liegt, gibt
home_url etwas anderes zurück.

2.9.3.9. Pfade und URLs für Themes

Unter http://codex.wordpress.org/DeterminingPluginandContentDirectories finden Sie eine Sammlung aller möglichen Funktionen, die entweder Pfade oder URLs zurückgeben. So gibt es separate Funktionen für das Entwickeln von Themes, die in diesem Buch allerdings nicht besprochen werden.

2.9.3.10. Pfade und URLS für Multisite-Instanzen

Darüber hinaus gibt es auch Funktionen zum Abruf von Multisite-URLs und Pfaden. Diese können meist mit
get_* oder network_* Präfix aufgerufen werden.

  • get_admin_url( $blog_id = null, $path = '', $scheme = 'admin' )
    Wie admin_url jedoch mit erforderlicher Angabe der Blog ID.
  • get_home_url( $blog_id = null, $path = '', $scheme = null )
    Wie home_url() jedoch mit Angabe der Blog ID.
  • get_site_url( $blog_id = null, $path = '', $scheme = null )
    wie site_url jedoch mit Angabe der Blog ID.
  • network_admin_url( $path = '', $scheme = 'admin' )
    wie admin_url() jedoch bezogen auf den Netzwerk-Administrationsbereich.
  • network_site_url( $path = '', $scheme = null )
    wie site_url() jedoch bezogen auf den Netzwerk-Blog (in der Regel der erste Blog, der angelegt
    wurde).
  • network_home_url( $path = '', $scheme = null )
    wie home_url() jedoch bezogen auf den Netzwerk-Blog (in der Regel der erste Blog, der angelegt
    wurde).

2.9.4. Plugin-Aktivierung

Nicht selten kommt es vor, dass Plugins bereits bei der Aktivierung bestimmte Aufgaben erledigen sollen. Ein Beispiel wäre das zusätzliche Anlegen einer Datenbanktabelle oder das Setzen von Standard-Einstellungen. Genau für diesen Fall gibt WordPress Ihnen die Möglichkeit, per
register_activation_hook( $file, $function ) eine Funktion anzugeben, die Aktivierungs-Aufgaben durchführt.

<?php
define( 'MM_PLUGIN_FILE', __FILE__ );

register_activation_hook( MM_PLUGIN_FILE, 'mm_activation' );

function mm_activation(){
	// mach etwas
}
?>

Auf Github ansehen

Wie Sie sehen benötigt der erste Parameter die Pfadangabe zum aktuellen Plugin, die wir über
__FILE__ bzw. die Konstante
MM_PLUGIN_FILE übergeben. Der zweite Parameter benötigt den Namen der Funktion, die bei Aktivierung ausgeführt werden soll.

2.9.5. Plugin-Deaktivierung

Genauso wie die Plugin-Aktivierung funktioniert auch die Plugin-Deaktivierung. Die Funktion register_deactivation_hook() erwartet dieselben Parameter.

<?php
define( 'MM_PLUGIN_FILE', __FILE__ );

register_deactivation_hook( MM_PLUGIN_FILE, 'mm_deactivation' );

function mm_deactivation(){
// mach etwas
}
?>

Auf Github ansehen

Diese Funktion sollte übrigens nicht dazu benutzt werden, das Plugin zu deinstallieren. Das soll heißen: Keine Dateien, Einstellungen oder Tabellen, die das Plugin zur Aktivierung angelegt hat, sollen mit der Deaktivierung gelöscht werden.

Warum sollen bei der Deaktivierung keine Daten gelöscht werden?

Ein Plugin zu deaktivieren bedeutet nicht gleich, es zu deinstallieren. Installiert man WordPress beispielsweise als „normalen“ Blog und aktiviert erst später die Multisite-Funktionalität, wird man aufgefordert, vorher alle Plugins zu deaktivieren.

Erst nach der Umstellung auf Multisite kann man alle Plugins wieder aktivieren. Es wäre recht unerfreulich, wenn man später merkt, dass plötzlich alle Einstellungen eines Plugins verschwunden sind. Für den Endbenutzer bedeutet das Frust pur.

Die Deinstallation sollte über die uninstall.php geschehen. Doch dazu gleich mehr.

2.9.6. Plugin-Deinstallation

Wenn ein Plugin Daten oder Dateien bei der Installation anlegt, sollte man dafür sorgen, dass diese beim Löschen auch wieder passend entfernt werden. WordPress kümmert sich nicht automatisch darum, denn es führt nicht Buch darüber, welche Daten von Ihrem Plugin hinzugefügt werden.

Denken Sie dabei immer an sich selbst. Sie möchten auch gerne, dass eine Software alle Teile, die sie bei der Installation angelegt hat, bei der Deinstallation wieder entfernt. Sie möchten nicht, dass etwas übrig bleibt. Immerhin sollte der Speicher auch wieder freigegeben werden, wenn er nicht mehr benötigt wird.

Grundsätzlich gibt es zwei Möglichkeiten, ein Plugin zu deinstallieren:

2.9.6.1. uninstall.php

Die erste Methode behandelt die Deinstallation mittels
uninstall.php. Wie weiter oben bereits angedeutet, muss sich diese Datei im Stammverzeichnis Ihres Plugins befinden. Sie wird dann ausgeführt, wenn das Plugin aus der Liste der Plugins gelöscht wird. Und hier liegt auch gleich der Hund begraben.
„Löschen“ bedeutet nämlich nicht auch sofort
„Deinstallieren“. Viele WordPress-User klicken nicht auf den Löschen-Link, sondern entfernen Plugins direkt per FTP. Damit wird die Deinstallations-Routine gar nicht erst aufgerufen. Nichtsdestotrotz sollte man Gebrauch davon machen.

<?php
// uninstall.php

if ( ! defined( 'WP_UNINSTALL_PLUGIN' ) ) {
	exit();
}

if ( ! WP_UNINSTALL_PLUGIN ) {
	exit();
}

// entferne etwas
?>

Auf Github
ansehen

Wie Sie sehen, muss die Konstante
WP_UNINSTALL_PLUGIN zuerst überprüft werden. Nur wenn sie existiert, wird die Deinstallation ausgeführt.

Vorsicht ist geboten, wenn Sie Zugriff auf Funktionen benötigen, die sich im Plugin befinden. Es wird nämlich während der Deinstallation nicht geladen. Wird eigener Plugin-Code benötigt, sollte man stattdessen auf die Funktion
register_uninstall_hook() zurückgreifen.

2.9.6.2. register_uninstall_hook()

Die register_uninstall_hook()-Funktion wird dann aufgerufen, wenn keine
uninstall.php gefunden werden konnte.

Hier gilt: Mitunter kann es zu Problemen kommen, wenn Sie in Ihrer Plugin-Datei Quellcode ausführen lassen, der sich nicht innerhalb einer Funktion bzw. eines Hooks befindet.
Generell sollte ausführbarer Code immer innerhalb von Funktionen (oder Methoden)
stehen.
Der Grund ist, dass WordPress das Plugin laden muss, bevor der Uninstall-Hook ausgeführt werden kann. Das bedeutet, dass ein anderer Plugin-Code möglicherweise mit ausgeführt wird, falls er nicht innerhalb einer Funktion steht. Das wiederum kann dafür sorgen, dass das Plugin nicht deinstalliert wird.

<?php
register_activation_hook( __FILE__, 'mm_activation' );

function mm_activation() {
	register_uninstall_hook( __FILE__, 'mm_uninstall' );
}

function mm_uninstall() {
	/* Ihr Code */
}
?>

Auf Github
ansehen

Wie Sie sehen, wird im obigen Beispiel die Funktion
mm_uninstall nur einmalig bei Plugin-Aktivierung registriert. Das sorgt dafür, dass WordPress die Funktion nicht immer lädt, wenn eine Admin-Seite aufgerufen wird.

Hinweis zum Testen:

Wundern Sie sich nicht, wenn die Deinstallations-Routine nicht aufgerufen wird, wenn das Plugin noch nie aktiviert
wurde. Das Plugin muss mindestens einmal aktiviert worden sein, bevor die von Ihnen registrierte Funktion zur
Deinstallation aufgerufen werden kann.

3. Kapitel 3 – Hooks

Sie wurden bereits angesprochen: die sogenannten Hooks. Sie bilden den Kern von WordPress und lassen Plugins zu sehr mächtigen Konstrukten anwachsen. Gerade dadurch, dass sie es erlauben, in den Arbeitsablauf von WordPress einzugreifen ohne den eigentlichen Quellcode anzufassen.

Das hat gleich mehrere Vorteile:

  1. Plugins können ohne Programmierkenntnisse bequem hinzugefügt oder entfernt werden.
  2. Die Standard-Installation von WordPress ändert sich nicht, weil der originale Quellcode nicht verändert werden
    muss. Dadurch kann es automatisch aktualisiert werden, ohne dass man selbst erneut Hand anlegen muss.
  3. Das wiederum macht WordPress sicherer, da sehr schnell auf die neueste Version aktualisiert werden kann.

Zugegeben, am Anfang ist das Verständnis von Hooks schwierig. Deshalb lernen Sie in diesem Kapitel, was Hooks genau sind und wie sie benutzt werden können.

3.1. Filter und Aktionen

Die Leseprobe ist an dieser Stelle leider zu Ende. Kaufen Sie das Buch jetzt um weiterzulesen.

Wenn Sie darüber informiert werden möchten, wann der zweite und letzte Band erscheint, dann tragen Sie sich doch zum
WordPress-Entwickler Newsletter ein. Das geht hier:

3.2. Actions

Die Leseprobe ist an dieser Stelle leider zu Ende. Kaufen Sie das Buch jetzt um weiterzulesen.

3.3. Filter

Die Leseprobe ist an dieser Stelle leider zu Ende. Kaufen Sie das Buch jetzt um weiterzulesen.

3.4. Art der Übergabe von Funktionen

Die Leseprobe ist an dieser Stelle leider zu Ende. Kaufen Sie das Buch jetzt um weiterzulesen.

3.5. Filter und Actions finden

Die Leseprobe ist an dieser Stelle leider zu Ende. Kaufen Sie das Buch jetzt um weiterzulesen.

3.6. Einfaches Beispiel mit Hooks: Drafts for Friends

Die Leseprobe ist an dieser Stelle leider zu Ende. Kaufen Sie das Buch jetzt um weiterzulesen.

4. Kapitel 4 – Plugin Integration

Sie haben nun gelernt, wie Sie WordPress Hooks, also die Filter und Actions, dazu benutzen können, Manipulationen an WordPress vorzunehmen. In einigen, wenigen Fällen reicht dies oft bereits aus. Dann genügt es, wenn der Endnutzer das Plugin aktiviert. WordPress beginnt dann, den in der Plugin-Datei enthaltenen Code einzubinden und auszuführen.

Die meisten Plugins benötigen jedoch eine eigene Einstellungsseite die es dem Benutzer erlaubt, mit dem Plugin zu interagieren oder dessen Verhalten zu verändern. Dies kann auf mehreren Wegen erfolgen:

  • Über eine eigene Einstellungsseite
    Sie können einen eigenen Menüpunkt im Administrationsbereich von WordPress erstellen und es dem Benutzer
    erlauben Einstellungen dort zu verändern.
  • Über Metaboxen
    Beim Editieren eines Artikels sind Sie Ihnen wohl bereits begegnet. Die Metaboxen sind einzelne
    Einstellungsbereiche innerhalb einer Seite. Sie können problemlos weitere Bereiche für Ihr Vorhaben hinzufügen.
  • Über Widgets und Dahsboard Widgets
    Widgets haben einen eigenen Einstellungsbereich. Er ist immer dann sichtbar, wenn ein Widget zu einer
    Seitenleiste hinzugefügt wurde.

Aber lassen Sie uns erst mit dem Einbinden von Menüs beginnen.

4.1. Top- und Second-Level Menüs

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Wenn Sie darüber informiert werden möchten, wann der zweite und letzte Band erscheint, dann tragen Sie sich doch zum
WordPress-Entwickler Newsletter ein. Das geht hier:

4.2. Metaboxen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

4.3. Die Settings API

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

4.4. Die Options API

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

4.5. Widgets API

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5. Kapitel 5 – Plugin Sicherheit

Die Sicherheit einer Webanwendung ist ein großes Thema und darf nicht vernachlässigt werden, auch wenn indees ein fast zu großes Feld ist um es hier komplett zu behandeln. Denn mit „Sicherheit“ werden im gleichen Zuge auch Begriffe wie SQL Injection, Cross Site Scripting, Session Hijacking und viele andere genannt.

Nichts desto trotz ist es leider so, dass Sicherheitslücken massiv ausgespäht und letztlich auch ausgenutzt werden (können). Im schlechtesten Fall kann der komplette Webserver kompromittiert werden. Durch schlechte Sicherheitsvorkehrungen gelangen auch immer wieder sensible Daten an die Öffentlichkeit.

In WordPress bedeutet „Sicherheit“ zwei Dinge:

  • Die Empfindlichkeit gegen Angriffe erhöhen und
  • die Datenintegrität sicherstellen.

Daraus ergibt sich, dass bösartigen Attacken entgegen gewirkt werden kann und der Code dadurch einfacher zu handhaben ist, weil es kein unerwartetes Verhalten gibt.

Toll ist, dass WordPress alle Tools die zu einem sicheren Plugin beitragen bereits mit an Board hat. Das macht das Einprogrammieren von Sicherheitsmaßnahmen einfach und schnell.

Wenn Sie darüber informiert werden möchten, wann der zweite und letzte Band erscheint, dann tragen Sie sich doch zum
WordPress-Entwickler Newsletter ein. Das geht hier:

5.1. Nonces

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.2. Benutzerrechte

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.3. Rollen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.4. Filtern: Validieren und Säubern

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.5. Superglobale Variablen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.6. Formulare

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.7. Sichere Datenbankmanipulationen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

5.8. Sicherheit im Allgemeinen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Wenn Sie darüber informiert werden möchten, wann weitere Kapitel erscheinen, dann tragen Sie sich doch zum WordPress-Entwickler Newsletter ein. Das geht hier:

Kapitel 6 – Internationalisierung

Unter
Internationalisierung versteht man das Vorhaben, ein Plugin so vorzubereiten, dass es ohne größeren Aufwand in jede beliebige Sprache übersetzt werden kann. Als Standard definiert WordPress die US-Amerikanische Sprache (en_US). Das bedeutet: Alle Plugins müssen „in englisch“ programmiert und erst später in andere Sprachen übersetzt werden.

Schön ist, bereits viele Übersetzungsfunktionen mit an Board sind. Es ist also nicht sonderlich schwer, ein Plugin zu internationalisieren.

Als Programmierer müssen Sie lediglich einige Funktionen kennen, die Sie dann während der Programmierung sofort mit integrieren können. Das bedeutet: Ein Entwickler muss nicht zuerst ein Plugin erstellen und es anschließend übersetzen. In den meisten Fällen wird die Internationalisierung schon während der Entwicklung sofort mit eingebaut.

6.1. Allgemeine Sprachdatei-Funktionen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.2. Übersetzungsfunktionen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.3. Platzhalter in Übersetzungen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.4. Übersetzung von Javascript-Inhalten

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.5. Übersetzungsdateien erstellen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.6. Portable-Object- (PO) und Message-Object- (MO) Dateien

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.7. Software- und Web-Tools zur Übersetzung

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

6.8. Eine PO-Datei erstellen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

7. Benutzer & Rechte

In den Kapiteln 5.2. und 5.3. haben Sie bereits gelernt, welche Benutzer und Rollen es gibt und wie diese dazu benutzt werden können, Zugriff auf bestimmte Seiten oder Aktionen zu beschränken.

Noch vor ein paar Jahren hatte WordPress keine Benutzer und Rechte. Es gab einen Login mit dem sich alle Benutzer einloggen konnten. In Version 2.0.0. tauchte dann erstmals die Funktion wp_insert_user() auf. Damit war klar: WordPress konnte von nun an auch mehrere Benutzer verwalten. Und das ist auch gut so, denn damit tat das vormals kleine Bloggingsystem WordPress wieder einen großen Schritt hin in Richtung Content Management System.

Mit der Einführung von Benutzerrollen und -rechten wurde auch der Sicherheit eine größere Bedeutung zugewiesen. Welche Funktionen da eine Rolle spielen, haben Sie im Kapitel zur Plugin Sicherheit bereits gelernt. Aber es gibt noch mehr interessante Funktionen, die ich Ihnen diesem Kapitel vermitteln möchte.

7.1. Benutzer-Handling

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

7.2. Benutzer-Metadaten

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

7.3. Benutzerdaten in Multisite-Umgebungen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

7.4. Weitere Benutzerfunktionen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Wenn Sie darüber informiert werden möchten, wann weitere Kapitel erscheinen, dann tragen Sie sich doch zum WordPress-Entwickler Newsletter ein. Das geht hier:

8. Shortcode API

Mit WordPress 2.5. fand eine neue, sehr intuitive und geniale API zugleich Einzug in den Quellcode: Die Shortcode-API. Sie erlaubt es, auf relativ einfache Weise, raffinierten und leicht zu handhabbaren Code in den WordPress-Editor einzufügen, der dann wiederum eine spezielle Funktion ausführt. Ohne Shortcodes wäre die Welt des WordPress-Editors um einiges wüster, denn sie erlauben es, den Editor frei von langem Quellcode zu halten und ist dabei von Laien sehr einfach zu benutzen.

8.1 Einen Shortcode erstellen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.2 Standardwerte von Shortcode Attributen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.3 Einen Shortcode entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.4 Alle Shortcodes löschen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.5 Existenz eines Shortcodes prüfen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.6 Inhalte auf Shortcode prüfen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.7 Shortcodes aus einem Inhalt entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

88 Shortcodes umwandeln

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.9 Weitere Shortcode-Funktionen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

8.10 Anmerkungen zu den Shortcodes

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 9: Grundlagen für HTTP-Abfragen

An allen Enden und Ecken lauern heutzutage so genannte Application Programming Interfaces, kurz: APIs. Sie können auf vielfältige Art und Weise genutzt werden. Zum Beispiel um Geld via Paypal zu transferieren oder um die letzten Beiträge aus dem eigenen Facebook-Stream zu lesen.

Die eigentliche HTTP-API wurde in der Version 2.7.0 eingeführt und standardisiert. In späteren Versionen kamen immer mehr und mehr Funktionen hinzu. Zum Beispiel Komprimierung, Cookie- und Proxy-Support.

Die HTTP-API unterstützte vormals drei verschiedene Methoden um Daten aus dem Internet zu empfangen oder dort hin zu senden. Diese waren:

Darüber hinaus gäbe es natürlich noch:

Die Klasse WP_HTTP_Fsockopen wurde jedoch in Version 3.7.0. in die Klasse
WP_HTTP_Streams integriert (bzw. eigentlich entfernt) und besteht heute nur noch aus Gründen Kompatibilität.

In Version 4.6 hat die HTTP-API eine große Überarbeitung erfahren1. So wurde der komplett eigens geschriebene Unterbau entfernt und die unabhängige
Requests Library in WordPress integriert.

Ein großer Misstand ist, dass nicht jede Webserver-Konfiguration alle Transportmöglichkeiten unterstützt. Auch unterschiedliche PHP-Versionen oder engere Sicherheitseinstellungen machen oft Probleme. So kann es vorkommen, dass die Curl-Funktionen von PHP auf einem Webserver einfach nicht vorhanden sind. Jeder Plugin-Programmierer musste deswegen immer mehrere Methoden selbst integrieren, was natürlich ein großer Aufwand wäre.

Die HTTP-API von WordPress hat für eine Standardisierung gesorgt. Nun können mit einer Handvoll Funktionen, Anfragen gesendet und empfangen werden ohne im Hintergrund die genaue Funktionsweise zu kennen.

Ein weiterer Vorteil bei der Nutzung der HTTP-API ist, dass vieles schon vorkonfiguriert ist. Sie können die Funktionen mit minimalen Parametern aufrufen und sie funktionieren trotzdem.

9.1. Helfer-Funktionen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

9.2. Verbindungsmethode testen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

9.3. Fortgeschrittene Konfigurationsmöglichkeiten

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

9.4. Mögliche Stolpersteine bei der Arbeit mit der HTTP-API

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

9.5.Beispiele

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 10 – Daten Zwischenspeichern: die Transient API

Im Beispiel des Kapitels 9.6.1. habe ich gezeigt wie es möglich ist, die Anzahl von Facebook-Likes einer URL abzurufen. Dazu wurde die Funktion wp_remote_request() benutzt. Als Standard-Timeout-Wert verwendet WordPress 5 Sekunden. Das ist ganz okay. Zumindest solange wie die Graph API von Facebook innerhalb dieser Zeit antwortet. Tut sie das nicht, schöpft WordPress die vollen 5 Sekunden komplett aus, was letztlich dazu führt, dass die Ladezeit der Website sich um 5 Sekunden verzögert. Und das bei jedem Aufruf der Website. Das ist nicht gerade elegant vor allem weil man keinen Einfluss auf die API hat. Abhilfe schafft hier die so genannten Transient API. Transient kommt aus dem englischen und steht für “vorübergehend“, “flüchtig“ oder “vergänglich“. Eine Art Cache also.

Die Transient API ist ähnlich aufgebaut wie die Options API und befindet sich praktisch gesehen auch in der selben Datei1 wie die Options API (wird also unter demselben Namen geführt). Es gibt eine get_transient()– genauso wie eine set_transient()-Funktion. Der Unterschied besteht lediglich darin, dass zum übergebenen Wert auch eine Ablaufzeit gespeichert wird. Aber sehen wir uns das im Detail genauer an.

10.1. set_transient()

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

10.2. get_transient()

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

10.3. delete_transient()

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

10.4. Hinweise und Notizen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

11. Benutzerdefinierte Artikeltypen

Bei aller Mächtigkeit ist der Inhalt das A und O von WordPress. Eine Website lebt schließlich von Inhalten. Den Artikeltyp „Beitrag“ (oder engl. „Post“) gab es schon immer. Danach kamen „Seiten“ hinzu. Seit Version 3.0. ist es auch möglich, eigene Artikeltypen anzulegen.

Derzeit existieren fünf feste „Artikeltypen“. Diese sind:

  • post
    Die Beiträge werden in der Regel nach Datum umgekehrt sequenziell geordnet. Aus Beiträgen können immer auch
    Feeds erstellt werden.
  • page
    Seiten sind den Beiträgen sehr ähnlich, sind aber in der Regel eher “statisch“. Sie sind meist nicht
    nach Datum sortiert, können jedoch hierarchisch geordnet und mithilfe von Seiten-Templates unterschiedlich
    gelayoutet werden.
  • attachment
    Zu Deutsch etwa „Anhang“. Damit sind die Dateien gemeint die in die Mediathek hochgeladen wurden.
  • revision
    Revision/Überarbeitung. Damit wird es möglich, dass auch ältere Inhalte jeglicher Artikeltypen jederzeit
    zurückgeholt werden können (ähnlich einem Backup-System).
  • nav_menu_item
    Navigationsmenü-Elemente. Sie sind ein gutes Beispiel dafür, was mit benutzerdefinierten Artikeltypen alles
    angestellt werden kann.

11.1. Benutzerdefinierten Artikeltypen erstellen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

11.2. Capabilities in benutzerdefinierten Artikeltypen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

11.3. Post Type entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

11.4. Hilfsfunktionen für benutzerdefinierte Artikeltypen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

11.5. Frontend-Loop mit benutzerdefinierten Artikeltypen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 12 – Benutzerdefinierte Taxonomien (Taxonomy API)

Das Wort “Taxonomie“ stammt aus dem griechischen und bedeutet so viel wie „Ordnung“. Im Wesentlichen erlauben Taxonomien es ,Objekte zu gruppieren.

In WordPress könnten Sie einen benutzerdefinierten Artikeltyp namens
books in die Genres wie z.B. „Sachbücher“ und/oder „Romane“ einteilen. Das Genre wären dann die Taxonomie.

Die Bezeichnungen der Taxonomien werden als „Terme“ (zu deutsch etwa „Ausdrücke“) bezeichnet. „Sachbuch“ wäre im Beispiel oben also ein Term.

WordPress liefert im Originalzustand zwei Taxonomien aus:

  • Kategorien und
  • Schlagwörter.

Die Kategorie-Taxonomie (engl. “category“) erlaubt die Gruppierung anhand von Kategorien. Die
Schlagwörter-Taxonomie (engl.
“tag“) eigentlich auch. Jedoch ist die Eingabe bei letzterem freier (man gibt Schlagwörter sozusagen on-the-fly direkt ein). Aus den Schlagwörtern formt WordPress durch ein Widget dann eine so genannte Schlagwörter-Wolke.

12.1. Taxonomien registrieren

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.2. Taxonomien entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.3. Registriertes Taxonomie zurückgeben

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.4. Registrierte Taxonomien zurückgeben

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.5. Taxonomie für ein Objekt erstellen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.6. Taxonomie von Objekt entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.7. Hilfsfunktionen für Taxonomien

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

12.8. Taxonomien im Frontend

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 13 – Benutzerdefinierte Ausdrücke (Terms API)

Am Kapitelanfang habe ich Ihnen ja bereits mitgeteilt, dass es Taxonomien und Terme gibt. In unseren Beispielen wäre „Genre“ die Taxonomie, ein möglicher Term etwa „Sachbuch“.

In diesem Kapitel geht es um die Terme, die Sie in WordPress anhand einer Fülle von Funktionen bearbeiten können. Zusammengefasst bilden diese Funktionen die so genannte Terms API.

Terme an sich werden meist direkt in einem Blogbeitrag oder einer Seite und dort in einer speziellen Metabox erstellt und mit dem jeweiligen Artikel verknüpft. Das ist aber nicht zwingend notwendig. Terme können auch zu anderen Objekten hinzugefügt werden. Zum Beispiel zu Benutzern.

13.1. Einen neuen Term erstellen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.2. Überprüfen ob ein Term existiert

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.3. Anzahl der Terme einer Taxonomie ausgeben

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.4. Term aus der Datenbank auslesen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.5. Term anhand verschiedener Daten lesen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.6. Terme einer Taxonomie auslesen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.7. Hierarchisch gelistete Kind-Terme auslesen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.8. Eltern und Kind Beziehung von Termen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.9. Term löschen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.10. Term aktualisieren

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.11. Alle Objekte eines Terms zurückgeben

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.12. Term-Objekt-Verbindungen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.13. Arbeiten mit Termen im Frontend

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

13.14. Ausnahmefall: Kategorien und Schlagwörter

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 14 – CSS und JavaScript API

Für eigene Plugins sind meist auch eigene JavaScript- sowie CSS-Dateien nötig. WordPress bringt die entsprechenden Funktionen und Hooks bereits mit und vereint diese in einer eigenen API. Ich nenne sie vereinfacht „CSS und JavaScript API“. Intern ist es allerdings so, dass die so genannte „Dependency API“ werkelt. Wie der Name schon sagt verwaltet sie Abhängigkeiten zwischen einzelnen Dateien. Dies ist auch der Grund warum Sie niemals JavaScripte und CSS-Dateien selbst durch eigenen Code einbinden sollen. Es kann dadurch zu unerwarteten Fehlern kommen die sich nur schwer Debugger lassen.

Wie diese API im Detail funktioniert, wollen wir in diesem Kapitel genauer erläutern. Dazu erweitern wir das Plugin aus Kapitel 3.5, welches wir „Drafts for Friends“ genannt hatten. Wie Sie sicherlich noch wissen, gibt es aktuell keine Möglichkeit, die „Drafts“ wieder zu löschen. Und genau das wollen wir hier mittels JavaScript und durch den Einsatz von jQuery lösen.

14.1. CSS- und JS Hooks

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

14.2. JavaScript

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 15 – Cronjobs

Wenn Sie schon einmal mit Linux oder einem Linux-ähnlichem System gearbeitet haben, kennen Sie die Cronjobs vielleicht bereits. Ein so genannter Cron-Daemon ist ein Hintergrunddienst, der dafür sorgt, dass Prozesse zeitbasiert ausgeführt werden können. Meist handelt es sich dabei um regelmäßig wiederkehrende Aufgaben, die man dann „Cronjobs“ nennt.

15.1. Cronjob anlegen/planen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

15.2. Cronjob entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

15.3. Prüfen ob Cronjob bereits geplant wurde

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

15.4. Eigene Zeitintervalle festlegen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

15.5. Einzelnen Cronjob planen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

15.6. Cronjob neu planen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 16 – Rewrite API

Was WordPress von jeher so populär machte war, dass es relativ einfach erlaubte, die URL-Struktur zu verändern. Man navigiert unter Einstellungen auf den Menüpunkt Permalinks und verändert die Einstellung so, bis sie passt.

Nützlich war das vor allem für die Suchmaschinen-Optimierung gedacht. Google und Co. wollten schon sehr früh „schöne URLs“ bekommen. Und WordPress machte es möglich. Im inneren werkelt dafür jedoch ein sehr komplexer Algorithmus, den Sie gleich etwas näher kennen lernen werden.

Die Rewrite-API wird intern von vielen Teilen des WordPress-Kerns benutzt. Neue und bestehende Posttypen wie Beiträge und Seiten nutzen sie beispielsweise. In der Grundeinstellung wird – bei aktivierten Permalinks – die URL-Struktur eines Artikels ungefähr so aussehen:

https://ihre-seite.com/%year%/%monthnum%/%day%/%postname%/

Die einzelnen Bereiche, wie z.B. %year%, werden dann durch den Inhalt aus dem Beitrag ersetzt. Ruft man die URL im Browser auf, nutzt WordPress die Daten um daraus eine Datenbank-Abfrage zu erstellen und findet dann exakt einen Beitrag der dann angezeigt werden kann:

  • Eingabe: https://ihre-seite.com/2018/04/02/rewrite-api
  • Jahr: 2018
  • Monat: 04
  • Tag: 02
  • Post-Name: rewrite-api

Natürlich klappt das ganze auch mit Custom Post Types oder Termen (wie Kategorien und Schlagwörtern). Diese bekommen allerdings eine so genannte Slug-Bezeichnung in der URL vorangestellt. Die Standard-Kategorie in WordPress hat z.B. die URL http://ihre-seite.com/category/allgemein/.

Das category in der URL ist wichtig, damit WordPress in der richtigen Datenbank-Tabelle nach dem Wort allgemein suchen kann.

Wenn Sie WooCommerce – ein Shopping-Plugin – installieren, erhalten Sie vor allen URLs ein product vorangestellt. Und zwar um den gleichen Effekt zu erzielen.

16.1. So funktioniert ein Rewrite

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.2. Eine neue Rewrite Regel anlegen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.3. Neue Rewrite Variablen anlegen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.4. Rewrite-Variablen abrufen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.5. Rewrite-Variablen setzen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.6. Rewrite-Variable entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.7. Rewrite-Cache leeren

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.8. Plugin fertigstellen (Zwischenkapitel)

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.9. Eine neue Permalink-Struktur anlegen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.10. Eine Permalink-Struktur entfernen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

16.11. Url zur Post-ID auflösen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17. Metadata-API

Nach der schweren Kost (RewriteAPI) gibt es jetzt hoffentlich eine etwas einfacher zu verstehende API. Nämlich die Metadata-API. Sie ist ein standardisierter Weg um Schlüssel-Wert-Paare zu WordPress-Objekten zu speichern. Intern nutzt WordPress diese API um zusätzliche Daten zu Kommentaren, Beiträgen, Termen, und Benutzern zu speichern die so in der Datenbank-Tabelle keinen Platz hätten.

Ein populäres Beispiel ist das Beitragsbild welches zu einem Blogbeitrag eingestellt werden kann. Man wählt ein entsprechendes Bild aus der Mediathek aus und verknüpft es mit dem Beitrag (dem Objekt). Im Hintergrund werkelt hier die Metadata-API zusammen mit der Datenbank-Tabelle wp_postmeta. Sie legt einen neuen Eintrag in der Datenbank an und schreibt folgende Daten:

  • Objekt-ID
    In diesem Fall die Post-ID.
  • Meta-Key
    In diesem Fall den String _thumbnail_id.
  • Meta-Value
    In diesem Fall die Media-ID des hochgeladenen Bildes.

17.1. Metadaten anlegen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17.2. Metadaten updaten

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17.3. Metadaten auslesen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17.4. Metadaten löschen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17.5. Metadaten anhand einer Meta-ID bearbeiten

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17.6. Helfer-Funktionen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

17.7. Meta-Schlüssel registrieren

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

18. Database API

Auf die „Datenbank API“ bin ich im Kapitel der Plugin-Sicherheit schon einmal eingegangen. Eigentlich gibt es in WordPress aber keine „Database API“. Wie Sie mittlerweile ja wissen, laufen die meisten Datenbank-Anfragen über die globale Variable namens $wpdb. Sie enthält die Ursprungs-Instanz der Klasse wpdb, deren Verbindung WordPress ganz am Anfang aufbaut. Somit müssen nicht alle Plugins und/oder Themes eine separate Datenbank-Verbindung aufbauen und/oder unterschiedliche Zugänge verwalten.

Grundsätzlich kann diese globale Instanz für alle möglich Datenbank-Abfragen verwendet werden. Selbst eine zweite Datenbank-Verbindung können Sie mit der Klasse wpdb aufbauen. Aber schauen wir uns das Schritt für Schritt an.

Hinweise

Beachten Sie, dass ich in diesem Kapitel nicht jede einzelne Methode der Klasse wpdb erklären werde. Sondern nur die von denen ich denke, dass sie für Ihre tägliche Arbeit nötig sind. Viele Methoden werden immerhin auch nur intern benutzt. Falls Sie mögen, können Sie sich die Datei wp-includs/wp-db.php genauer anschauen, wenn Sie nähere Informationen benötigen.

Beachten Sie, dass WordPress zuerst versucht, die MySQLi-Extension von PHP zu nutzen. Ist diese nicht vorhanden, wird die – veraltete – MySQL-Extension benutzt.

18.1. Wichtige Klassen-Parameter

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

18.2. Wichtige Klassen-Methoden

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

18.3. Eine Verbindung aufbauen und schließen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

18.3. Datenbank auswählen

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

18.4. Beispiel

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

18.5. Weitere Datenbank-Methoden

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

Kapitel 19 – Best Practices

Von den unzähligen Funktionen, Methoden und Klassen in WordPress gibt es einige, schöne Helferlein. Denn man muss – wie so oft erwähnt – nicht immer das Rad neu erfinden. Stattdessen kann man auf vorhandenes ganz einfach zugreifen. Und darum soll es in diesem Kapitel gehen.

19.1. Konsequenz im Layout

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

19.2. Errorhandling

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

19.3. Nützliche WordPress Funktionen die kaum jemand kennt

Dieses Kapitel ist teil der Online-Ausgabe. Werden Sie jetzt Mitglied um diesen Teil zu lesen.

20. Nichts verpassen

Ich hoffe, Sie hatten Spaß beim Durchstöbern der Leseprobe.

Aber das war’s noch lange nicht. WordPress ist mittlerweile zu einem umfangreichen Framework geworden. Es bringt sehr viele Funktionen und Klassen mit, auf die Sie während Ihrer Programmierung zugreifen können. Viele Code-Teile sind zu „Application Programming Interfaces“ (APIs) zusammengefasst und sind Thema des zweiten Bandes. Der zweite und letzte Teil ist aktuell zu etwa 60% fertig gestellt (Stand Februar 2017).

Falls Sie sich für die Online-Mitgliedschaft entscheiden, können Sie bereits jetzt all neuen Kapitel online lesen. Und es kommen monatlich neue Inhalte hinzu.

Der zweite Band wird ebenfalls im eBook-Format erscheinen, sobald der Inhalt fertiggestellt und lektoriert wurde.

Weiterhin viel Spaß beim Coden.

Ihr Dipl.-Ing. (FH) Florian Simeth

Wenn Sie darüber informiert werden möchten, wann der zweite und letzte Band erscheint, dann tragen Sie sich doch zum WordPress-Entwickler Newsletter ein. Das geht hier:

  1. http://w3techs.com/technologies/overview/contentmanagement/all/
    Stand: Dezember 2013
    Stand: Oktober 2014 ↩︎
  2. https://twitter.com/post_status/status/805160669733654528
    ↩︎
  3. http://de.wikipedia.org/wiki/GNUGeneralPublicLicense
    Stand: 2. Januar 2014
    Stand: 2. Januar 2014 ↩︎
  4. http://www.phpbench.com/ Stand: 2. Januar 2014. ↩︎
  5. http://www.php.net/ChangeLog-5.php#5.3.0 Stand:
    3. Januar 2014 ↩︎
  6. http://www.php.net/ChangeLog-5.php#5.5.0 Stand:
    3. Januar 2014 ↩︎
  7. https://core.trac.wordpress.org/browser/tags/4.7.1/src/wp-includes/post.php#L3496
    ↩︎
  8. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L378-L400
    ↩︎
  9. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L477-L518
    ↩︎
  10. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/admin-bar.php#L68-L100
    ↩︎
  11. https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-admin/includes/user.php#L121
    ↩︎
  12. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L540-L556
    ↩︎
  13. https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-includes/default-filters.php#L209
    ↩︎
  14. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L558-L569
    ↩︎
  15. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L520-L538
    ↩︎
  16. https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-includes/plugin.php#L447
    ↩︎
  17. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L323-L332
    ↩︎
  18. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L365-L376
    ↩︎
  19. https://codex.wordpress.org/Plugin_API/Action_Reference/pre_get_posts#Exclude_categories_on_your_main_page
    ↩︎
  20. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L141-L208
    ↩︎
  21. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/admin-bar.php#L973-L983
    ↩︎
  22. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L42-L113
    ↩︎
  23. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L210-L249
    ↩︎
  24. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/class-wp-query.php#L2383-L2391
    ↩︎
  25. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L251-L283
    ↩︎
  26. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/default-filters.php#L137
    ↩︎
  27. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L285-L307
    ↩︎
  28. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L115-L139
    ↩︎
  29. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L309-L321
    ↩︎
  30. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/plugin.php#L334-L363
    ↩︎
  31. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/functions.php
    ↩︎
  32. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-admin/admin.php#L192-L212
    ↩︎
  33. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-admin/admin.php#L212 ↩︎
  34. https://github.com/WordPress/WordPress/blob/4.7-branch/wp-includes/post.php#L3974-L3993
    ↩︎