Mentre iniziamo l'articolo finale della serie sulla creazione di pagine di amministrazione personalizzate di WordPress in WordPress, penso che sia importante ribadire che non si intende dire che dovremmo aggirare l'API Settings (o una qualsiasi delle API native).
In effetti, ogni API ha il suo posto e ovviamente ne usiamo molti attraverso questo codice. Ma è probabile che ci siano dei momenti in cui stai lavorando su un plug-in personalizzato o un'applicazione personalizzata e devi essere in grado di implementare un po 'di convalida, serializzazione, instradamento e così via personalizzati..
Ed è quello che abbiamo fatto in questa serie. Quindi, mentre andiamo avanti nel completare il nostro plugin, voglio assicurarmi che tu capisca che non sto sostenendo l'elusione di alcuna delle API native. Sto sostenendo l'utilizzo di quali API sono disponibili per i requisiti del tuo progetto.
A questo punto, presumo che tu sia coinvolto con gli articoli precedenti. In caso contrario, probabilmente non riuscirai a capire da dove veniamo e perché stiamo prendendo alcune delle decisioni che prendiamo in merito al codice.
Inoltre, perderai alcuni dei principi che abbiamo discusso in precedenza. In breve, consiglio di recuperare e tornare a questo articolo.
Detto questo (e parlando di requisiti), ci sono solo alcune altre cose che dobbiamo concludere in riferimento a questo plugin.
Nello specifico, abbiamo bisogno di:
Fortunatamente, la maggior parte del lavoro è stata fatta per noi. Abbiamo tutte le informazioni di cui abbiamo bisogno nel database. A questo punto, si tratta di introdurre funzionalità che lo faranno fare qualcosa con quei dati.
Come al solito, presumo che tu abbia l'ultima versione del codice sorgente e sei pronto per continuare con questa serie aggiungendo ad essa il resto del codice.
Detto ciò, iniziamo.
Prima di iniziare a scrivere il codice, voglio chiarire che il codice che andremo a scrivere è semplice, ma c'è un livello di refactoring che potrebbe essere necessario introdurre una volta raggiunto il punto di rendere le informazioni disponibili su entrambi back-end e front-end.
Questa è una buona cosa, però.
Non solo ci darà la possibilità di pensare in modo critico all'organizzazione del nostro codice, ma ci esporrà anche ad alcune tecniche aggiuntive orientate agli oggetti che non abbiamo mai visto in tutta la serie di tutorial finora.
Con questo in mente, cerchiamo di recuperare le informazioni dal database.
L'acquisizione delle informazioni dal database è un processo semplice. Dato che in precedenza abbiamo lavorato con funzioni come update_option
, questo dovrebbe essere molto facile.
Lavoreremo con get_option
. Richiede solo un singolo argomento, e questo è l'ID o la chiave che abbiamo usato per memorizzare le informazioni. Nel nostro caso, questo è tutsplus-custom-dati
. Se vuoi diventare creativo, puoi passare un secondo argomento opzionale che verrà restituito se le informazioni non vengono trovate.
Per mostrare come questo può essere usato, avrò la funzione restituire una stringa vuota in modo che abbiamo qualcosa valido da mostrare all'utente (anche se non è niente). Lo snippet di codice per fare ciò assomiglia a questo:
Ma questo solleva due domande:
- Dove va questo (specialmente se lo renderizzeremo in due punti nel plugin)?
- Non dovremmo convalidare questa informazione?
Vedremo la prima domanda un po 'più avanti nel tutorial. Innanzitutto, parliamo di convalida.
Convalidare le informazioni
C'è molto che si può dire sulla convalida in WordPress. Ma per mantenere questo tutorial il più semplice possibile, parleremo della validazione dell'input. Dopotutto, abbiamo a che fare con l'input dell'utente tramite un
ingresso
elemento, quindi ha senso.Puoi leggere tutto su di esso nel Codex, ma la convalida dell'input è spesso definita come la seguente:
La convalida dei dati è il processo per garantire che un programma funzioni su dati puliti, corretti e utili.Nell'ultimo articolo, abbiamo trattato il tema dell'igienizzazione, che è fondamentalmente facendo in modo che i dati siano puliti prima di essere inseriti nel database. Allo stesso modo, la convalida sta garantendo che sia pulito, sicuro e leggibile per i nostri utenti.
A tal fine, non è abbastanza appena per prendere le informazioni dal database. Dobbiamo anche convalidarlo. Nel caso del nostro plugin, i dati sono abbastanza semplici da sembrare eccessivo per la sua validazione; tuttavia, lo scopo dell'esercizio è di aiutare a sviluppare la mentalità su come dobbiamo procedere per disinfettare, salvare, recuperare, convalidare e visualizzare i dati.
Tecniche di convalida
E proprio come nel caso della sanitizzazione, WordPress offre alcune funzioni che rendono facile la convalida, in particolare per quanto riguarda la convalida dell'input. In questa situazione, possiamo essere aggressivi come vogliamo.
Nel nostro caso, potrebbe essere sufficiente solo da usare
esc_attr
durante il rendering delle opzioni. Se abbiamo permesso agli utenti di inserire qualunque tipo di HTML, quindi potremmo voler usarewp_kses
.Quest'ultima funzione potrebbe richiedere un tutorial tutto da solo, specialmente se sei nuovo su WordPress, quindi continueremo con il primo per i nostri scopi.
deserializzazione
In precedenza nel progetto, abbiamo creato una classe specifica per il salvataggio delle informazioni nel database. Abbiamo chiamato questa classe
Serializer
. Per coloro che non ricordano esattamente cosa fa:
admin_post
aggancia e salva le informazioni che vengono inviate al server.Ma non vogliamo sovraccaricare quella classe con una responsabilità che non ha senso. E visto che mostreremo queste informazioni sia nella pagina delle opzioni che nel front-end del sito, sarebbe ovvio che abbiamo una classe per deserializzare il valore e renderlo accessibile all'intera applicazione WordPress.
Quindi nella radice della directory dei plugin, crea a condivisa
directory e aggiungere un file chiamato class-deserializer.php
.
Quindi, vogliamo che il nostro codice sia impostato in modo che:
A tal fine, lo scheletro iniziale della classe potrebbe essere simile a questo:
È semplice, per essere sicuro. Aggiungeremo più codice in questo tutorial, ma ricordiamo il principio di responsabilità singola, e questa è una classe che deve essere utilizzata tra due parti dell'applicazione WordPress.
Si noti che nel codice sopra, abbiamo definito tre funzioni. Discutiamo di ciò che ognuno farà:
Get_Value
userà la chiave di opzione in entrata che, nel nostro caso, è tutsplus-custom-dati
, e restituirà il valore al chiamante. Secondo gli standard di codifica di WordPress, abbiamo bisogno di usare "late escaping" per assicurarci di convalidare correttamente le informazioni. Vedremo questo spettacolo per un momento.Detto questo, andiamo avanti e cancelliamo le funzioni. Fornirò anche PHP DocBlocks per spiegare cosa fa ogni funzione.
A questo punto, il codice sopra dovrebbe essere facile da seguire, dati i punti puntati sopra e i commenti all'interno del codice.
Mostralo nella pagina delle opzioni
Per mostrarlo nella pagina delle opzioni, dobbiamo rivisitare il modo in cui stiamo creando un'istanza
Submenu_Page
nelcustom-admin-settings.php
file. In particolare, abbiamo bisogno di istanziare il deserializzatore e passarlo nel costruttore delSubmenu_Page
.Per prima cosa, dobbiamo includere il file. Questo può accadere subito dopo aver controllato se il file del plugin principale è accessibile direttamente:
Il codice nella funzione principale della radice del plugin dovrebbe ora assomigliare a questo:
dentro(); $ deserializer = new Deserializer (); $ plugin = new Sottomenu (new Submenu_Page ($ deserializer)); $ Plugin-> init ();E poi il costruttore per il
Submenu_Page
dovrebbe assomigliare a questo:deserializer = $ deserializer;Da qui, possiamo affrontare la pagina delle opzioni. Semplicemente aggiorniamo il
valore
attributo effettuando una chiamata alla funzione nel deserializzatore. Ricorda, dal momento che stiamo recuperando incondizionatamente il valore e alla fine restituendo una stringa vuota se non esiste nulla, dovrebbe funzionare bene.
E con questo, dovresti essere in grado di salvare e recuperare il tuo valore nella pagina delle opzioni.
Mostralo sul front-end
Abbiamo quasi finito. L'ultima cosa che dobbiamo fare è impostare il plugin per visualizzare il messaggio personalizzato sul front-end. In particolare, vogliamo visualizzare qualsiasi cosa l'utente abbia inserito nella singola pagina del post (rispetto a una pagina di archivio o qualsiasi altro tipo di pagina) e a farlo sopra ogni post.
Questo significa che avremo bisogno di fare quanto segue:
Fortunatamente, non lo è quello molto lavoro, soprattutto perché abbiamo la maggior parte del lavoro di cui avremo bisogno per iniziare. Tuttavia, dobbiamo creare un'area del plugin specificatamente responsabile della gestione del front-end del sito.
A tal fine, creare un pubblico
directory nella radice della directory dei plugin e aggiungi class-content-messenger.php
.
Nella classe, dobbiamo definire un costruttore che accetterà il deserializzatore come dipendenza. Il costruttore (e la proprietà necessaria) dovrebbero assomigliare a questo:
deserializer = $ deserializer;
Quindi dobbiamo creare un dentro
funzione che registrerà una funzione interna (che chiameremo display
) per rendere il contenuto insieme al nuovo messaggio.
Dopodiché, dovremo aggiornare il file del plugin principale in modo da creare un'istanza della nostra nuova classe e passare il deserializzatore al costruttore. Quindi inizializzerà la classe.
Innanzitutto, lo includeremo:
Quindi lo istanziamo:
dentro();Da qui, dovremmo essere pronti per andare. Assicurati di aver inserito un valore nella pagina delle opzioni. Salva il tuo lavoro e controlla una singola pagina sul tuo sito. Dovrebbe assomigliare a qualcosa di simile a questo:
In caso contrario, confronta il tuo codice con quello che è sopra (o quello che è allegato) e assicurati di aver impostato correttamente tutte le classi, le funzioni e i ganci.
Una parola su viste e dipendenze
Anche se abbiamo parlato del principio di responsabilità unica in questa serie, non abbiamo parlato molto di argomenti più avanzati che potremmo usare per rendere il codice ancora più pulito e seguire le migliori pratiche.
Alcuni di questi argomenti includono cose come l'autoloading di PHP e cose come Dependency Injection. Non ne ho parlato perché sono al di fuori del fulcro e del punto principale di questa serie particolare che mira ad insegnare.
A seconda di come viene ricevuta questa particolare serie, prenderò in considerazione la creazione di alcuni tutorial specifici su questi argomenti.
Conclusione
E con questo, concludiamo la serie sulla creazione di pagine di amministrazione personalizzate. Spero che, in questa serie, abbiate imparato alcune cose oltre al modo standard di creare pagine di amministrazione.
Inoltre, spero che tu abbia visto come puoi applicare alcune tecniche di sviluppo del software nel tuo lavoro quotidiano con WordPress. Inoltre, spero che la discussione sulle opinioni e le dipendenze abbia suscitato interesse anche in argomenti più avanzati. Queste sono cose che spero di coprire anche in future esercitazioni.
Come al solito, puoi vedere i miei corsi e tutorial nella pagina del mio profilo, e puoi seguirmi sul mio blog e / o Twitter su @tommcfarlin dove parlo di varie pratiche di sviluppo del software e come possiamo impiegarle in WordPress.
Non dimenticare di scaricare il codice nella barra laterale di questo post, rivederlo, giocarci e vedere cosa puoi fare per estenderlo e aggiungere la tua funzionalità ad esso. Come al solito, non esitate a contattarmi tramite i commenti riguardanti il tutorial.
risorse