Crearea paginilor personalizate de administrare WordPress, Partea 3

În această serie, am analizat modul de creare a paginilor de administrare personalizate în WordPress fără a utiliza API-ul pentru setări. Acest lucru nu înseamnă că API-ul pentru setări nu este util (deoarece este!), Dar pot exista momente când trebuie să implementăm anumite funcții personalizate sau implementări mai detaliate ale caracteristicilor pe care API-urile disponibile nu le permit.

În plus, ne uităm la unele dintre cele mai importante principii de dezvoltare a software-ului, cum ar fi principiul responsabilității unice și aplicarea acestora la munca noastră. 

Dacă tocmai vă alăturați seriei, vă recomand să citiți posturile anterioare, astfel încât să fiți familiarizați cu ceea ce am făcut până acum și astfel să înțelegeți de ce luăm unele decizii că suntem atunci cand scriem codul nostru.

O examinare rapidă

Deși nu pot rezuma tot ceea ce am acoperit până acum în serie, mă pot asigura că subliniez punctele importante.

• Am introdus pluginul de bază și am adăugat o pagină de submeniuri și opțiuni pentru pluginul din tabloul de bord WordPress.
• Am discutat principiul responsabilității unice și rolul pe care îl joacă în dezvoltarea noastră.
• Un singur intrare a fost adăugat un element care va accepta contribuția utilizatorilor.
• Am adăugat o valoare nonce la pagină, dar nu am făcut nimic cu ea.

Cu toate acestea, presupun că aveți cea mai recentă versiune a codului sursă (care este disponibilă ca atașament în articolul precedent) și sunteți gata să vă deplasați înainte.

Înainte de a începe

Ca și în celelalte articole, presupun că aveți un mediu local de dezvoltare WordPress instalat pe mașina dvs.. 

Mai mult, presupun că aveți cea mai recentă versiune a codului sursă și că sunteți gata să continuați să construiți pe partea de sus a acesteia sau sunteți confortabil să citiți codul pe care îl avem aici și să îl implementați atunci când aveți mai mult timp.

În cele din urmă, vom trece prin fiecare bit de cod incremental. În primul rând, voi vorbi despre ceea ce vom face, atunci voi arăta codul, iar apoi voi explica tot ce face codul, așa că nu mai rămâne nimic care ar putea fi confuz.

Dacă, totuși, vă veți confunda cu ceva în cod și tutorialul nu face o treabă bună de a explica ce se întâmplă, atunci vă rugăm să lăsați un comentariu și voi fi sigur că va urma cu tine.

Să începem.

Implementarea de noi funcții

În ultimul articol, am rămas cu un plugin care arată ca și cum ar face ceva, dar nu salvează de fapt nimic în baza de date, să nu mai vorbim să recuperăm nimic din baza de date.

Pe scurt, avem un plugin care arată funcțional, dar nu este. Și acolo vom ajunge la acest tutorial.

Mai exact, vom aborda următoarele subiecte:

• Vom verifica valoarea nonce care am creat și definit în tutorialul anterior pentru a obține o înțelegere a modului în care funcționează o componentă a securității WordPress.
• Vom verifica dacă utilizatorul existent are permisiunea de a trimite efectiv informațiile (și de a le împiedica să facă acest lucru, dacă nu).
• Dacă depunerea este securizată și utilizatorul are permisiunea, atunci vom dezinfecta informațiile pentru a vă asigura că nu se introduce conținut rău intenționat în baza de date.

Cu aceasta ca foaia de parcurs, suntem gata să revenim în cod și să continuăm să lucrăm la plugin.

Securitate

Amintiți-vă din postul anterior, am profitat de funcția API WordPress wp_nonce_field. Această funcție particulară face următoarele:

Câmpul nonce este utilizat pentru a valida faptul că conținutul cererii de formular a venit de pe site-ul curent și nu în altă parte. Un nonce nu oferă protecție absolută, ci ar trebui să protejeze împotriva celor mai multe cazuri. Este foarte important să folosim câmpurile nonce în forme.

Dacă încercați să salvați pagina cu opțiuni, veți avea probabil un ecran alb. Nu este niciodată bine, dar este ceea ce ne așteptăm, având în vedere stadiul actual al plugin-ului nostru.

Trebuie să introducem o funcție care să cupleze într-unul dintre cârligele WordPress disponibile și va verifica dacă valoarea nonce este validă. Daca este valabil, atunci ne va permite să continuăm cu salvarea informațiilor; în caz contrar, nu ar trebui să ne lase să procedăm.

