WordPress Plugin objektorientiert programmieren, Teil 6: Fazit

Mit dem hier vorgestellten Ansatz, habe ich mir eine Blaupause für WordPress Plugins erstellt, mit der ich schnell ein neues Plugin schreiben kann.

Durch die Verwendung von namespaces kann ich auf Präfixe weitestgehend verzichten und meine Methoden nennen, wie ich will, ohne in Konflikte zu geraten. Natürlich müssen für Tabellen, die evtl. in die DB geschrieben werden, weiterhin passende Präfixe gefunden werden.

Der kleine autoloader erspart mir die Verwendung von ‚require‘ oder ‚include‘.

Ich könnte dieses Grundgerüst noch um einiges umfangreicher gestalten, z.B. um eine DB-Klasse, welche alle Verbindungen zur Datenbank handelt und so eine weitere saubere Schnittstelle zu WordPress bieten würde.
Oder um eine RBAC Funktionalität, welche die WordPress Rechteverwaltung erweitert.

Natürlich fehlt im Beispiel auch noch die ganze CRUD Funktionalität, welche ich in einem späteren Beitrag darstellen möchte.

Aber ich denke, dieses kleine Grundgerüst veranschaulicht bereits die Möglichkeit mit diesem Ansatz, sauberen, leicht verständlichen, gut wartbaren und erweiterbaren Code zu schreiben.

zurück zu Teil 5: Routing und der BaseController

WordPress Plugin objektorientiert programmieren, Teil 5: Routing und der BaseController

Ich verwende eine einfache Basis Klasse, um die einzelnen Actions der Controller richtig zu routen. Im Konstruktor der Klasse wird $_GET ausgelesen und dann die passenden Actions ausgeführt.

Ansonsten enthält die Klasse noch eine Methode namens ‚view‘, die dafür sorgt, dass jeweils die richtige view gerendert wird. Die einzelnen Actions werden in der BasisKlasse lediglich als Methodenrümpfe angelegt und in den einzelnen Controllern dann mit Leben gefüllt.

Das geht bestimmt eleganter, aber ich finde diesen Ansatz leicht nachvollziehbar und vor allem leicht anwendbar.

In den einzelnen Controllern sorgen dann die Actions (wie ‚index‘, ‚create‘, etc.) für das Aufrufen der richtigen Models, welche die Inhalte liefern, sowie das rendern der zugehörigen views.

zurück zu Teil 4: Die Init Klasse

weiter zu Teil 6: Fazit

WordPress Plugin objektorientiert programmieren, Teil 4: die Init Klasse

Die Init Class stellt die Verbindung zwischen dem Plugin und WordPress her. Mit add_action wird das Backend Menu und alle Scripts and Styles eingebunden. Die Frontendfunktionalität wird über add_shortcode bereit gestellt.
Alles weitere wird an Controller delegiert.

Die Controller erben alle von einem BaseController, der das Routing übernimmt.

In der Init Klasse könnte natürlich noch mehr passieren. Z.B. könnte ich hier eine Session starten oder über ‚get_role‘ und ‚add_cap‘ bestimmte Rechte setzen.

Zurück: Teil 3: die ActivatePlugin Klasse

Weiter zu Teil 5: Routing und der BaseController

WordPress Plugin objektorientiert programmieren, Teil 3: Die ActivatePlugin Klasse

Die ActivatePlugin Klasse übernimmt alle Aufgaben, die während der Aktivierung des Plugins nötig sind. Im konkreten Beispiel erstellt die Klasse einige Tabellen in der Datenbank. Angenommen, das Plugin soll ein Tool zur Projektverwaltung werden, dann könnten die Tabellen in einem ersten Schritt in etwa so aussehen:

 

Im Kontstruktor wird die Methode createTables() aufgerufen, die dann zwei Tabellen erstellt. Für ein echtes Projektmanagement Tool wäre das natürlich bei weitem nicht ausreichend, aber zur Anschauung sollte das ausreichend sein.

zurück zu Teil 2: WordPress Plugin objektorientiert programmieren: die entry-class

weiter zu Teil 4: Die Init Klasse

 

WordPress Plugin objektorientiert programmieren, Teil 2: die entry-class

Wie sieht die Eingangsdatei meines WordPress Plugins aus?

Nun, zunächst einmal, wie üblich steht oben die Beschreibung. Dann folgt die Definition der Eingangsklasse, welche am Ende, sofern noch nicht geschehen, instanziiert wird.

