Plug-in-Ausführung ohne Abhängigkeit stoppen
Wenn Sie einen Großteil der WordPress-Plugin-Entwicklung aus einer objektorientierten Perspektive angehen, werden Sie irgendwann einen Punkt erreichen, an dem Sie nicht mehr viel direkt mit dem WordPress-Kern selbst interagieren.
Und das ist meiner Meinung nach auch gut so. Es ist ein Zeichen für eine Architektur, dass Sie Ihren Code richtig strukturieren. Das ist:
- Sie haben WordPress auf der Grundstufe,
- Sie haben eine Reihe von Klassen, die direkt über WordPress sitzen und für das Senden von Informationen zu und von WordPress zwischen dem Plugin verantwortlich sind.
- Und Sie haben den Rest Ihres Codes, der den Rest der Funktionalität umfasst.
Wie dies implementiert wird, kann variieren, aber im Allgemeinen stelle ich mir das so vor, wie ich eher an die Standard -N-Tier- Anwendung denke, bei der Sie die Datenschicht, die Anwendungsschicht und das Front-End haben.
Abgesehen von dieser Zeit haben Sie WordPress, eine Ebene für die Kommunikation mit WordPress und dem Rest Ihres Codes, und Sie wissen schon, den Rest Ihres Codes.
Wie ein Plugin organisiert sein kann.
Was passiert also, wenn Sie die Plugin-Ausführung stoppen möchten, wenn sie mit einer Abhängigkeit eines Drittanbieters interagieren muss und nur ausgeführt werden soll, wenn diese Abhängigkeit vorhanden ist?
Plug-in-Ausführung stoppen
Aufgrund der Natur von PHP und WordPress gibt es einige Möglichkeiten, dies zu tun. Der Code, den ich teilen werde, schreibt nicht vor, wie es zu tun ist.
Stattdessen ist dies eine Möglichkeit, dies zu tun (die aus etwas gezogen wurde, das sich in der Entwicklung befindet). Außerdem werde ich zeigen, wie es mit einigen anderen Komponenten der Plugins interagiert.
1 Der Konstruktor
Wenn Sie genügend Artikel über WordPress und objektorientierte Programmierung lesen, werden Sie wahrscheinlich feststellen, dass Konstruktoren nicht zum Definieren von Hooks verwendet werden sollten. Und ich stimme zu.
Es schafft ein unnötiges Maß an Kopplung und macht das Testen schwieriger. Was ist dann der Zweck eines Konstruktors in WordPress-basiertem Code?
Ich verwende es aus den gleichen Gründen, die Sie in jeder anderen Sprache erwarten würden: Um die Eigenschaften der Klasse zu initialisieren. Im folgenden Code sehen Sie drei Dinge:
- Ich initialisiere eine Eigenschaft,
- Ich überprüfe, ob eine Drittanbieter-Abhängigkeit besteht,
- Wenn nicht, dann füge ich eine Fehlermeldung hinzu,
- Ich aktualisiere die Eigenschaft.
Sicher, es ist verbose, aber es greift auch nicht auf cleveren Code zum Initialisieren von Werten zurück.
(Je älter ich werde, desto mehr mag ich bestimmten Code, da er leichter zu lesen, zu verstehen und schneller zu verwenden ist als die Alternative.)
2 Die Initialisierungsmethode
Da wir keinen Konstruktor verwenden, um mit WordPress-Hooks zu arbeiten, sollte diese Funktionalität im Kontext einer anderen Methode vorhanden sein.
Dies gibt uns einen dedizierten Platz, um diese Art von Funktionalität zu platzieren, sie vom Rest der Klasse zu entkoppeln und sie nur dann mit WordPress interagieren zu lassen, wenn die Methode explizit aufgerufen wird.
Aber denken Sie daran, dass der ganze Sinn dessen, worauf ich hinaus will, damit zu tun hat, die Ausführung eines Plugins zu stoppen – und nicht, wo Hooks zu platzieren sind.
Nehmen wir also an, die Abhängigkeit von Drittanbietern existiert nicht, was dann? Erinnern Sie sich, dass im Konstruktor eine Eigenschaft festgelegt wurde, mit der wir bestimmen können, ob wir mit dem Einrichten von Hooks fortfahren sollten oder nicht:
Und wenn das vorhanden ist, wird der Rest des Codes nicht ausgeführt.
Viele Worte, ein wenig Code
Es klingt nach einer Menge Erklärungen für so wenig Code.
Aber ein Teil davon soll auch versuchen zu vermitteln, wie wichtig es ist, Teile eines WordPress-basierten Projekts vom Rest des Kerns zu trennen, damit die Teile mit sich selbst interagieren können, ohne die ganze Zeit explizit mit dem Kern sprechen zu müssen.