De vreme ce suntem în căutarea unei pagini de administrare personalizate, vom avea nevoie de un cârlig diferit de cel pe care ni-l putem folosi în situații de genul asta. În acest exemplu, vom folosi admin_post cârlig. 

Incendii la o cerere de autentificare de administrator autentificată, în cazul în care nu a fost furnizată nicio acțiune.

Reamintim din discuțiile noastre anterioare că nu vrem să supraîncărcăm clasele noastre cu mai multă responsabilitate decât este necesar. Amintiți-vă, întrebarea pe care trebuie să ne întrebăm în mod constant este: "Ce motiv ar trebui să se schimbe această clasă?" 

În prezent, nu avem o clasă care să gestioneze opțiunile de salvare. Deci, să introducem unul. În directorul de administrare al pluginului, să creăm un serializer clasă. Acesta va fi responsabil pentru salvarea valorii opțiunilor noastre.

După cum puteți vedea, mi-am numit dosarul clasa-serializer.php. Știm din experiență și din codul de mai sus că va trebui să cârlig în admin_post cârlig menționate mai sus și știm că vom avea nevoie de o funcție responsabilă de salvarea informațiilor.

Să le definim acum.

Evident, mai avem încă de lucru (de fapt, nici măcar nu am instanțiat această clasă!), Dar codul de mai sus ar putea fi suficient pentru a vedea unde ne îndreptăm.
O conversație rapidă despre dependențe
Înainte de a adăuga orice funcționalitate, hai să mergem mai departe și să setăm acest lucru când pluginul nostru se încarcă. În primul rând, returnați personalizate-admin-settings.php. Acum, în acest moment, trebuie să ne întrebăm dacă oricare dintre clasele noastre existente ar trebui să aibă serializatorul ca o dependență.
Cred că se poate face un caz ca Submenu_Page ar trebui să aibă o referință la serializator, deoarece pagina are opțiunile de salvare.
De asemenea, este posibil să lăsați acest fișier complet separat și să îl aveți la dispoziție pentru un alt model. Dacă ar fi să facem acest lucru, ne-am fi diferiți de subiectul la îndemână. Deși cred că este important, este în afara scopului a ceea ce vrem să facem.
Deci, hai să instanțiăm serializer clasa, inițializați-o și apoi treceți-o în constructorul paginii de submeniu. Codul din fișierul de bootstrap al pluginului ar trebui să arate astfel:
init (); $ plugin = nou Submeniu (nou submeniu_Page ($ serializer)); $ Plugin-> init (); 
Cu aceasta, suntem gata să continuăm salvarea opțiunilor noastre.
Înapoi la dezvoltare
Să ne întoarcem la serializer. Acum, când l-am conectat la restul pluginului, este timpul să scriem un cod astfel încât, după cum sugerează comentariul, să verificăm valoarea nonce pe care am creat-o pe front-end.
Din fericire, WordPress face acest lucru ușor prin intermediul unei funcții API încorporate: wp_verify_nonce. Această funcție acceptă două argumente:
 
Actiunea
 
Numele
 
