Advertisement
  1. Code
  2. WordPress Plugins

Creazione delle pagine di amministrazione WordPress personalizzate, Parte 3

Scroll to top
Read Time: 17 min
This post is part of a series called Creating Custom WordPress Administration Pages.
Creating Custom WordPress Administration Pages, Part 2
Creating Custom WordPress Administration Pages, Part 4

Italian (Italiano) translation by Piergiorgio Sansone (you can also view the original English article)

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

Inoltre,stiamo rivedendo alcuni dei principi più importanti dello sviluppo software, quali il principio di responsabilità del singolo e la loro applicazione al nostro lavoro.

Se vi siete avvicinati alla serie solo ora, vi consiglio di leggere i post precedenti in modo da avere familiarità con quello che abbiamo fatto fino a questo punto in modo da capire perché stiamo prendendo alcune delle decisioni mentre scriviamo il nostro codice.

Una rapida rassegna

Anche se non posso riassumere tutto ciò che abbiamo visto finora nella serie, posso evidenziare i punti importanti.

  • Abbiamo introdotto il plugin di base,  aggiunto una pagina di opzioni e la voce di sottomenu per il plugin, nel cruscotto di WordPress.
  • Abbiamo discusso il principio di responsabilità singola e il ruolo che svolge nel nostro sviluppo.
  • Un singolo elemento di input è stato aggiunto che accetterà l'input degli utenti.
  • Abbiamo aggiunto un valore nonce alla pagina, ma in realtà non abbiamo fatto niente con esso.

Tutto ciò premesso, suppongo abbaite l'ultima versione del codice sorgente (che è disponibile come allegato nel precedente articolo) e siete pronti ad andare avanti.

Prima di iniziare

Come negli agli articoli, suppongo abbiate installato e configurato un'ambiente WordPress di sviluppo locale sul vostro pc.

Inoltre, suppongo che abbiata l'ultima versione del codice sorgente e siete pronti per continuare a costruire su di esso o siete in grado di leggere ll codice che abbiamo qui e implementarlo quando avrete più tempo.

Infine, andremo avanti passo dopo passo con ogni bit di codice in modo incrementale. In primo luogo, parlerò di ciò che faremo, poi vi mostrerò il codice, e poi vi spiegherò  qualsiasi cosa il codice stia facendo, in modo che non ci sia nulla che possa generare confusione o incomprensioni.

Se, tuttavia, non abbiate chiaro qualcosa nel cofice e il tutorial non dovesse spiegare correttamente cosa sta accedendo, vi prego di lasciare un commento e sarò felice di seguirlo con voi.

Iniziamo.

Implementazione di nuove funzionalità

Nell'ultimo articolo, vi avevamo lasciato con un plugin che sembrava che facesse qualcosa, ma non salva effettivamente nulla nel database, figuriamoci se possa  recuperare qualcosa.

In breve, abbiamo un plugin che sembra funzionale ma non è. E questo è ciò che faremo con il tutorial.

In particolare, affronteremo i seguenti argomenti:

  • Verificheremo il valore nonce che abbiamo creato e definito nel precedente tutorial per capire il funzionamento dei componenti la sicurezza di WordPress.
  • Verificheremo che l'utente esistente abbia permesso effettivamente di mostrare le informazioni (e impedire loro di farlo, se non lo fanno).
  • Se la presentazione è sicura e l'utente dispone dell'autorizzazione, filtreremo le informazioni per assicurarci che nessun contenuto dannoso arrivi nel database.

Con questo come dalla nostra tabella di marcia, siamo pronti a saltare nuovamente dentro il codice e continuare a lavorare sul plugin.

Sicurezza

Richiamandoci al post precedente, abbiamo approfittato del  della funzione API di WordPress wp_nonce_field . Questa particolare funzione esegue le seguenti operazioni:

Il campo nonce viene utilizzato per convalidare che il contenuto del modulo di richiesta sia arrivato dal sito corrente e non altrove. Un nonce non offre una protezione assoluta, ma deve proteggere contro la maggior parte dei casi. È molto importante utilizzare campi nonce nei form.

Se si tenta di salvare la pagina di opzioni, probabilmente si apre con una schermata bianca. Che non è mai buono, ma è quello che ci aspettiamo dato lo stato attuale del nostro plugin.

Abbiamo bisogno di introdurre una funzione gancio in uno dei ganci WordPress disponibili, che verificherà se il valore nonce è valido. Se è valido, quindi procederemo con il salvataggio delle informazioni; in caso contrario, non dovrebbe consentirci di procedere.

