In questo tutorial illustrerò una tecnica che ti consente di utilizzare un file modello per tutte le tue esigenze HTML! Non avrai più bisogno di "echo" le stringhe all'interno delle tue funzioni, o ti preoccuperai di inserire e uscire da PHP solo per generare dei markup.
Ho passato molti anni a utilizzare i framework MVC (come Zend e al giorno d'oggi Laravel), dove è una buona pratica separare la 'logica di programmazione' (funzioni o metodi) dalla 'vista' (il markup HTML risultante). Questo sempre porta a una base di codice più manutenibile ed è in realtà molto più facile da scrivere. Avere questo background mi ha spinto a trovare una soluzione simile nello sviluppo di plugin per WordPress! Non è niente di speciale: è solo un piccolo "aiuto" che ti permetterà di rimuovere tutti gli snippet HTML e di "scappare" dalle tue funzioni e metterli al sicuro nel loro file "modello".
Quindi, spero che questo tutorial ti sembri interessante e, senza ulteriori indugi, iniziamo!
Diamo un calcio a questo tutorial dando un'occhiata esattamente a ciò che stiamo per migliorare.
È molto comune vedere qualcosa di simile all'interno di un plugin: (questo frammento proviene in realtà da uno dei miei tutorial su questo sito: p)
add_shortcode ('faq', function () $ posts = get_posts (array (// Ottieni le FAQ Custom Post Type 'numberposts' => 10, 'orderby' => 'menu_order', 'order' => 'ASC', 'post_type' => 'faq',)); $ faq = ''; // Apri il contenitore foreach ($ post come $ post) // Genera il markup per ogni domanda $ faq. = Sprintf ((''; // Chiudi il contenitore restituisce $ faq; // Restituisce l'HTML. );% 1 $ s
% 2 $ s'), $ post-> post_title, wpautop ($ post-> post_content)); $ faq. = '
Beh niente, davvero. Ma potrebbe essere più pulito, più facile da scalare e più manutenibile!
Correndo dall'alto verso il basso, possiamo vedere che tutti all'interno di una singola funzione siamo:
Ora puoi benissimo guardare questo e pensare "Grande affare! Sono solo alcune righe di HTML, qual è il problema?" Per certi versi sei benissimo nei tuoi diritti di pensare in questo modo. Ma ricorda, al momento ci sono solo 17 linee di codice - cosa succede quando espandi / migliora il plugin? Cosa succede quando il tuo plug-in cresce a 50/100/1000 righe di codice (o più!). Sarai comunque contento di avere stringhe HTML puntate sulla tua funzione in vari luoghi? Cosa succede quando si vuole esportare un codice HTML che necessita di qualche 'scappatoia' per funzionare correttamente all'interno del codice PHP?
Spero che questo approccio alla creazione e alla pubblicazione di HTML Markup possa diventare molto problematico! Senza contare che diventa molto difficile mantenere e migliorare l'HTML quando è sparpagliato.
Quindi, con tutto questo in mente, mi sono preso la briga di cambiare il modo in cui pensi di emettere l'HTML in WordPress. Per sempre.
Ok, andiamo a fare i conti con questo.
Il nostro plugin è semplice, include solo il vista
classe in modo che possiamo usarlo in uno qualsiasi dei nostri altri plugin.
/ * view_renderer.php * / include ('View.php');
Ok, ora che abbiamo incluso il vista
classe, è ora di costruirlo.
Qui abbiamo una classe chiamata vista
con una singola funzione statica chiamata rendere
(questo ci permetterà di usare la sintassi Visualizza :: render ($ template)
da qualsiasi punto all'interno dei nostri plugin) e richiede due parametri:
$ filePath
- Il percorso del file di modello. Non dimenticare che terremo i nostri modelli all'interno del vista cartella che abbiamo creato in precedenza$ Viewdata
- Qualsiasi variabile a cui vorremmo avere accesso all'interno del modello (molto più su questo più avanti)Copia il codice qui sotto in view.php:
Prima di tutto stiamo controllando se il $ Viewdata
varible ha un valore (cioè abbiamo inviato qualcosa da utilizzare nel modello?). Se lo fa, estraiamo il contenuto (ne parleremo più avanti)
Quindi stiamo facendo uso del buffer di output di PHP. Ci consente di analizzare un file PHP e salvare il contenuto in una variabile
Alla fine restituiamo la stringa
Nota: non dimenticare di attivare il plug-in ora dal pannello di amministrazione
Sembra piuttosto semplice eh? Esattamente! Ma mentre sembra essere solo una piccola funzione molto semplice, in realtà ci offre il lusso di poter scrivere i nostri plugin in modo super organizzato, scalabile e manutenibile. Per favore, permettimi di dimostrare ...
Creiamo un semplice plugin chiamato Slider
** Nota: questo è solo a scopo dimostrativo. Sentiti libero di usare il tuo plugin qui.
OK, ora aggiungeremo uno shortcode che recupererà gli ultimi 5 post e li visualizzerà in un elenco con il titolo e il contenuto. (Per motivi di brevità, aggiungeremo la nostra classe di plugin e i nostri hook di azione nello stesso file di estensione, ma per favore non farlo nella "vita reale": p)
/ ** * Aggiungi lo Shortcode (PHP 5.3 e successivi) * / add_shortcode ('slider', function () return Slider :: display (););
Questo ci permetterà semplicemente di usarlo [Cursore]
in qualsiasi post / pagina e verrà visualizzato il risultato di Slider :: display ()
display()
Metodoclass Slider public static function display () // Restituisci HTML QUI.
/ * * Ottieni gli ultimi 5 post * / public static function display () $ posts = get_posts (array ('numberposts' => 5));
Ora abbiamo una serie di inviare
oggetti e siamo pronti a costruire il nostro codice HTML scorrendoli tra loro. Ma non stiamo per iniziare semplicemente a inserire stringhe HTML nella nostra funzione qui! Invece, passeremo la matrice di oggetti a un file di modello e avremo tutto il codice HTML generato in modo dannoso.
Questo modello manterrà tutti i nostri markup e ci permetterà di accedere ai dati noi inviare ad esso più tardi.
Ogni volta che vogliamo utilizzare qualsiasi variabile all'interno dei nostri modelli, possiamo semplicemente inviare loro impostando un valore nel $ Viewdata
array. Chiunque abbia familiarità con l'utilizzo dei framework MVC si sentirà a proprio agio con questo approccio.
$ viewData = array ('posts' => $ post);
L'array chiave Qui ('messaggi
') è importante perché è così che faremo riferimento ai dati all'interno del modello. (Puoi chiamarlo come preferisci, ma attenersi a qualcosa che abbia senso).
Ok, quindi abbiamo visto come recuperare gli ultimi 5 post e come inviare quella matrice di oggetti al modello, ora è il momento di arricchire il file modello.
= $post->post_title?>
= $post->post_content?>
Ah! Quanto è bello avere tutto quel markup nel proprio file separato, lontano dalla nostra logica di recupero e programmazione dei dati? Grande, lo so! La parte più importante di questo approccio è che stiamo sempre e solo "accedendo" ai dati dalle variabili all'interno del modello. Tutta la 'logica' dovrebbe essere fatta all'interno del metodo che chiama il modello. Questo porta a un flusso di lavoro molto bello in quanto hai una completa separazione delle preoccupazioni.
Immagina quanto sarà facile ora quando sarai pronto per costruire su questo plugin. Niente più concatenazione di stringhe e caratteri di escape all'interno delle funzioni.
Ok, abbiamo visto tutte le parti dei componenti, vediamo come si combina tutto per permetterci di eseguire il rendering di un modello e ottenere una stringa indietro (che possiamo quindi tornare al nostro shortcode):
vista
la classe esiste$ template
Vista :: render ()
metodo e passare i due parametri necessariIn questo caso, noi ritorno il risultato del modello renderizzato perché è così shortcodes lavoro. Ma se tu avessi bisogno di eco i risultati invece (ad esempio, quando crei una pagina di amministrazione, il callback si aspetta che l'output venga stampato direttamente), quindi sostituisce semplicemente ritorno con eco.
display()
Metodo in pienoclass Slider static $ template = '/templates/01.template.php'; display public function function () if (class_exists ('View')) // Ricevi gli ultimi 5 post $ posts = get_posts (array ('numberposts' => 5)); // Imposta visualizzazione dati $ viewData = array ('posts' => $ post); // Ottieni il percorso completo per il file del modello. $ templatePath = dirname (__FILE__). statica :: $ template; // Restituisce il rendering HTML reso View :: render ($ templatePath, $ viewData); else return "Stai tentando di eseguire il rendering di un modello, ma non siamo in grado di trovare la classe View";
Spero che tu possa apprezzare il livello di organizzazione che questo approccio ti permetterà! Adesso tuo display la funzione è responsabile solo della raccolta dei dati di cui ha bisogno e della restituzione del risultato del modello renderizzato.
Il nostro esempio sopra è di base come diventa. Anche così, è ancora un flusso di lavoro notevolmente migliorato. Ora diamo un'occhiata a un altro esempio che mostra quanto possa essere utile.
Supponiamo, ad esempio, che il tuo plug-in faccia uso di una meta-box personalizzata. Per farlo dovremmo:
Slider
classeclass Slider static $ metaBox = '/templates/metabox.template.php'; funzione pubblica __construct () add_action ('add_meta_boxes', array ($ this, 'add_some_meta_box')); / ** * Aggiunge il contenitore del meta box * / public function add_some_meta_box () add_meta_box ('some_meta_box_name', 'Alcuni Metabox Headline', array ($ this, 'rendering_meta_box_content'), 'post', 'advanced', ' alto ',); / ** * Rendering del contenuto della Meta Box * / public function render_meta_box_content () / ** Dal Codex ** / echo 'TEST OUTPUT - questo viene reso all'interno della meta-box.
'; // class // aggiunge la funzione hook action call_Slider () return new Slider (); if (is_admin ()) add_action ('load-post.php', 'call_Slider');
Dai un'occhiata al render_meta_box_content
metodo lì. È l'occasione perfetta per usare Viewer! Immagina un esempio più realistico come questo:
/ ** * Render contenuto Meta Box * / public function render_meta_box_content ($ post) $ name = get_post_meta ($ post-> ID, "nome"); $ fieldName = static :: $ fieldName; eco 'Il tuo nome:
'; eco ''; eco ''; eco '';
Urg! Certo, ha fatto il lavoro, ma è così difficile farlo in questo modo! Che ne dici invece di utilizzare il nostro View Renderer.
/ ** * Rendering contenuto Meta Box * / public function render_meta_box_content ($ post) $ viewData = array ('name' => get_post_meta ($ post-> ID, 'nome'), 'campo' => statico :: $ fieldName); $ templatePath = dirname (__FILE__). statica :: $ METABOX; echo View :: render ($ templatePath, $ viewData);
E nel file di modello:
Il tuo nome:
Potrebbe sembrare solo un piccolo vantaggio in questo esempio. Ma credimi, se tieni le tue preoccupazioni separate in questo modo, diventerai uno sviluppatore WordPress molto migliore abbastanza rapidamente.
Penso che ora probabilmente hai una buona comprensione di ciò che stiamo cercando di ottenere qui e ti esorto a provare a utilizzare questa tecnica quando crei plug-in in futuro. Spero che troverai la "separazione delle preoccupazioni" a tuo vantaggio.
Note dell'esercitazione:
Sarei interessato a sapere quali usi hai trovato per questa tecnica, quindi per favore condividi i commenti :)