Dacă vă amintiți din articolul precedent, am folosit Acme-settings-save ca și acțiunea noastră și Acme-custom-mesaj ca valoare nonce noastre. Pentru ao valida, trebuie să verificăm dacă există $ _POST de colectare și că acesta trece verificările native ale WordPress. 
Pentru a face acest lucru, îmi place să creez a privat metodă care îmi permite să încapsulez această logică într - o funcție pe care o pot folosi în Salvați funcția pe care am definit-o mai sus.
După ce am terminat, pot să includ un apel la această funcție, care să ne permită să verificăm valabilitatea trimiterii și fie să ieșim din rutină, fie să mergem la următoarea verificare (la care vom ajunge la moment).
Rețineți că simpla returnare a falsului în această condiție nu este o modalitate adecvată de a face față acestei situații. În schimb, ar fi mai curat să introduci un mesaj de eroare care se afișează în tabloul de bord WordPress. Acesta este un lucru pe care îl vom revizui într-un viitor tutorial. 
Pentru moment, totuși, suntem în primul rând preocupați de asigurarea faptului că suntem capabili să trimitem datele cu succes. Acest lucru ne aduce la următoarea porțiune a codului nostru.
Permisiune
Chiar dacă numărul de validare folosit o singură dată (sau nonce) a fost verificat, mai avem încă un lucru pe care trebuie să-l verificăm: trebuie să ne asigurăm că utilizatorul curent are permisiunea de a salva datele.
Pentru scopurile noastre, dorim să ne asigurăm că utilizatorul curent este un administrator. Pentru a face acest lucru, ne putem uita la capabilitățile utilizatorului curent (puteți vedea că această pagină oferă o referință pentru fiecare rol și capabilitățile asociate acestuia).
Observați că una dintre capabilitățile administrației este de a gestiona opțiunile. Acum putem folosi funcția API WordPress current_user_can pentru a verifica dacă utilizatorul curent poate salva opțiunile din această pagină.
Dar, mai întâi, aceasta ridică o întrebare: dacă utilizatorul nu poate salva opțiunile, de ce ar trebui să li se permită să vadă efectiv pagina în primul rând?
Dacă vă amintiți din mai devreme în serie, am scris următorul cod de cod:
submenu_page, 'render')); 
Aceasta asigură pagina opțiunilor este disponibilă numai administratorilor; cu toate acestea, dorim să fim foarte atenți și să facem un control pentru acest lucru în timpul procesului de serializare, de asemenea.
Acum putem actualiza condiția în care verificăm, de asemenea, valoarea nonce, de asemenea, pentru a verifica permisiunea utilizatorului curent:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: Afișați un mesaj de eroare.  // Dacă cele de mai sus sunt valide, salvați opțiunea. 
Acum, că avem un cod în loc pentru a ne asigura că valoarea nonce este setată și că utilizatorul curent poate salva valoarea, putem merge mai departe cu dezinfectarea.
Ține minte, noi voi reveniți la locul în care se spune că trebuie să afișăm un mesaj de eroare. Dar asta nu este în acest tutorial.
sanitization
"Dar așteptați", spuneți voi. "Am crezut că ne pregătim să salvăm opțiunea!" Suntem, dar înainte de a putea face acest lucru trebuie să trecem printr-un proces de igienizare. Pe scurt, sanitizarea este ideea de a vă asigura că datele sunt curate, sigure și, hm, sanitare pentru baza de date.
Pur și simplu, acesta împiedică utilizatorii rău intenționați să introducă informații în baza de date care ar putea afecta în cele din urmă site-ul nostru.
Din fericire, WordPress oferă o funcție de ajutor care ne permite să ne asigurăm că acest lucru este cât se poate de ușor. Pentru cei interesați, puteți citi totul despre validarea și dezinfectarea datelor (deși vom examina validarea în tutorialul următor).
În codul nostru, vom folosi sanitize_text_field (așa cum este legat mai sus). Această funcție va face următoarele:
 
Verifică nevalabilitatea UTF-8
 
Convertește un singur "<' characters to entities
 
Elimină toate etichetele
 
Elimină pauzele de linie, filele și spațiile albe
 
Batete octeți
 
Destul de frumos să fie disponibil, nu-i așa? Să facem asta să funcționeze. Pentru aceasta, localizați Salvați cu care lucram și actualizăm-o astfel încât să pară următoarele:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: Afișați un mesaj de eroare.  // Dacă cele de mai sus sunt valabile, dezinfectați și salvați opțiunea. dacă null! == wp_unslash ($ _POST ['acme-message']))) $ value = sanitize_text_field ($ _POST ['acme-message']); update_option ('tutsplus-custom-data', valoare $); 
Observați că citim intrarea din $ _POST colectarea, dezinfectarea și apoi salvarea rezultatului într-o variabilă separată. Apoi, acea variabilă este scrisă în baza de date folosind update_option funcţie. 
Pentru acest articol, prefer să folosesc cheia tutsplus-custom-date. Indiferent ce folosiți, este important să fie prefixată cu ceva unic, astfel încât un alt plugin sau temă să nu suprascrie opțiunea și să nu înlocuiți o opțiune existentă.
În cele din urmă, trebuie să redirecționăm înapoi la pagina cu opțiuni. Deoarece nu folosim un API încorporat, va trebui să scriem o funcție pentru a face acest lucru pentru noi. Din fericire, este foarte ușor. 
Mai întâi, creați o funcție numită redirecționare și asigurați-vă că arată astfel:
Codul de mai sus ar trebui să să fie explicativ, dar pentru a vă asigura că este clar, face următoarele:
 