Visto che siamo nel business della creazione di una pagina di amministrazione personalizzata, avremmo bisogno di un gancio diverso rispetto a quello che possiamo essere abituati a usare in situazioni come questa. In questo esempio, utilizzeremo il gancio di admin_post.

Quando non viene fornita un'azione ad una richiesta post admin viene autenticata.

Richiamandoci alle precedenti discussioni, penso, che non vogliamo sovraccaricare Ricordate, la domanda che dobbiamo costantemente chiederci è: "Per quale motivo avrebbe dovuto cambiare questa classe?"

Ora, non abbiamo una classe che può gestire le opzioni di salvataggio. Quindi cerchiamo di introdurne una. Nella directory admin del plugin, creiamo una classe Serializer. Questa sarà responsabile dei valori delle nostre opzioni di salvataggi.

The Serializer class in our plugin directoryThe Serializer class in our plugin directoryThe Serializer class in our plugin directory

Come potete vedere, ho chiamato il mio file class-serializer.php Sappiamo per esperienza e dal codice sopra, che avremo bisongo di agganciarci ad un gancio nell'admin_post menzionato sopra, e che avremo bisogno di una funzione responsabile del salvataggio delle informazioni.

Definiamole ora.

1
<?php
2
/**

3
 * Performs all sanitization functions required to save the option values to

4
 * the database.

5
 *

6
 * @package Custom_Admin_Settings

7
 */
8
9
/**

10
 * Performs all sanitization functions required to save the option values to

11
 * the database.

12
 *

13
 * This will also check the specified nonce and verify that the current user has

14
 * permission to save the data.

15
 *

16
 * @package Custom_Admin_Settings

17
 */
18
class Serializer {
19
20
    public function init() {
21
        add_action( 'admin_post', array( $this, 'save' ) );
22
    }
23
24
    public function save() {
25
26
        // First, validate the nonce.

27
        // Secondly, verify the user has permission to save.

28
        // If the above are valid, save the option.

29
30
    }
31
}

Ovviamente, c'è ancora tanto lavoro da fare (infatti, non l'abbiamo neanche creata un'istanza di questa classe!) ma il codice sopra riportato potrebbe essere sufficiente per vedere dove stiamo andando.

Una rapida conversazione sulle dipendenze

Prima di aggiungere qualsiasi funzionalità, andiamo avanti e impostare questa funzione quando si carica innanzitutto il nostro plugin. In primo luogo, restituisce il custom-admin-settings.php. Ora, a questo punto, dobbiamo chiederci se una delle nostre classi esistenti dovrebbe contenere il Serializer come dipendenza.

Penso che un caso possa essere quello del Submenu_Page il quale deve avere un riferimento al serializzatore perchè la pagina contiene le opzioni da salvare.

In alternativa, possiamo lasciare questo file completamente separato e renderlo disponibile per un altro modello. Se dovessimo farlo, andremmo fuori tema. Anche se penso che sia importante, è fuori della portata di cio che  vogliamo fare.

Quindi cerchiamo di creare un'istanza della classe  Serializer, inizializzarlo e poi passarlo al costruttore della pagina sottomenu. Il codice nel file di avvio del plugin dovrebbe risultare come questo:

1
<?php
2
3
add_action( 'plugins_loaded', 'tutsplus_custom_admin_settings' );
4
/**

5
 * Starts the plugin.

6
 *

7
 * @since 1.0.0

8
 */
9
function tutsplus_custom_admin_settings() {
10
11
    $serializer = new Serializer();
12
    $serializer->init();
13
14
    $plugin = new Submenu( new Submenu_Page( $serializer ) );
15
    $plugin->init();
16
17
}

Con questo, siamo pronti a continuare a salvare le nostre opzioni.

Torniamo allo sviluppo

Torniamo al Serializer. Ora che ce l'abbiamo adattato al resto del plugin,è arrivato il momento di scrivere un pò di codice, seguendo quanto suggerito dal commento, verificando il valore nonce che abbiamo creato sul front-end.

Fortunatamente, WordPress rende questo processo semplice grazie alla funzione wp_verify_nonce. Questa funzione accetta due argomenti :

  1. L'azione 
  2. Il nome

Se ricordate l'articolo precedente,utilizziamo come action la funzione acme-settings-save e acme-custom-message come valore nonce per validarlo, abbiamo bisogno di verificare che esista tra gli elementi di $_Post e abbia superato i controlli nativi di WordPress.

