Programmazione orientata agli oggetti in WordPress creazione del plugin I

A questo punto della serie, lo siamo finalmente in grado di iniziare a costruire il nostro plugin usando le tecniche orientate agli oggetti che abbiamo imparato finora nella serie.

Se ti stai solo unendo a noi, ti consiglio vivamente di recuperare la serie finora; altrimenti, rischi di perdere alcuni dei punti chiave che dimostreremo mentre costruiamo il plugin nei prossimi articoli.

1. Un introduzione
2. Classi
3. tipi
4. Strutture di controllo: dichiarazioni condizionali
5. Strutture di controllo: cicli
6. Funzioni e attributi
7. Scopo

Bene, quindi con quello detto, è finalmente il momento di iniziare a scrivere codice. Prima di iniziare, è importante capire che la creazione di un plug-in o qualsiasi tipo di software per tale materia richiede una serie di passaggi e, anche se scriveremo un po 'di codice in questo particolare articolo, non saremo aggiungendo un sacco di funzionalità fino ad avere lo scaffolding o la base del plugin.

Per fare ciò, dobbiamo rivedere diverse cose:

1. Definire le caratteristiche del plugin che stiamo per scrivere,
2. Condividi tutto ciò che potremmo non costruire in questa prima versione,
3. Discutere l'architettura e l'organizzazione dei file del plugin.

Quindi copriamo quei punti molto velocemente, e poi entreremo nei dettagli del plugin.

Post Meta Viewer

Nei prossimi articoli svilupperemo un plug-in che introdurrà un post meta box nella visualizzazione dell'editor di post singoli che visualizza tutti i metadati associati al post corrente.

1. Le caratteristiche

Il plugin sarà di sola lettura in quanto è possibile solo vista i meta dati associati al plugin. Non saremo in grado di introdurre nuovi metadati, almeno non per la prima versione.

Le altre funzionalità sono che verrà visualizzato in un formato pulito e organizzato in modo da poter identificare facilmente la chiave e i valori per l'ID post. Introdurremo anche un'ancora che ci consentirà di copiare una riga di codice che ci consentirà di effettuare una chiamata al pezzo di informazione sotto forma di get_post_meta ($ post_id, $ meta_key, $ meta_value);.

2. Un forte 1.0

Prima di andare avanti, ci sono un sacco di funzionalità che potremmo implementare in questo plugin. 

Potremmo introdurre la capacità di:

• aggiungi nuovi meta dati post personalizzati
• aggiornare i metadati dei post esistenti
• cancella i metadati dei post esistenti
• ordina le colonne per meta chiavi
• ordina le colonne in base ai metadati
• … e così via

Ma in linea con la filosofia della creazione di un "forte 1.0", stiamo costruendo una base snella e focalizzata su cui possiamo continuare a costruire il plug-in come lo riterrò opportuno dopo questa serie.

Forse copriremo alcune delle funzionalità sopra citate prima della fine della serie, forse vorrai introdurre il tuo set di funzionalità. Va bene comunque. La linea di fondo è che stiamo andando a costruire un nucleo forte su cui possiamo continuare a scorrere per espandere la funzionalità.

3. L'architettura e l'organizzazione dei file

Quindi, con tutto ciò che detto, parliamo prima attraverso i punti più alti del plugin, poi daremo un'occhiata a come organizzeremo i file e i componenti del plugin.

• Il plug-in richiede un file plug-in di base che funge da caricatore di avvio (o file di bootstrap) per registrarsi a WordPress e caricare i componenti del plug-in.
• Il plugin avrà bisogno di una classe che coordina gli hook e i callback utilizzati nel plugin. Ciò contribuirà a separare le funzionalità dagli hook e dalle classi responsabili della visualizzazione effettiva del lavoro, il che ci consente di assicurarci che ciascuna delle nostre classi sia specializzata e che svolga idealmente un singolo lavoro.
• Il plug-in avrà bisogno di una classe che sarà responsabile della visualizzazione delle informazioni nel dashboard post singolo che renderà effettivamente la meta-box. 
• Avremo bisogno di una classe di plugin di base che registrerà tutte le dipendenze e fornirà informazioni sulla versione del plugin, è a conoscenza del caricatore e della funzionalità di amministrazione per registrare le informazioni tra i due componenti.
• E infine, avremo bisogno di alcuni fogli di stile per assicurarci che le informazioni siano buone all'interno della dashboard.

