Share
Im vorigen Artikel dieser Serie haben wir endlich mit der Vorbereitung der Grundlagen für das Plugin begonnen, das wir schreiben werden.
Insbesondere haben wir uns die Dateiorganisation, die Komponenten und die tatsächlichen Details des Plugins angesehen. Wir haben auch den Code entfernt, den wir in diesem Tutorial ausfüllen werden.
Neben der Tatsache, dass unser Plugin tatsächlich etwas unternimmt, werden wir bei der Arbeit mit dem Plugin über eine Reihe von objektorientierten Prinzipien, Techniken und Ideen sprechen.
Beachten Sie, dass wir in diesem Tutorial nur sehr wenige Dokumentationen machen werden. Die Details dazu haben wir im vorherigen Artikel behandelt. aber wir werden reden Mehr darüber in dem folgenden Artikel.
Wie bei den übrigen Artikeln in dieser Reihe, sollten Sie unbedingt alles, was wir bisher in der Reihe behandelt haben, auf den neuesten Stand bringen, da alles, was wir tun, auf den vorherigen Themen aufbaut.
Als Referenz haben wir behandelt:
Nachdem wir gesagt haben, lass uns da weitermachen, wo wir aufgehört haben.
Wenn es um das Schreiben von Software geht - unabhängig vom verwendeten Paradigma -, geschieht dies nicht linear. Das heißt, wir schreiben nicht unbedingt am Startpunkt des Programms. Oft - wenn auch nicht immer - ist dies einer der letzten Teile, die wir richtig machen.
Nachdem dies gesagt ist, beginnen wir mit der Arbeit an jeder Datei, aus der das Plugin besteht, auf eine Art und Weise, die sinnvoll ist, wenn wir das Plugin durcharbeiten. Damit meine ich, dass die Dinge beim Durcharbeiten dieses Artikels zunächst als verstreut erscheinen, aber hoffentlich etwas klarer werden, wenn wir uns jede Datei ansehen.
Die erste Klasse, die wir abschließen werden, befindet sich in Includes / class-single-post-meta-manager-loader.php. Wenn Sie sich an den vorherigen Artikel erinnern, ist diese Klasse für die Koordinierung von Aktionen und Filtern zwischen dem Core-Plugin und der Verwaltungsklasse verantwortlich.
In gewissem Sinne stellt es einen Wrapper für die native Hook-API von WordPress bereit. Es erlaubt uns jedoch, unsere Klassen zu entkoppeln (und damit eine Trennung der Bedenken durchzusetzen), so dass sich jeder auf einen bestimmten Zweck spezialisieren kann.
Zuerst werfen wir einen Blick auf die Klasse:
Accentsconagua
Aktionen = Array (); $ this-> filters = array (); public function add_action ($ hook, $ component, $ callback) $ this-> actions = $ this-> add ($ this-> aktionen, $ hook, $ component, $ callback); public function add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> add ($ this-> filters, $ hook, $ component, $ callback); private Funktion add ($ hooks, $ hook, $ component, $ callback) $ hooks [] = array ('hook' => $ hook, 'Komponente' => $ Komponente, 'callback' => $ callback); $ hooks zurückgeben; public function run () foreach ($ this-> filtert als $ hook) add_filter ($ hook ['hook']), array ($ hook ['Komponente'], $ hook ['callback'])); foreach ($ this-> fungiert als $ hook) add_action ($ hook ['hook']), array ($ hook ['Komponente'], $ hook ['callback'])); An diesem Punkt der Serie sollten Sie einige wichtige Dinge über die Klasse bemerken, basierend auf den Diskussionen, die wir bisher in der Serie geführt haben.
geschützt Attributionen, auf die sich jeweils beziehen Arrays wie im Konstruktor definiert. Eine ist für Aktionen bestimmt, die andere für Filter.Öffentlichkeit Funktionen. Die eine ist so konzipiert, dass sie leicht Aktionen hinzufügen kann, die andere ist so konzipiert, dass sie leicht Filter hinzufügen kann. Beachten Sie, dass jede Komponente drei Komponenten akzeptiert: den Hook-Namen, das Hauptobjekt, das die aufzurufende Funktion hat, und die Funktion, die während der eigentlichen Ausführung des Hooks aufgerufen werden soll. Weitere Informationen zu Aktionen und Filtern finden Sie in dieser Referenz.Privatgelände Funktion, die verwendet wird, um die beiden vorherigen zu vereinfachen Öffentlichkeit Funktionen, so dass wir eine einzige Stelle haben, um den Haken zum richtigen Array hinzuzufügen.Lauf Funktion ist diejenige, mit der alle definierten Haken verbunden werden. Dies ist, was alle unsere benutzerdefinierten Funktionen in WordPress registriert.Während wir den Rest des Plugins weiterentwickeln, wird diese bestimmte Klasse verwendet.
Dieser Teil des Plugins enthält alle Dateien, die sich im Ordner befinden Administrator Verzeichnis. Wenn Sie sich an den vorherigen Artikel erinnern, verfügen wir über eine primäre Klasse, ein Stylesheet und eine einzelne Datei, die zum Rendern der Ansicht des Inhalts verwendet wird.
Wir werden uns jede dieser Dateien ansehen, damit sie ab der Core-Admin-Klasse verwendet werden.
Dies ist die Kernklasse, die für die Registrierung der Stylesheets, der Meta-Box und der Datei verantwortlich ist, die den Inhalt der Meta-Box darstellen soll.
Werfen wir einen Blick auf den vollständigen Code und dann prüfen wir, was er tut.
version = $ version; public function enqueue_styles () wp_enqueue_style ('single-post-meta-manager-admin', plugin_dir_url (__FILE__). 'css / single-post-meta-manager-admin.css', array (), $ this->) Version, FALSCH); public function add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'single post-Meta-Manager', Array ($ this, 'render_meta_box'), 'post', 'normal', 'core') ; public function render_meta_box () required_once plugin_dir_path (__FILE__). 'partials / single-post-meta-manager.php'; Dies ist eine relativ einfache Klasse, die davon ausgeht, dass Sie vertraut sind wp_enqueue_style und add_meta_box. Wenn nicht, überprüfen Sie die verknüpften Artikel und kehren Sie dann zu diesem Beitrag zurück.
Als Nächstes sehen wir uns an, was der Rest der Klasse macht:
Privatgelände Attribut, mit dem die Version des Plugins verfolgt wird. Dieser Wert wird an den Konstruktor der Klasse übergeben und wird in erster Linie verwendet, um sicherzustellen, dass beim Einreihen unserer Stylesheets die neueste Version des Plug-Ins mit einbezogen wird, um sicherzustellen, dass alle Dateien, die beim Ausführen zwischengespeichert werden, verworfen werden dieses Plugin.Öffentlichkeit Funktion, die zum Registrieren des Stylesheets verwendet wird, das dem Dashboard zugeordnet ist, und wir haben eine öffentliche Funktion, mit der der Meta-Box eine hinzugefügt wird Post Typ Dashboard.Wenn wir später alles genauer sehen werden, stellen Sie möglicherweise fest, dass die Funktion, mit der die Stylesheets in eine Warteschlange gestellt werden, nirgendwo anders referenziert wird. Dies ist, wo die Lader Klasse wird schließlich ins Spiel kommen.
Einige Entwickler schreiben das Markup für Meta-Box-Views in PHP gerne und speichern sie in wirklich langen Strings.
Ich bin kein Fan dieses Ansatzes, da Ansichten (oder Teilbilder oder Vorlagen oder wie auch immer Sie sie anrufen möchten) normalerweise zur Anzeige von Daten verwendet wurden und daher aus mehr Markup bestehen als alles andere. Zu diesem Zweck denke ich, dass sie ihre eigene Akte sein sollten.
In diesem Fall möchten wir eine Datei haben, die alle mit dem aktuellen Beitrag verknüpften Metadaten in a darstellt Tabelle Element, das in der Meta-Box enthalten ist.
Das Markup für diese Datei sieht folgendermaßen aus:
$ post_meta_value) ?>
Obwohl das Markup und das minimale PHP, das in dieser Datei enthalten ist, relativ selbsterklärend sein sollten, ist es das tut abhängig von Ihrem Wissen über die get_post_meta und get_the_ID Funktionen.
Sobald alle Metadaten des Beitrags abgerufen wurden, durchlaufen wir die Informationen (mithilfe eines der viel früher behandelten Schleifenkonstrukte) und zeigen dann sowohl den Metaschlüssel als auch den Wert an.
Das letzte, was wir für den Inhalt in der Meta-Box tun müssen, ist die Bereitstellung der Stile im Stylesheet, die wir in die Core-Admin-Klasse eingereiht haben.
Um das zu tun, bearbeiten wir css / simple-post-meta-manager.css.
# Einzel-Post-Meta-Manager-Daten width: 100%; # single-post-meta-manager-data .key font-weight: fett;
Das ist natürlich sehr einfach. Es bietet nichts Außergewöhnliches, als die Breite der Tabelle auf 100% ihres Containers zu setzen, und die Metaschlüsselwerte werden angezeigt.
Aber das ist genug für das, was wir jetzt tun wollen.
An diesem Punkt müssen wir die Core-Plugin-Datei definieren. Dies ist die Datei, die die Version des Plugins definiert, den Slug des Plugins (der normalerweise bei der Internationalisierung sowie für andere Funktionen verwendet wird), den Loader instanziiert und alle erforderlichen Hooks in WordPress registriert.
Schauen wir uns den Code an und prüfen ihn dann, wenn wir alles definiert haben:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ this-> load_dependencies (); $ this-> define_admin_hooks (); private Funktion load_dependencies () required_once plugin_dir_path (dirname (__FILE__)). 'admin / class-single-post-meta-manager-admin.php'; required_once plugin_dir_path (__FILE__). 'class-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); private Funktion define_admin_hooks () $ admin = new Single_Post_Meta_Manager_Admin ($ this-> get_version ()); $ this-> loader-> add_action ('admin_enqueue_scripts', $ admin, 'enqueue_styles'); $ this-> loader-> add_action ('add_meta_boxes', $ admin, 'add_meta_box'); public function run () $ this-> loader-> run (); public function get_version () return $ this-> version; Die Klasse enthält die folgenden Attribute:
Die oben genannten Attribute werden alle im Konstruktor festgelegt, es gibt jedoch auch Aufrufe zu mehreren anderen Funktionen.
Lastabhängigkeiten wird verwendet, um alle Dateien zu importieren, die in diesem Plugin verwendet werden, z. B. Admin Manager und Loader.define_admin_hooks So nutzen wir den Loader, um die in unserer Admin-Klasse definierten Funktionen zu koordinieren, die unsere Stile und unsere Meta-Box mit WordPress erfassen. So trennen wir die Anliegen unseres Plugins und stellen sicher, dass jede Klasse zu einem einzigen Zweck dient.Lauf ist die Funktion, die alles in Bewegung setzt, so dass alle Funktionen des Plugins aktiv sind, wenn sie in WordPress aktiviert werden.Außer, dass uns noch ein abschließendes Stück fehlt: Wie können wir die Core-Plugin-Klasse tatsächlich instanziieren und den Prozess starten??
Dazu nutzen wir eine Datei, die sich im Stammverzeichnis des Plugin-Verzeichnisses befindet. Einige Leute nennen dies eine Plugin-Bootstrap-Datei, manche nennen es einen Bootloader und andere nennen es die Haupt-Plugin-Datei.
Wie auch immer Sie sich entscheiden, es ist die Datei, die sich bei WordPress registriert und alles in Bewegung setzt. Werfen wir einen Blick auf den Code und prüfen wir anschließend, was er macht:
Lauf(); run_single_post_meta_manager ();
Der Codekommentar oben in der Datei ist dafür verantwortlich, WordPress mitzuteilen, dass das Plugin vorhanden ist, und ihm genügend Informationen über das Plugin zu geben, damit es im Dashboard angezeigt werden kann.
Die erste Bedingung, die Sie sehen, verhindert, dass direkt auf die Plugin-Datei zugegriffen wird. Dies ist nichts weiter als eine Sicherheitsmaßnahme.
Zum Schluss rufen wir an einmalig benötigt Um die Kern-Plugin-Datei einzuschließen, die wir oben betrachtet haben, definieren wir eine Funktion und instanziieren die Single_Post_Meta_Manager und danach rufen wir an Lauf Das ist, was alles in Bewegung setzt.
Zum Schluss rufen wir die Funktion auf, die wir am Ende der Datei definiert haben. Dies startet den Prozess und erweckt das Plugin zum Leben.
An diesem Punkt haben wir die Funktionalität unseres Plugins abgeschlossen. wir sind aber noch nicht fertig. Es gibt noch eine weitere Sache, die wir tun müssen, um sicherzustellen, dass wir alle bewährten Methoden befolgen, die in einem Plugin enthalten sind, und das Dokumentation bereitstellt.
Im nächsten Beitrag werden wir eine Pause von den längeren Artikeln zum Schreiben von Code nehmen, die WordPress-Dokumentationsstandards durchsehen und dann das Plugin dokumentieren, sodass wir die gesamte Funktionalität vollständig abrunden.
Laden Sie in der Zwischenzeit das Beispiel-Plugin herunter, erkunden Sie, wie alles zusammenpasst, und hinterlassen Sie Kommentare und Fragen zu unserer bisherigen Arbeit.