Per fare questo, mi piace creare un metodo private che mi consente di incapsulare questa logica in una funzione che possa utilizzare nella funzione save che abbiamo definito sopra.

1
<?php
2
3
/**

4
 * Determines if the nonce variable associated with the options page is set

5
 * and is valid.

6
 *

7
 * @access private

8
 * 

9
 * @return boolean False if the field isn't set or the nonce value is invalid;

10
 *                 otherwise, true.

11
 */
12
private function has_valid_nonce() {
13
14
    // If the field isn't even in the $_POST, then it's invalid.

15
    if ( ! isset( $_POST['acme-custom-message'] ) ) { // Input var okay.

16
        return false;
17
    }
18
19
    $field  = wp_unslash( $_POST['acme-custom-message'] );
20
    $action = 'acme-settings-save';
21
22
    return wp_verify_nonce( $field, $action );
23
24
}

Una volta fatto, potrò aggiungere una call a questa funzione che ci consentirà di verificare la validità della sottomissione ed uscire dalla routine o procedere con il controllo successivo (a cui arriveremo a momenti).

Si noti che restituire semplicemente false in questo controllo condizionale non è il modo adeguato per gestirlo. Invece, sarebbe meglio inserire un messaggio di errore visualizzabile nel  dashboard di WordPress. Questo è qualcosa che ci potrà essere utile quando rivisiteremo in un futuro il tutorial.

Per ora, però, siamo principalmente interessati a rendere sicuro che siamo in grado di inviare correttamente i dati. Questo ci porta alla parte successiva del nostro codice.

Autorizzazione

Anche se il numero sia stato utilizzato (o nonce) una volta controllata la validazione, c'è ancora un'altra cosa che dobbiamo controllare: abbiamo bisogno di assicurarsi che l'utente corrente disponga dell'autorizzazione per salvare i dati.

A questo proposito, dobbiamo assicurarci che l'utente corrente sia un amministratore. A tal scopo, possiamo vedere le funzionalità dell'attuale utente (potete vedere che questa pagina fornisce un riferimento per ogni ruolo e le sue funzionalità associate).

Notate che una delle caratteristiche dell'amministratore è gestire le opzioni. Adesso possiamo usare una Funzione API di WordPress current_user_can per verificare se l'untente corrente può salvare le opzioni su questa pagina.

Ma in primo luogo, questo solleva una domanda: se l'utente non può salvare le opzioni, perché dovrebbe essere consentito loro in realtà di vedere la pagina?

Se vi ricordate da versioni precedenti della serie, abbiamo scritto il seguente frammento di codice:

1
<?php
2
3
public function add_options_page() {
4
5
    add_options_page(
6
        'Tuts+ Custom Administration Page',
7
        'Custom Administration Page',
8
        'manage_options',
9
        'custom-admin-page',
10
        array( $this->submenu_page, 'render' )
11
    );
12
}

Questo assicura che la pagina delle opzioni è disponibile solo per gli amministratori; Tuttavia, vogliamo essere molto attenti e posizionare un controllo per questo durante il nostro processo di serializzazione.

Ora possiamo aggiornare il condizionale dove stiamo anche verificando il valore nonce oltre a verificare l'autorizzazione dell'utente corrente:

1
<?php
2
3
/**

4
 * Validates the incoming nonce value, verifies the current user has

5
 * permission to save the value from the options page and saves the

6
 * option to the database.

7
 */
8
public function save() {
9
10
    // First, validate the nonce and verify the user as permission to save.

11
    if ( ! ( $this->has_valid_nonce() && current_user_can( 'manage_options' ) ) ) {
12
        // TODO: Display an error message.

13
    }
14
15
    // If the above are valid, save the option.

16
17
}

Ora che abbiamo il codice in atto per assicurarsi che il valore nonce sia impostato e che l'utente corrente possa salvare il valore, possiamo andare avanti con la sanificazione

Ricordate, torneremo dove si dice che abbiamo bisogno di visualizzare un messaggio di errore. Ma questo non è nel tutorial.

Sanificazione

"Ma aspetta", dici. "Ho pensato che eravamo pronti per salvare l'opzione!" lo siamo, ma prima che si possa fare dobbiamo passare attraverso un processo di sanificazione. In breve, la sanificazione è l'idea di essere sicuri di rendere puliti, sicuri ehm sani per il database.