Suona confuso? Speriamo di vedere e dare un'occhiata alla struttura del file e al codice di esempio di base per aiutare a continuare a dare più senso.

Detto questo, diamo uno sguardo ad alto livello ai componenti che interagiranno tra loro, quindi daremo un'occhiata a come saranno organizzati i file. Dopodiché, inseriremo il codice per il plug-in su cui compileremo il prossimo articolo.

Componenti per plugin

In particolare, il plugin consisterà dei seguenti componenti - o file - che costituiranno la fonte del plugin. Dopo aver dato un'occhiata all'elenco dei file, daremo un'occhiata a un diagramma di come tutti i pezzi interagiranno.

• singolo-post-meta-manager.php è il file primario che registra il plugin con WordPress e imposta tutto in movimento.
• class-single-post-meta-manager-admin.php è il file responsabile della registrazione e dell'accodamento dei fogli di stile nonché della visualizzazione degli elementi dell'interfaccia utente che conterranno i metadati dei post.
• singolo-post-meta-manager-admin.css è il foglio di stile che modellerà l'interfaccia utente.
• class-single-post-meta-manager-loader.php è il file che coordinerà azioni e filtri tra il plugin principale e la classe di amministrazione.
• class-single-post-meta-manager.php è il file principale del plugin che conserva le informazioni sulla versione del plugin, le informazioni sullo slug del plugin, i riferimenti al loader e il file in cui viene indicato al caricatore quali oggetti e funzioni sono responsabili della visualizzazione dell'interfaccia utente amministrativa.
• README.md fornisce le solite istruzioni su come iniziare con il plugin.
• CHANGES.md fornisce un elenco di modifiche che si verificano in ogni versione del plug-in che rilasciamo.

A seconda del livello di esperienza con la programmazione orientata agli oggetti, questo può sembrare un gran numero di file per un insieme relativamente semplice di funzionalità; tuttavia, c'è ancora dell'altro: non lasceremo tutti questi file nella radice della directory dei plugin.

Invece, faremo un ulteriore passo avanti e organizzeremo anche le cose nelle directory appropriate. Una volta esaminato, daremo un'occhiata all'organizzazione dei componenti sotto forma di diagramma, quindi esamineremo il codice che fornisce lo scaffolding per il plug-in.

Organizzazione file

L'organizzazione dei file è relativamente semplice e probabilmente è meglio dimostrata attraverso l'uso di un'immagine:

Per essere chiari, ecco la suddivisione di ciò che vedi nello screenshot qui sopra:

• admin / class-single-post-meta-manager-admin.php
• admin / css / single-post-meta-manager.admin.css
• includes / class-single-post-meta-manager-loader.php
• includes / class-single-post-meta-manager.php
• le lingue/
• singolo-post-meta-manager.php
• CHANGES.md
• README.md
• LICENSE.txt

Questo è importante da riconoscere e ci sono un paio di punti nel codice in cui registreremo le dipendenze ed è importante sapere dove le dipendenze sono così che possiamo fornire loro i percorsi appropriati.

Costruire il plugin

A questo punto, siamo pronti per iniziare a eliminare le classi che useremo. Ci sono diverse cose importanti da notare sul codice che stai per vedere:

