Creazione di pagine di amministrazione di WordPress personalizzate, parte 3

In questa serie, abbiamo cercato come creare pagine di amministrazione personalizzate in WordPress senza utilizzare l'API Settings. Questo non vuol dire che l'API delle impostazioni non sia utile (perché lo è!), Ma ci possono essere momenti in cui è necessario implementare alcune funzionalità personalizzate o implementazioni più specializzate di funzionalità che le API disponibili non consentono.

Inoltre, stiamo esaminando alcuni dei più importanti principi di sviluppo del software, come il principio della responsabilità unica, e applicandoli al nostro lavoro. 

Se ti stai solo unendo alla serie, ti consiglio di leggere i post precedenti in modo che tu abbia familiarità con ciò che abbiamo fatto fino a questo punto e così puoi capire perché stiamo prendendo alcune delle decisioni che siamo fare durante la scrittura del nostro codice.

Una rapida recensione

Anche se non riesco a riassumere tutto ciò che abbiamo analizzato finora nella serie, posso assicurarmi di evidenziare i punti importanti.

• Abbiamo introdotto il plug-in di base e aggiunto una voce di sottomenu e una pagina di opzioni per il plug-in nel dashboard di WordPress.
• Abbiamo discusso il principio della singola responsabilità e il ruolo che svolge nel nostro sviluppo.
• Una sola ingresso è stato aggiunto un elemento che accetterà l'input degli utenti.
• Abbiamo aggiunto un valore nonce alla pagina, ma non abbiamo effettivamente fatto nulla con esso.

Con tutto ciò detto, presumo che tu abbia l'ultima versione del codice sorgente (che è disponibile come allegato nell'articolo precedente) e sei pronto per andare avanti.

Prima di iniziare

Come per gli altri articoli, suppongo che tu abbia un ambiente di sviluppo WordPress locale configurato sul tuo computer. 

Inoltre, presumo che tu abbia l'ultima versione del codice sorgente e sei pronto per continuare a crearlo o ti stia comodo leggere il codice che abbiamo qui e implementarlo quando hai più tempo.

Infine, analizzeremo gradualmente ogni bit di codice. In primo luogo, parlerò di ciò che faremo, quindi mostrerò il codice e poi spiegherò qualunque cosa stia facendo il codice, quindi non rimane nulla che possa confondere.

Se, tuttavia, ti trovi confuso su qualcosa nel codice e il tutorial non fa un buon lavoro di spiegare cosa sta succedendo, per favore lascia un commento e io ti assicurerò di seguirti.

Iniziamo.

Implementazione di nuove funzionalità

Nell'ultimo articolo, abbiamo terminato con un plug-in sembra come se facesse qualcosa ma in realtà non salvasse nulla nel database, per non parlare di recuperare nulla dal database.

In breve, abbiamo un plugin che sembra funzionale ma non lo è. Ed è qui che andremo a riprendere con questo tutorial.

Nello specifico, affronteremo i seguenti argomenti:

• Verificheremo il valore nonce che abbiamo creato e definito nel tutorial precedente per capire come funziona un componente della sicurezza di WordPress.
• Verificheremo che l'utente esistente abbia il permesso di inviare effettivamente le informazioni (e impedisca loro di farlo, se non lo fanno).
• Se l'invio è sicuro e l'utente ha il permesso, provvederemo a disinfettare le informazioni per assicurarsi che nessun contenuto dannoso entri nel database.

Con questo come nostra roadmap, siamo pronti per tornare indietro nel codice e continuare a lavorare sul plugin.

Sicurezza

Ricordiamo dal post precedente, abbiamo sfruttato la funzione API di WordPress wp_nonce_field. Questa particolare funzione procede come segue:

Il campo nonce viene utilizzato per convalidare che il contenuto della richiesta di modulo proviene dal sito corrente e non da qualche altra parte. Un nonce non offre una protezione assoluta, ma dovrebbe proteggere dalla maggior parte dei casi. È molto importante utilizzare i campi nonce nei moduli.

Se si tenta di salvare la pagina delle opzioni, verrà visualizzata una schermata bianca. Non va mai bene, ma è quello che ci aspettiamo dato lo stato attuale del nostro plugin.