In poche parole, impedisce agli utenti malintenzionati di inserire informazioni nel database che, in definitiva, potrebbero influenzare negativamente il nostro sito.

Fortunatamente, WordPress fornisce una bella funzione di supporto che ci permette di assicurarci che questo avvenga nel modo più semplice possibile. Per coloro che sono interessati, potete leggere tutto riguardo la convalida e la sanificazione dei dati (Anche se guarderemo la validazione nel tutorial successivo).

Nel nostro codice, andremo ad utilizzare sanitaze_text_field (come linkato sopra). Questa funzione si comporta nel modo seguente:

  • Controlli per la codifica UTF-8 non valida
  • Converte single ' <' caratteri delle entità
  • Elimina tutti i tag
  • Rimuove le interruzioni di riga, tabulazioni e spazi vuoti aggiuntivi
  •  Elimina gli ottetti

Troppo bello poterne disporre, non è vero? Mettiamolo in funzione. A tale scopo, individuate funzione save su cui abbiamo lavorato ed aggiornatela in modo che assomiglia a questo:

1
<?php
2
/**

3
 * Validates the incoming nonce value, verifies the current user has

4
 * permission to save the value from the options page and saves the

5
 * option to the database.

6
 */
7
public function save() {
8
9
    // First, validate the nonce and verify the user as permission to save.

10
    if ( ! ( $this->has_valid_nonce() && current_user_can( 'manage_options' ) ) ) {
11
        // TODO: Display an error message.

12
    }
13
14
    // If the above are valid, sanitize and save the option.

15
    if ( null !== wp_unslash( $_POST['acme-message'] ) ) {
16
17
        $value = sanitize_text_field( $_POST['acme-message'] );
18
        update_option( 'tutsplus-custom-data', $value );
19
20
    }
21
}

Notate che stiamo leggendo l'input dalla raccolta $_post, sanificatela e salvate il risultato in una variabile separata. Successivamente, questa variabile verrà scritta nel database utilizzando la funzione update_option.

Per questo articolo, io sto optanto per utilizzare la chiave tutsplus-custom-data. Tutto ciò che utilizzate, è importante, che sia preceduto da qualcosa di unico in modo che un altro plugin o tema non sovrascriva l'opzione e voi non sovrascriviate un'opzione esistente.

Infine, abbiamo bisogno di reindirizzarci alla pagina delle opzioni. Dato che non stiamo usando un'API incorporata, abbiamo bisogno di scrivere una funzione che faccia questo per noi. Fortunatamente, è molto facile.

In primo luogo, create una funzione denominata redirect e assicuratevi che assomiglia a questa:

1
<?php
2
/**

3
 * Redirect to the page from which we came (which should always be the

4
 * admin page. If the referred isn't set, then we redirect the user to

5
 * the login page.

6
 *

7
 * @access private

8
 */
9
private function redirect() {
10
11
    // To make the Coding Standards happy, we have to initialize this.

12
    if ( ! isset( $_POST['_wp_http_referer'] ) ) { // Input var okay.

13
        $_POST['_wp_http_referer'] = wp_login_url();
14
    }
15
16
    // Sanitize the value of the $_POST collection for the Coding Standards.

17
    $url = sanitize_text_field(
18
        wp_unslash( $_POST['_wp_http_referer'] ) // Input var okay.

19
    );
20
21
    // Finally, redirect back to the admin page.

22
    wp_safe_redirect( urldecode( $url ) );
23
    exit;
24
25
}

Il codice sopra riportato deve essere auto-esplicativo, ma per essere sicuri che sia chiaro, deve eseguire le operazioni seguenti:

  1. Controlla che un valore di WordPress privato sia presente nella raccolta $_post. Se non è impostato, quindi lo imposterà uguale all'URL di login di WordPress. Questo costringerà le persone alla pagina di login se non è impostato l'URL di riferimento; Tuttavia, non c'è nessuna ragione perché non debba esserlo.
  2. Successivamente, prendiamo il riferimento e sterilizziamo i dati. Questo è qualcosa che le norme di codifica chiamano per assicurarsi che i dati siano puliti.
  3. Infine, inizializziamo un wp_safe_redirect all'URL in modo da ritornare alla pagina Opzioni.

Una volta che tutto questo è fatto, aggiungete questo come ultima riga nella funzione save precedente. La versione finale del codice dovrebbe assomigliare a questo:

1
<?php
2
/**

3
 * Performs all sanitization functions required to save the option values to

4
 * the database.

5
 *

6
 * @package Custom_Admin_Settings

7
 */