Diese Klasse übernimmt folgende Aufgaben:

  1. Sie stellt einen Aktivierungshook bereit.
  2. Sie instanziiert eine Init Klasse, welche das Handling des Plugins übernimmt.
  3. Sie stellt eine autoload Methode bereit.

Daneben sollte sie noch einen Deaktivierungs- und einen Uninstallhook enthalten. Das ist aber im Beispiel nicht implementiert, würde aber analog zum Aktivierungshook funktionieren (register_deactivation_hook, bzw. register_uninstall_hook).

Die komplette Datei sieht dann in etwa so aus:

 

Ziemlich selbsterklärend, denke ich.

Im nächsten Teil erkläre ich die Aufgabe der ActivatePlugin Klasse und anschließend die Init Klasse.

Zurück zu Teil 1: WordPress Plugin objektorientiert programmieren mit MVC pattern, namespaces und autoloading

Weiter zu Teil 3: Die ActivatePlugin Klasse

 

WordPress Plugin objektorientiert programmieren, Teil 1: das MVC pattern, namespaces und autoloading

In letzter Zeit habe ich ein paar kleine WordPress Plugins geschrieben und dabei versucht objektorientiert zu arbeiten. Dabei ist eine Art Vorlage entstanden, die ich jetzt leicht nutzen kann.
Durch die Verwendung von namespaces brauche ich keine Präfixe mehr für meine Methoden und allein das sehe ich als hinreichendes Argument, Plugins nur noch so zu schreiben.

Plugin Grundstruktur

Für mich hat sich dabei folgender Aufbau heraus gebildet:

Basic WP Plugin Structure

 

 

 

 

 

Diese Struktur kann natürlich erweitert werden, z.B. um einen Backend- und Frontendordner, etc.. Im assets Ordner befinden sich die Unterordner ‚css‘, ‚img‘ und ‚js‘. Aber auch da kann natürlich mehr oder anderes hin, wie z.B. ein ‚fonts‘ Ordner. Die Ordner ‚controllers‘, ‚models‘ und views sollten klar sein, wobei der views Ordner Unterordner enthält, welche die Struktur abbilden:

Views Folder with Sub Folders

 

 

 

 

 

Entsprechend finden sich die Klassen ProjectController und TaskController im Ordner Controllers sowie die Klassen Project und Task im Ordner models. Im Ordner ‚core‘ finden sich die Klassen ‚ActivatePlugin‘ sowie ‚DeactivatePlugin‘ und eine ‚Init‘ Klasse. Da packe ich bei Bedarf auch noch Helper Klassen hin, die vorwiegend statische Methoden enthalten.

Und alles nimmt seinen Ausgangspunkt in der Klasse ‚OopPlugin‘. Diese Klasse beschreibe ich im nächsten Beitrag zu diesem Thema.

 

Ich habe mich an folgenden Beiträgen orientiert (und hoffe, keinen vergessen zu haben):

Grundaufbau eines WordPress Plugins

Object-Oriented WordPress Plugin Development

WordPress Plugin Development: Ein Plugin erstellen

Using Namespaces In WordPress Development

https://code.tutsplus.com/tutorials/using-namespaces-and-autoloading-in-wordpress-plugins-part-1–cms-27157 und davon natürlich die ganze Serie. 😉

Weiter zu Teil 2: WordPress Plugin objektorientiert programmieren: die entry-class

 

 

Spaceship Operator, The Null Coalesce Operator and the Splat Operator

<=>

that’s it for the spaceship operator. Consider its use with usort

The null coalesce operator is used like this (e.g. check if a get var is set):

$id = $_GET[‚id‘] ?? 0;

This is much shorter than $id = isset($_GET[‚id‘]) ? $_GET[‚id‘] : 0;

Splat Operator for unpacking an array:

See also: php.net

For more information and other new features in PHP 7 visit:
http://php.net/manual/en/migration70.new-features.php

Splat Operator was introduced in php 5.6 as far as I remember.

Scripts, Styles und Google Fonts richtig in WordPress einbinden

Angenommen ich erstelle ein eigenes Theme oder ein Child Theme in WordPress und möchte dort eigene Javascript Dateien, Stylesheets und Google Fonts verwenden.  Dann gibt es eine WordPress typische und ganz einfache Art und Weise dies zu tun.

Scripts, Styles und Google Fonts richtig in WordPress einbinden weiterlesen