Abbiamo bisogno di introdurre una funzione che si agganci a uno degli hook di WordPress disponibili e verificherà se il valore di nonce è valido. Se è così è valido, quindi ci permetterà di procedere con il salvataggio delle informazioni; altrimenti, non dovrebbe lasciarci procedere.

Dal momento che stiamo progettando la creazione di una pagina di amministrazione personalizzata, avremo bisogno di un hook diverso da quello che potremmo utilizzare in situazioni come questa. In questo esempio, useremo il admin_post gancio. 

Viene eseguito su una richiesta di post di amministrazione autenticata in cui non è stata fornita alcuna azione.

Ricordiamo, tuttavia, dalle nostre precedenti discussioni che non vogliamo sovraccaricare le nostre classi con più responsabilità del necessario. Ricorda, la domanda che dobbiamo costantemente chiederci è: "Quale motivo dovrebbe cambiare questa classe?" 

Al momento, non abbiamo una classe in grado di gestire le opzioni di salvataggio. Quindi presentiamone uno. Nella directory di amministrazione del plugin, creiamo a Serializer classe. Questo sarà responsabile per il salvataggio del valore delle nostre opzioni.

Come puoi vedere, ho chiamato il mio file class-serializer.php. Sappiamo per esperienza e dal codice di cui sopra che sarà necessario connettersi al admin_post hook citato sopra, e sappiamo che avremo bisogno di una funzione responsabile per il salvataggio delle informazioni.

Definiamo ora quelli.

Ovviamente, c'è ancora del lavoro da fare (in effetti, non abbiamo nemmeno istanziato questa classe!) Ma il codice sopra potrebbe essere sufficiente per vedere dove stiamo andando.
Una conversazione rapida sulle dipendenze
Prima di aggiungere qualsiasi funzionalità, andiamo avanti e impostiamola quando il nostro plugin viene caricato per la prima volta. In primo luogo, restituire il custom-admin-settings.php. Ora, a questo punto, dobbiamo chiederci se una delle nostre classi esistenti debba avere il Serializer come dipendenza.
Penso che un caso possa essere fatto che il Submenu_Page dovrebbe avere un riferimento al serializzatore poiché la pagina ha le opzioni per salvare.
In alternativa, è anche possibile lasciare questo file completamente separato e renderlo disponibile per un altro pattern. Se dovessimo farlo, saremmo divergenti dall'argomento in discussione. Anche se penso che sia importante, è al di fuori della portata di ciò che intendiamo fare.
Quindi, istanziamo il Serializer classe, inizializzarlo e quindi passarlo nel costruttore della pagina del sottomenu. Il codice nel file bootstrap del plugin dovrebbe ora apparire come questo:
dentro(); $ plugin = new Sottomenu (new Submenu_Page ($ serializer)); $ Plugin-> init (); 
Con ciò, siamo pronti a continuare a salvare le nostre opzioni.
Ritorno allo sviluppo
Torniamo al Serializer. Ora che lo abbiamo cablato al resto del plug-in, è tempo di scrivere del codice quindi, come suggerisce il commento, controlliamo il valore nonce che abbiamo creato sul front-end.
Fortunatamente, WordPress rende questo facile attraverso una funzione API integrata: wp_verify_nonce. Questa funzione accetta due argomenti:
 
L'azione
 
Il nome
 