8
9
/**

10
 * Performs all sanitization functions required to save the option values to

11
 * the database.

12
 *

13
 * This will also check the specified nonce and verify that the current user has

14
 * permission to save the data.

15
 *

16
 * @package Custom_Admin_Settings

17
 */
18
class Serializer {
19
20
    /**

21
   * Initializes the function by registering the save function with the

22
	 * admin_post hook so that we can save our options to the database.

23
	 */
24
	public function init() {
25
		add_action( 'admin_post', array( $this, 'save' ) );
26
	}
27
28
	/**

29
	 * Validates the incoming nonce value, verifies the current user has

30
	 * permission to save the value from the options page and saves the

31
	 * option to the database.

32
	 */
33
	public function save() {
34
35
		// First, validate the nonce and verify the user as permission to save.

36
		if ( ! ( $this->has_valid_nonce() && current_user_can( 'manage_options' ) ) ) {
37
			// TODO: Display an error message.

38
		}
39
40
		// If the above are valid, sanitize and save the option.

41
		if ( null !== wp_unslash( $_POST['acme-message'] ) ) {
42
43
			$value = sanitize_text_field( $_POST['acme-message'] );
44
			update_option( 'tutsplus-custom-data', $value );
45
46
		}
47
48
		$this->redirect();
49
50
	}
51
52
	/**

53
	 * Determines if the nonce variable associated with the options page is set

54
	 * and is valid.

55
	 *

56
	 * @access private

57
	 *

58
	 * @return boolean False if the field isn't set or the nonce value is invalid;

59
	 *                 otherwise, true.

60
	 */
61
	private function has_valid_nonce() {
62
63
		// If the field isn't even in the $_POST, then it's invalid.

64
		if ( ! isset( $_POST['acme-custom-message'] ) ) { // Input var okay.

65
			return false;
66
		}
67
68
		$field  = wp_unslash( $_POST['acme-custom-message'] );
69
		$action = 'acme-settings-save';
70
71
		return wp_verify_nonce( $field, $action );
72
73
	}
74
75
	/**

76
	 * Redirect to the page from which we came (which should always be the

77
	 * admin page. If the referred isn't set, then we redirect the user to

78
	 * the login page.

79
	 *

80
	 * @access private

81
	 */
82
	private function redirect() {
83
84
		// To make the Coding Standards happy, we have to initialize this.

85
		if ( ! isset( $_POST['_wp_http_referer'] ) ) { // Input var okay.

86
			$_POST['_wp_http_referer'] = wp_login_url();
87
		}
88
89
		// Sanitize the value of the $_POST collection for the Coding Standards.

90
		$url = sanitize_text_field(
91
				wp_unslash( $_POST['_wp_http_referer'] ) // Input var okay.

92
		);
93
94
		// Finally, redirect back to the admin page.

95
		wp_safe_redirect( urldecode( $url ) );
96
		exit;
97
98
	}
99
}

Ecco cosa c'è : abbiamo sicurezza, sanificazione, serializzazione e reindirizzamento nello stesso luogo. Ma non stiamo dimostrando i messaggi di errore, e noi non stiamo recuperando i dati.

Ecco dove verremo con il prossimo tutorial.

Conclusione

A questo punto, abbiamo un plugin parzialmente funzionante, ma c'è ancora molto lavoro da fare. Ovviamente , le informazioni che sottomettiamo al database non vengono 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 informazioni. Nel prossimo tutorial, cercheremo di recuperare le informazioni visualizzandole sul front-end, visualizzandole nella pagina delle opzioni e aggiornando le informazioni in quanto l'utente modifica il valore dell'elemento di input.

240/5000 Nel frattempo, se stai cercando altre utilità per aiutarti a costruire il tuo crescente set di strumenti per WordPress o per studiare il codice e diventare più esperto in WordPress, non dimenticare di vedere ciò che abbiamo nel marketplace di Envato.

Ricordate, potete prendere tutti i miei corsi e tutorial sulla mia pagina del profilo, e potete seguirmi sul mio blog e/o Twitter a @tommcfarlin dove parlo di varie procedure di sviluppo software e come li possiamo impiegare in WordPress.

Infine, non esitate a lasciare qualsiasi domanda o commento nel feed qui sotto. Faccio del mio meglio per partecipare e rispondere a ogni domanda o critica che offrite in relazione a questo progetto.

Risorse

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.