Verifică pentru a vă asigura că o valoare WordPress privată este prezentă în $ _POST Colectie. Dacă nu este setat, atunci va fi egal cu adresa URL de conectare WordPress. Acest lucru va forța oamenii la pagina de conectare dacă adresa URL de trimitere nu este setată; cu toate acestea, nu există nici un motiv pentru care să nu fie.
 
Apoi, luăm referire și dezinfectăm datele. Acesta este un lucru pe care standardele de codare îl solicită și se asigură că datele sunt curate.
 
În cele din urmă, inițializăm o wp_safe_redirect la adresa URL, astfel încât să ne întoarcem la pagina de opțiuni.
 
După ce se termină toate acestea, adăugați acest lucru ca ultimul rând din Salvați funcția de mai sus. Versiunea finală a codului ar trebui să arate astfel:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: Afișați un mesaj de eroare.  // Dacă cele de mai sus sunt valabile, dezinfectați și salvați opțiunea. dacă null! == wp_unslash ($ _POST ['acme-message']))) $ value = sanitize_text_field ($ _POST ['acme-message']); update_option ('tutsplus-custom-data', valoare $);  $ this-> redirect ();  / ** * Stabilește dacă variabila nonce asociată cu pagina cu opțiuni este setată * și este validă. * * @access private * * @return boolean Fals dacă câmpul nu este setat sau valoarea nonce este nevalidă; * altfel, adevărat. * / funcția privată has_valid_nonce () // Dacă câmpul nu este chiar în $ _POST, atunci este nevalid. dacă isset ($ _POST ['acme-custom-message']))) // Introduceți var bine. return false;  $ field = wp_unslash ($ _POST ['acme-personalizat-mesaj']); $ actiune = 'acme-settings-save'; returnați wp_verify_nonce ($ field, $ action);  / ** * Redirecționați către pagina din care am venit (care ar trebui să fie întotdeauna pagina de admin *.) Dacă referința nu este setată, atunci redirecționăm utilizatorul la * pagina de conectare. funcția redirect () // Pentru a face standardele de codificare fericite, trebuie să inițializăm acest lucru dacă (isset ($ _POST ['_ wp_http_referer']))) // Introduceți var okay $ _POST ['_wp_http_referer'] = wp_login_url (); // Sanitizează valoarea colecției $ _POST pentru standardele de codare $ url = sanitize_text_field (wp_unslash ($ _POST ['_ wp_http_referer']) // Input var okay;) // În final, redirecționați înapoi la pagina de administrare wp_safe_redirect (urldecode ($ url)); ieșire; 
Iată lucrurile: avem securitate, dezinfectare, serializare și redirecționare. Dar nu afișăm mesaje de eroare și nu preluăm datele. 
Acolo vom lua locul următorului tutorial.
Concluzie
În acest moment, avem un plugin semi-funcțional, dar mai avem încă de lucru. Evident, informațiile pe care le trimitem la baza de date nu sunt afișate nicăieri și nu este un lucru bun.
Dar, la fel ca în cazul salvării informațiilor, există lucruri importante de luat în considerare atunci când se creează informații. În tutorialul următor, vom examina descărcarea informațiilor, afișarea lor pe front-end, afișarea acestora pe pagina de opțiuni și actualizarea informațiilor în timp ce utilizatorul modifică valoarea elementului de intrare.
Între timp, dacă sunteți în căutarea pentru alte utilități pentru a vă ajuta să construi setul tot mai mare de instrumente pentru WordPress sau de cod pentru a studia și de a deveni mai bine versat în WordPress, nu uitați să vedem ce avem la dispoziție în Envato Piaţă.
Amintiți-vă că puteți prinde toate cursurile și tutorialele mele pe pagina mea de profil și puteți să mă urmați pe blogul meu și / sau pe Twitter la @tommcfarlin unde vorbesc despre diverse practici de dezvoltare software și cum le putem angaja în WordPress.
În cele din urmă, nu ezitați să lăsați orice întrebări sau comentarii în feed-ul de mai jos. Fac tot ce pot pentru a participa și a răspunde la fiecare întrebare sau critică pe care o oferiți în legătură cu acest proiect.
Resurse
 
API-ul Setări
 
Ghidul complet al API-ului pentru setări
 
Principiul unic de responsabilitate
 
wp_nonce_field
 
admin_post
 
wp_verify_nonce
 
 wp_nonce_field
 
Roluri și capabilități
 
current_user_can
 
Validarea și evitarea datelor de utilizator
 



		
			
	   
	




Cod