Se ricordi l'articolo precedente, abbiamo usato acme-settings-save come nostra azione e acme-custom-messaggio come il nostro valore nonce. Per convalidarlo, dobbiamo verificare che esista nel $ _POST raccolta e che supera i controlli nativi di WordPress. 
Per fare questo, mi piace creare un privato metodo che mi permette di incapsulare questa logica in una funzione che posso usare nel salvare funzione che abbiamo definito sopra.
Una volta fatto, posso incorporare una chiamata a questa funzione che ci permetterà di verificare la validità dell'invio e di uscire dalla routine o procedere al controllo successivo (che otterremo momentaneamente).
Nota che semplicemente restituire false in questo condizionale non è un modo adatto per gestirli. Invece, sarebbe più pulito introdurre un messaggio di errore che viene visualizzato sul dashboard di WordPress. Questo è qualcosa che rivedremo in un prossimo tutorial. 
Per ora, però, ci preoccupiamo principalmente di assicurarci che siamo in grado di inviare i dati con successo. Questo ci porta alla prossima parte del nostro codice.
Autorizzazione
Anche se la verifica del numero usato una volta (o nonce) è stata verificata, c'è ancora un'altra cosa che dobbiamo controllare: dobbiamo assicurarci che l'utente corrente abbia il permesso di salvare i dati.
Per i nostri scopi, vogliamo assicurarci che l'utente corrente sia un amministratore. Per fare questo, possiamo esaminare le funzionalità dell'utente corrente (puoi vedere questa pagina fornisce un riferimento per ogni ruolo e le sue capacità associate).
Si noti che una delle funzionalità dell'amministrazione è la gestione delle opzioni. Ora possiamo usare la funzione API di WordPress current_user_can per verificare se l'utente corrente può salvare le opzioni su questa pagina.
Ma prima, questo solleva una domanda: se l'utente non può salvare le opzioni, perché dovrebbe essere permesso effettivamente di vedere la pagina in primo luogo?
Se ricordi di prima nella serie, abbiamo scritto il seguente bit di codice:
submenu_page, 'render')); 
Questo assicura che la pagina delle opzioni è disponibile solo per gli amministratori; tuttavia, vogliamo essere più attenti e fare un controllo per questo durante il nostro processo di serializzazione, pure.
Ora possiamo aggiornare il condizionale in cui controlliamo anche il valore di nonce anche per verificare l'autorizzazione dell'utente corrente:
has_valid_nonce () && current_user_can ('manage_options')))) // TODO: Visualizza un messaggio di errore.  // Se quanto sopra è valido, salva l'opzione. 
Ora che abbiamo il codice in atto per assicurarci che il valore di nonce sia impostato e che l'utente corrente possa salvare il valore, possiamo procedere con la sanitizzazione.
Ricorda, noi volontà tornare al punto in cui è indicato che è necessario visualizzare un messaggio di errore. Ma non è in questo tutorial.
sanificazione
"Ma aspetta", dici. "Pensavo che ci stessimo preparando a salvare l'opzione!" Lo siamo, ma prima di poterlo fare dobbiamo passare attraverso un processo di sterilizzazione. In breve, l'igienizzazione è l'idea di assicurarsi che i dati siano puliti, sicuri e, ahem, sanitario per il database.
In poche parole, impedisce agli utenti malintenzionati di inserire informazioni nel database che potrebbero in ultima analisi influire negativamente sul nostro sito.
Fortunatamente, WordPress offre una bella funzione di supporto che ci consente di assicurarci che sia il più semplice possibile. Per coloro che sono interessati, puoi leggere tutto sulla validazione e la disinfezione dei dati (anche se esamineremo la convalida nel prossimo tutorial).
Nel nostro codice, useremo sanitize_text_field (come collegato sopra). Questa funzione farà quanto segue:
 
Controlla l'UTF-8 non valido
 
Converti single '<' characters to entities
 
Toglie tutti i tag
 
Rimuove interruzioni di riga, tabulazioni e spazi bianchi extra
 
Strisce ottetti
 
Piuttosto bello averlo disponibile, no? Mettiamolo a posto. Per fare ciò, individuare il salvare funzione con cui abbiamo lavorato e aggiornarlo in modo che assomigli a questo:
has_valid_nonce () && current_user_can ('manage_options')))) // TODO: Visualizza un messaggio di errore.  // Se quanto sopra è valido, disinfetti e salva l'opzione. if (null! == wp_unslash ($ _POST ['acme-message'])) $ value = sanitize_text_field ($ _POST ['acme-message']); update_option ('tutsplus-custom-data', $ value); 
Si noti che stiamo leggendo l'input dal $ _POST raccolta, disinfettandola e quindi salvando il risultato in una variabile separata. Successivamente, quella variabile viene scritta nel database usando il update_option funzione. 
Per questo articolo, sto optando per usare la chiave tutsplus-custom-dati. Qualunque cosa tu usi, è importante che sia preceduta da qualcosa di unico in modo che un altro plugin o tema non sovrascriva l'opzione e non sovrascrivi un'opzione esistente.
Infine, dobbiamo reindirizzare nuovamente alla pagina delle opzioni. Dal momento che non stiamo usando un'API integrata, avremo bisogno di scrivere una funzione per farlo per noi. Fortunatamente, è molto facile. 
Per prima cosa, crea una funzione chiamata redirect e assicurati che assomigli a questa:
Il codice sopra dovrebbero essere auto-esplicativo, ma per assicurarsi che sia chiaro, sta facendo quanto segue:
 
