Share
Nel precedente articolo di questa serie, abbiamo finalmente iniziato a preparare le basi per il plugin che stiamo per scrivere.
Nello specifico, abbiamo dato un'occhiata all'organizzazione dei file, ai componenti e ai dettagli reali di ciò che il plug-in farà. Abbiamo anche cancellato il codice che compileremo in questo tutorial.
Oltre a fare in modo che il nostro plugin faccia effettivamente qualcosa, parleremo di una serie di principi, tecniche e idee orientati agli oggetti diversi mentre lavoriamo attraverso il plugin.
Nota che in questo tutorial faremo pochissima documentazione. Abbiamo coperto i dettagli su questo nel precedente articolo; tuttavia, parleremo Di Più su di esso nell'articolo che segue questo.
Come per il resto degli articoli di questa serie, assicurati di recuperare tutto ciò che abbiamo trattato finora nella serie, poiché tutto ciò che stiamo facendo si basa sugli argomenti precedenti.
Per riferimento, abbiamo coperto:
Detto questo, riprendiamo da dove eravamo rimasti.
Quando si tratta di scrivere software, indipendentemente dal paradigma che viene utilizzato, non lo si fa in modo lineare. Cioè, non stiamo necessariamente scrivendo al punto di partenza del programma. Spesso, anche se non sempre, questa potrebbe essere una delle ultime parti che abbiamo ragione.
Detto questo, inizieremo a lavorare su ogni file che compone il plugin in un modo che abbia senso mentre lavoriamo attraverso il plugin. Con ciò intendo che mentre lavoriamo attraverso questo articolo, le cose possono sembrare sparse all'inizio, ma dovrebbe diventare un po 'più chiaro, mentre guardiamo ogni file.
La prima lezione che stiamo per completare si trova in includes / class-single-post-meta-manager-loader.php. Se si richiama l'articolo precedente, questa classe è responsabile del coordinamento delle azioni e dei filtri tra il plugin principale e la classe di amministrazione.
In un certo senso, fornisce un wrapper attorno alle API hook native di WordPress; tuttavia, ci permette di deconcentrare (e quindi far rispettare una separazione di preoccupazioni) le nostre classi in modo che ognuna possa specializzarsi su uno scopo specifico.
Per prima cosa, diamo un'occhiata alla classe:
Accentsconagua
actions = array (); $ this-> filters = array (); funzione pubblica add_action ($ hook, $ component, $ callback) $ this-> actions = $ this-> add ($ this-> actions, $ hook, $ component, $ callback); public function add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> add ($ this-> filters, $ hook, $ component, $ callback); funzione privata add ($ hooks, $ hook, $ componente, $ callback) $ hooks [] = array ('hook' => $ hook, 'componente' => $ componente, 'callback' => $ callback); restituire $ ganci; public function run () foreach ($ this-> filtri come $ hook) add_filter ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); foreach ($ this-> azioni come $ hook) add_action ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); A questo punto della serie, dovresti notare alcune cose fondamentali sulla classe basate sulle discussioni che abbiamo avuto fino ad ora nella serie.
protetta attribuzioni ciascuna delle quali si riferisce a array come definito nel costruttore. Uno è designato per le azioni, l'altro per i filtri.pubblico funzioni. Uno è progettato per aggiungere facilmente azioni, l'altro è progettato per aggiungere facilmente filtri. Si noti che ciascuno accetta tre componenti: il nome dell'aggancio, l'oggetto principale che ha la funzione da chiamare e la funzione da chiamare durante l'effettiva esecuzione del gancio. Per ulteriori informazioni su azioni e filtri, consultare questo riferimento.privato funzione che viene utilizzata per semplificare i due precedenti pubblico funziona in modo tale che abbiamo un posto unico per aggiungere il gancio alla matrice corretta.correre la funzione è quella usata per cablare tutti i ganci definiti. Questo è ciò che registrerà tutte le nostre funzioni personalizzate con WordPress.Mentre continuiamo a costruire il resto del plugin, vedremo questa particolare classe in uso.
Questa parte del plugin contiene tutti i file che si trovano nel Admin directory. Se ricordi dal precedente articolo, abbiamo una classe primaria, un foglio di stile e un singolo file usati per rendere la visualizzazione del contenuto.
Esamineremo ciascuno di questi file in modo che vengano utilizzati a partire dalla classe di amministrazione principale.
Questa è la classe principale responsabile della registrazione dei fogli di stile, della meta-box e del file che renderà il contenuto della meta-box.
Diamo un'occhiata al codice completo e quindi esamineremo cosa sta facendo.
versione = $ versione; 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-> versione, FALSE); public function add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', array ($ this, 'rendering_meta_box'), 'post', 'normal', 'core') ; public function render_meta_box () require_once plugin_dir_path (__FILE__). 'Parziali / single-post-meta-manager.php'; Questa è una classe relativamente semplice che presume che tu abbia familiarità con wp_enqueue_style e add_meta_box. In caso contrario, rivedere gli articoli collegati e quindi tornare a questo post.
Successivamente, diamo un'occhiata a ciò che sta facendo il resto della classe:
privato attributo che viene utilizzato per tracciare la versione del plugin. Questo valore viene passato al costruttore della classe e viene utilizzato principalmente per assicurarsi che stiamo includendo la versione più recente del plug-in quando accodiamo i nostri fogli di stile per assicurarci di interrompere tutti i file che potrebbero essere memorizzati nella cache durante l'esecuzione questo plugin.pubblico funzione usata per registrare il foglio di stile associato al dashboard e abbiamo una funzione pubblica che è usata per aggiungere una meta-scatola al inviare digitare dashboard.Anche se vedremo che tutto si svolgerà in modo più dettagliato in seguito, si potrebbe iniziare a notare che la funzione che accoda i fogli di stile non viene referenziata da nessun'altra parte. Questo è dove il caricatore la classe finirà per entrare in gioco.
Alcuni sviluppatori amano scrivere il markup per le viste meta box in PHP e memorizzarle in stringhe veramente lunghe.
Non sono un fan di questo approccio perché le viste (o partial o template, o qualsiasi altra cosa si voglia chiamare) e tipicamente utilizzate per visualizzare i dati e quindi consistono in più markup di ogni altra cosa. A tal fine, penso che dovrebbero essere i loro file.
In questo caso, vogliamo avere un file che mostri tutti i metadati associati al post corrente in a tavolo elemento che è contenuto nella meta-scatola.
Il markup per questo file è simile al seguente:
$ post_meta_value) ?>
Anche se il markup e il PHP minimo contenuto in questo file dovrebbero essere relativamente auto-esplicativi, lo è fa dipende dalla tua conoscenza del get_post_meta e get_the_ID funzioni.
Una volta recuperati tutti i metadati del post, passiamo in rassegna le informazioni (usando uno dei costrutti del ciclo che abbiamo trattato molto prima) e poi mostriamo sia la meta chiave che il valore.
L'ultima cosa che dobbiamo fare per il contenuto nella meta-box è fornire gli stili nel foglio di stile che abbiamo messo in coda nella classe di amministrazione principale.
Per fare ciò, modificheremo css / semplice post-meta-manager.css.
# single-post-meta-manager-data width: 100%; # single-post-meta-manager-data .key font-weight: bold;
Ovviamente, questo è molto semplice. Non fornisce niente di speciale se non impostando la larghezza della tabella al 100% del suo contenitore e mette in grassetto i valori della meta chiave.
Ma questo è abbastanza per quello che stiamo cercando di fare ora.
A questo punto, dobbiamo definire il file del plugin principale. Questo è il file che definisce la versione del plugin, lo slug del plugin (che viene normalmente utilizzato nell'internazionalizzazione e altre funzionalità), crea un'istanza del Loader e registra tutti i hook necessari con WordPress.
Diamo un'occhiata al codice, quindi esaminalo una volta che abbiamo definito tutto:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ This-> load_dependencies (); $ This-> define_admin_hooks (); private function load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / classe-single-post-meta-manager-admin.php'; require_once plugin_dir_path (__FILE__). 'Class-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); funzione privata 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; La classe contiene i seguenti attributi:
Gli attributi di cui sopra sono tutti impostati nel costruttore, ma ci sono anche chiamate a diverse altre funzioni.
load_dependencies viene utilizzato per importare tutti i file utilizzati in questo plug-in come Admin Manager e Loader.define_admin_hooks è il modo in cui sfruttiamo il Loader per coordinare le funzioni definite nella nostra classe Admin che accodano i nostri stili e la nostra meta-box con WordPress. Questo è il modo in cui separiamo le preoccupazioni del nostro plugin e ci assicuriamo che ogni classe sia un unico scopo.correre è la funzione che mette tutto in movimento in modo che tutte le funzionalità del plugin siano attive quando vengono attivate all'interno di WordPress.Tranne che ci manca ancora un pezzo finale: in che modo possiamo istanziare la classe del plug-in core e dare il via al processo?
Per fare ciò, sfruttiamo un file che si trova nella radice della directory dei plugin. Alcuni lo chiamano un file di bootstrap plugin, alcuni lo chiamano boot loader e alcuni lo chiamano il file plugin principale.
Qualunque cosa tu scelga di chiamare, questo è il file che si registra con WordPress e che mette tutto in moto. Diamo un'occhiata al codice e poi esamineremo cosa farà in seguito:
correre(); run_single_post_meta_manager ();
Il commento del codice nella parte superiore del file è responsabile di dire a WordPress che il plugin esiste e fornendogli informazioni sufficienti sul plug-in in modo che possa visualizzarlo all'interno della dashboard.
Il primo condizionale che vedi impedisce l'accesso diretto al file del plugin. Questo non è altro che una semplice misura di sicurezza.
Infine, facciamo una chiamata a require_once per includere il file del plugin principale che abbiamo visto sopra, e quindi definiamo una funzione e istanziamo il Single_Post_Meta_Manager e dopo di che chiamiamo correre che è ciò che mette tutto in movimento.
Infine, effettuiamo una chiamata alla funzione che abbiamo definito alla fine del file. Questo dà il via al processo e porta il plugin alla vita.
A questo punto, abbiamo completato la funzionalità del nostro plugin; tuttavia, non abbiamo ancora finito. C'è ancora un'altra cosa che dobbiamo fare per essere sicuri di seguire tutte le best practice che vanno in un plugin e che sta fornendo documentazione.
Nel prossimo post, faremo una pausa dagli articoli più lunghi del codice di scrittura, esamineremo gli standard di documentazione di WordPress e quindi documenteremo il plug-in in modo da completare completamente tutte le sue funzionalità.
Nel frattempo, scarica il plug-in di esempio, esplora il modo in cui tutto combacia e assicurati di lasciare commenti o domande sul lavoro fino a quel momento.