• Stiamo solo eliminando le classi e i metodi: non introdurremo alcuna funzionalità reale in questo articolo.
• Alla fine dell'implementazione, il plugin dovrebbero appare nel dashboard di WordPress e può essere attivato (anche se non accadrà nulla).
• Nonostante il fatto che ritengo che la documentazione sia la chiave per lo sviluppo della qualità, non introdurremo i commenti in questo articolo perché c'è un compromesso da fare: questo articolo può diventare eccessivamente lungo con una quantità straordinaria di dettagli, oppure possiamo continuare per seguire passo dopo passo ogni aspetto di questa serie. Sto optando per il secondo in modo da non essere sopraffatti dalla quantità di informazioni.

Detto questo, se avete domande sul codice, sentitevi liberi di lasciare commenti su questo; tuttavia, potrei dire di aspettare fino al prossimo articolo per vedere la risposta.

Ora, sul codice.

Il Core Plugin File

Il file del core plug-in è responsabile della registrazione del plug-in con WordPress e, in definitiva, sarà responsabile dell'importazione della classe del plug-in core (che esamineremo in un po ') e in effetti l'impostazione del plug-in in movimento.

Si noti che il condizionale che abbiamo nella parte inferiore del file. Ciò assicurerà che il file del plugin non sia accessibile direttamente dal browser web.
File amministrativi
Tutti questi file risiedono nel Admin directory come elencato sopra.
La classe di amministrazione Meta Manager Single Post
Questa classe accoderà il foglio di stile e renderà la meta-box che verrà utilizzata per visualizzare il meta meta specificato.
versione = $ versione;  public function enqueue_styles ()  public function add_meta_box () 
In questa classe, si noti che ha un singolo attributo protetto per $ versione del plugin. Questo attributo è impostato nel costruttore della classe.
Vedremo come questo si inserisce più tardi nel codice.
Il foglio di stile di Meta Manager a post singolo
Al momento, non c'è alcun codice da visualizzare per questo particolare file; tuttavia, andare avanti e aggiungerlo al admin / css sottodirectory come quello che useremo per modellare la dashboard.
include
Questi sono i file di plugin di base che sono responsabili del coordinamento delle informazioni tra i vari hook e l'area amministrativa del plugin.
Caricatore di Meta Manager a post singolo
Questa classe verrà utilizzata dalla classe plugin principale per coordinare tutti gli hook esistenti nel plug-in e la classe amministrativa che abbiamo definito sopra.
Nota che nella classe sopra, abbiamo contrassegnato gli attributi come protetta. Questo è fatto in modo che questa classe abbia accesso ai suoi attributi, ma non altre classi.
Inoltre, siamo andati avanti e fatto questo nel caso in cui suddividiamo questa particolare classe in una futura iterazione del plugin.
Meta Manager Single Post
Infine, abbiamo la classe plugin principale che è responsabile del caricamento delle dipendenze, dell'impostazione delle impostazioni locali e del coordinamento degli hook.
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.1.0';  private function load_dependencies ()  funzione privata define_admin_hooks ()  public function run ()  public function get_version () return $ this-> version; 
Nota nel codice sopra, abbiamo aggiunto protetta attributi, un paio di privato funzioni e a pubblico funzione usata come getter che useremo mentre continuiamo a costruire il plugin.
Nel prossimo articolo, passeremo molto tempo in questa classe in quanto questo è il punto di ingresso per cui si verificano molte funzionalità.
In arrivo
In questo articolo abbiamo coperto molto materiale, ma ovviamente c'è molto altro da fare. Oltre a fornire documentazione per le nostre funzioni, è necessario implementare effettivamente funzionalità che rendano questa impalcatura viva.
Nel prossimo articolo della serie, faremo proprio questo, dopo di che concentreremo la nostra attenzione sulla documentazione del codice.
Come accennato in precedenza, non esitate a lasciare domande e / o commenti sul codice qui sopra. Per coloro che sono interessati, puoi sempre consultare lo stato attuale del progetto su GitHub.
Fino al prossimo articolo!



		
			
	   
	




Codice