Controlla che un valore WordPress privato sia presente nel file $ _POST collezione. Se non è impostato, verrà impostato uguale all'URL di accesso di WordPress. Questo costringerà le persone alla pagina di accesso se l'URL di riferimento non è impostato; tuttavia, non c'è motivo per cui non dovrebbe essere.
 
Successivamente, prendiamo il referrer e disinfettiamo i dati. Questo è qualcosa che gli standard di codifica richiedono e si assicura che i dati siano puliti.
 
Infine, inizializziamo a wp_safe_redirect all'URL in modo che torniamo alla pagina delle opzioni.
 
Una volta fatto tutto questo, aggiungilo come ultima riga nel file salvare funzione sopra. La versione finale del codice dovrebbe apparire così:
has_valid_nonce () && current_user_can ('manage_options')))) // TODO: Visualizza un messaggio di errore.  // Se quanto sopra è valido, disinfetti e salva l'opzione. if (null! == wp_unslash ($ _POST ['acme-message'])) $ value = sanitize_text_field ($ _POST ['acme-message']); update_option ('tutsplus-custom-data', $ value);  $ this-> redirect ();  / ** * Determina se la variabile nonce associata alla pagina delle opzioni è impostata * ed è valida. * * @accesso privato * * @return booleano False se il campo non è impostato o il valore nonce non è valido; * altrimenti, vero. * / private function has_valid_nonce () // Se il campo non è nemmeno in $ _POST, non è valido. if (! isset ($ _POST ['acme-custom-message'])) // Input var okay. restituisce falso;  $ field = wp_unslash ($ _POST ['acme-custom-message']); $ action = 'acme-settings-save'; restituisce wp_verify_nonce ($ campo, $ azione);  / ** * Reindirizza alla pagina da cui siamo arrivati ​​(che dovrebbe sempre essere la pagina di * admin. Se il riferimento non è impostato, quindi reindirizzare l'utente a * la pagina di accesso. * * @Accesso privato * / privato function redirect () // Per rendere felici gli standard di codifica, dobbiamo inizializzarlo. if (! isset ($ _POST ['_ wp_http_referer'])) // Input var okay. $ _POST ['_ wp_http_referer'] = wp_login_url (); // Sanitizza il valore della raccolta $ _POST per gli standard di codifica. $ Url = sanitize_text_field (wp_unslash ($ _POST ['_ wp_http_referer']) // Input var okay.); // Infine, reindirizza al pagina admin wp_safe_redirect (urldecode ($ url)); exit; 
Ecco la cosa: abbiamo sicurezza, sanificazione, serializzazione e reindirizzamento. Ma non visualizziamo messaggi di errore e non stiamo recuperando i dati. 
Ecco dove ci riprenderemo con il prossimo tutorial.
Conclusione
A questo punto, abbiamo un plugin semi-funzionale, ma c'è ancora molto lavoro da fare. Ovviamente, le informazioni che stiamo inviando al database non sono visualizzate da nessuna parte, e questa non è una buona cosa.
Ma proprio come con il salvataggio delle informazioni, ci sono cose importanti da considerare quando si recuperano le informazioni. Nel prossimo tutorial, cercheremo di recuperare le informazioni, visualizzarle sul front-end, visualizzarle nella pagina delle opzioni e anche aggiornare le informazioni mentre un utente modifica il valore dell'elemento di input.
Nel frattempo, se stai cercando altre utilità che ti aiutino a costruire il tuo set crescente di strumenti per WordPress o che il codice studi e diventi più esperto in WordPress, non dimenticare di vedere cosa abbiamo a disposizione in Envato Mercato.
Ricorda, puoi prendere tutti 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.
Infine, non esitate a lasciare domande o commenti nel feed qui sotto. Faccio del mio meglio per partecipare e rispondere a qualsiasi domanda o critica che offri in relazione a questo progetto.
risorse
 
L'API delle impostazioni
 
La guida completa all'API Impostazioni
 
Principio della singola responsabilità
 
wp_nonce_field
 
admin_post
 
wp_verify_nonce
 
 wp_nonce_field
 
Ruoli e funzionalità
 
current_user_can
 
Convalida ed escaping dei dati dell'utente
 



		
			
	   
	




Codice