Organisieren von WordPress-Typen, -Ansichten und -Abonnenten
Eines der Dinge, die ich regelmäßig versuche, ist die Optimierung der Art und Weise, wie ich WordPress-fokussierte Funktionen aufbaue. Ich habe kürzlich darüber gesprochen, dachte aber, ich würde es ein wenig weiter ausführen.
Das heißt, ich dachte, ich würde den Ansatz darlegen, den ich beim Erstellen von Dingen wie benutzerdefinierten Beitragstypen, Taxonomien, Metaboxen und so weiter verwende.
Betrachten Sie dies im Allgemeinen als eine Strategie, der ich folge, um Aspekte eines Projekts aufzubauen, das direkt mit WordPress verbunden ist, aber möglicherweise einige Komponenten erfordert, wie zum Beispiel:
- Klassen, die sich über verschiedene Hooks bei WordPress registrieren,
- Klassen, die Aufrufe bestimmter WordPress-APIs erfordern
- und Klassen, die eine benutzerdefinierte Ansicht erfordern.
Sicher, nicht alles, was mit WordPress verbunden ist, benötigt alle oben genannten Punkte (braucht zum Beispiel ein benutzerdefinierter Beitragstyp eine Ansicht? Nein. Aber eine Meta-Box tut es.)
Organisieren von WordPress-Typen
Nachdem dies gesagt ist, werde ich ein komplizierteres Beispiel wie eine Meta-Box nehmen und dann eine Art und Weise aufschlüsseln, wie es meiner Meinung nach implementiert werden kann. Ich werde die Dinge notieren, die ich für notwendig halte, und die Dinge, die optional sind.
Und wie gesagt, ich verwende eine Meta-Box als Beispiel, weil ich eine vorherige Referenz habe und dies den größten Arbeitsaufwand erfordert, während etwas anderes wie eine benutzerdefinierte Taxonomie möglicherweise nicht alle (nur eine Teilmenge) der Teile erfordert .
Nachdem dies gesagt ist, lassen Sie mich meinen Ansatz darlegen.
Wir brauchen Abonnenten
Ich habe genug über dieses bestimmte Muster gesprochen, bis zu einem Punkt, an dem ich einfach auf eine Definition davon verlinken werde. Wenn Sie diese Seite lesen, kennen Sie wahrscheinlich die verschiedenen Hooks und wie man sie in WordPress verwendet.
Foto von Alexander Andrews auf Unsplash
Aber der Grund, warum ich es erwähnen möchte, ist, dass Sie nicht daran denken, eine Funktion anzuschließen, die immer dann ausgelöst wird, wenn etwas passiert, sondern dass Sie an ein Objekt denken, das ein Ereignis abonniert, wenn es eintritt.
Das bedeutet, dass wir eine Art Abonnentenklasse benötigen.
WordPress-API-Klassen
Zweitens brauchen wir Klassen, die für die direkte Verbindung mit WordPress verantwortlich sind. Dies sind die Klassen, die die WordPress-API aufrufen und alles registrieren, wofür sie verantwortlich sind.
Das heißt, vielleicht werden sie einen benutzerdefinierten Beitragstyp definieren oder vielleicht, wie gesagt, sie werden eine Meta-Box definieren.
Sichten definieren
Schließlich ist es wichtig zu beachten, dass Sie für einige benutzerdefinierte Funktionen für den WordPress-Administrationsbereich (oder sogar öffentlich zugängliche Bereiche) möglicherweise eine Ansicht oder eine Vorlage oder einen Teil davon (ich bezeichne sie im Allgemeinen nur als Ansichten) einschließen möchten arbeiten, um die Daten für eine Metabox darzustellen.
Foto von Saketh Garuda auf Unsplash
Manchmal ist dies nur informativ. Manchmal erfordert dies, dass es an den Server zurückgesendet und die Daten serialisiert werden. Obwohl ich denke, dass es wirklich nützlich wäre, über letzteres zu sprechen, liegt es außerhalb des aktuellen Rahmens dieses Beitrags.
Vielleicht in einem zukünftigen Beitrag.
Klassen organisieren
Was das alles gesagt hat, wie würde es aussehen, das alles darzustellen? Zumindest schauen wir uns an:
- ein Abonnent,
- ein WordPress-Typ,
- eine Sicht
Und Sie könnten höchstens daran interessiert sein, Schnittstellen oder abstrakte Klassen zu definieren, um einen Vertrag zwischen den verschiedenen WordPress-Typen durchzusetzen. Dies ist auch ein gesundes objektorientiertes Prinzip, über das ich in einem zukünftigen Beitrag sprechen werde.
Lassen Sie uns jedoch zunächst darüber sprechen, wie Sie diese einrichten.
Der Abonnent
Einfach ausgedrückt, der Abonnent ist dafür verantwortlich, zuzuhören, wann immer WordPress ein Ereignis auslöst (ein Ereignis veröffentlicht). Und wenn es bemerkt, dass dies der Fall ist, löst es eine Funktion aus, die daran angeschlossen ist.
Dies ist im Allgemeinen im Registrierungsmuster definiert. Wenn Sie diesen Beitrag nicht gelesen haben, empfehle ich ihn, aber das Einrichten des Codes dafür ist ganz einfach:
<?php
class AcmeMetaBoxSubscriber extends AbstractSubscriber
{
public function __construct(string $hook)
{
parent::__construct($hook);
}
public function load()
{
(new AcmeMetaBox())->render();
}
}
Von dort aus wird die Funktion immer dann ausgelöst, wenn das Ereignis ausgelöst wird. Hier ist jedoch die Sache: Die Funktion muss Teil einer bestimmten Klasse sein. Daher die Notwendigkeit für den WordPress-Typ
Der WordPress-Typ
Ich betrachte die Arten von Dingen, die mit WordPress verbunden sind, gerne als WordPress-Typen (ähnlich wie unsere Programmiersprachen native Typen wie Strings und Integer haben). WordPress hat Taxonomien, Metaboxen, Menüs und so weiter.
Damit unser Abonnent richtig funktioniert, muss er auf unseren WordPress-Typ aufmerksam gemacht werden. In Übereinstimmung mit dem Meta-Box-Beispiel könnte es so aussehen:
<?php
class AcmeMetaBox extends AbstractMetaBox
{
public function render()
{
add_meta_box(
'acme-data',
'Acme Data',
[$this, 'display'],
$this->postType,
'normal',
'high'
);
}
public function display()
{
include_once plugin_dir_path(__FILE__).'Views/acme-data.php';
}
}
Dann müssen wir sicherstellen, dass die Registrierung diese Klasse kennt.
Die Aussicht
Schließlich müssen wir für eine Metabox sicherstellen, dass es eine Ansicht gibt, die zumindest Informationen anzeigt. Das Serialisieren von Informationen und das anschließende Aktualisieren der Ansicht für den Benutzer ist etwas anderes.
Aber wie könnte eine Aussicht aussehen? Einfach :
<div class="acme-data-metabox">
<?php echo __('Acme Data', 'acme-meta-box'); ?>
<p class="description">
This is the content of the metabox.
</p>
</div>
Es ist nur ein einfaches Markup, das dem Benutzer Informationen liefert.
Alles zusammenbinden
Wenn ich all dies zusammenfüge, habe ich normalerweise eine Plugin-Klasse, mit der alles beginnt. Wenn ein Projekt groß ist, kann es mehr als eines geben, aber in diesem Fall denke ich, dass es in Ordnung ist, mit einer einzelnen Klasse zu zeigen, wie es aussieht.
Also sieht die Haupt-Plugin-Klasse zunächst so aus:
<?php
class Plugin
{
private $registry;
public function __construct(Registry $registry)
{
$this->registry = $registry;
}
public function start()
{
array_map(function ($subscriber) {
add_action($subscriber->getHook(), [$subscriber, 'load']);
}, $this->registry->getRegisteredSubscribers());
}
}
Und der Bootstrap für das Plugin sieht so aus:
<?php
// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('acmeApiRegistry', function() use ($registry) {
return $registry;
});
// Register all of our objects with a basic registry.
$registry->add('acmeMetaBoxSubscriber', new AcmeMetaBoxSubscriber('add_meta_boxes'));
$plugin = new Plugin($registry);
$plugin->start();
Und von dort aus wird alles andere in Gang gesetzt.
Was ist mit erweiterten Funktionen?
Ich werfe diese Frage auf, weil ich in diesem Beitrag bereits ein wenig darüber gesprochen habe. Ich sprach nämlich von:
- die Idee, Daten an den Server zurückzusenden (und sie wahrscheinlich erneut zu lesen),
- und ich habe über die Verwendung von Schnittstellen gesprochen.
Beides Dinge, die es meiner Meinung nach wert sind, genauer untersucht zu werden. Aber bevor Sie dies tun, legen Sie den Grundstein dafür, wie ich diese Informationen organisiere, da sie insbesondere auf früheren Beiträgen wie dem Registrierungsmuster und dem Organisieren von WordPress-zentrierten Klassen über Metaboxen aufbauen .
