Confidențialitatea și optimizarea unui Widget Dashboard Widget

Ce veți crea

În primele două părți ale acestei serii, am finalizat un plug-in complet, care ne arată starea serverului ca widget de tablou de bord. Ca atare, este disponibil pentru fiecare utilizator conectat. Unele informații pot fi sensibile și nu vrem să le vadă, deci este mai bine să verificăm rolul utilizatorului pentru a determina dacă ar trebui să-i punem widget-ul la dispoziție.

Utilizarea rolurilor sau a capacităților pentru a limita vizibilitatea

WordPress utilizează un concept de Roluri, conceput pentru a oferi proprietarului site-ului capacitatea de a controla ceea ce utilizatorii pot și nu pot face în cadrul site-ului. Fiecărui rol îi este permis să efectueze un set de sarcini numite Capabilități. Putem personaliza rolul și capabilitățile acestuia cu funcțiile add_roles și add_cap.

Pluginul nostru va crea un nou apel de capabilitate servermetric. Numai utilizatorul care are această capacitate poate încărca widget-urile noastre de tabloul de bord. Vom adăuga această capacitate pentru rolul administratorului, astfel încât toți utilizatorii administratorului îl vor vedea în mod implicit.

Pentru ceilalți utilizatori, puteți utiliza pluginul Editor de roluri pentru utilizator pentru a gestiona capabilitățile unui anumit utilizator și a le atribui servermetic capacitate pentru utilizator.

Folosim add_cap pentru a adăuga o nouă capacitate, totuși, această funcție scrie în baza de date, așa că ar trebui să o facem doar atunci când activăm pluginul. Odată dezactivat, ar trebui să curățăm baza de date eliminând rolul cu remove_cap.

clasa de tablou de bord // ... alt cod const CAP_METRIC = 'server_metric'; / ** * Începeți să configurați cârligul * / funcția publică executați () add_action ('wp_dashboard_setup', array ($ this, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ this, 'add_asset')); add_action ('admin_footer', array ($ this, 'footer')); register_activation_hook (__FILE__, array ($ this, 'add_servermetric_caps')); register_deactivation_hook (__FILE__, array ($ this, 'remove_servermetric_caps'));  / ** * Adăugați capacitatea severometrică pentru admin implicit * / funcția add_servermetric_caps () // primește rolul autorului $ role = get_role ("administrator"); // Aceasta funcționează numai pentru că accesează instanța de clasă. // ar permite autorului să editeze postările altor persoane pentru tema curentă doar $ role-> add_cap (self :: CAP_METRIC);  function remove_servermetric_caps () // get_role returnează o instanță a WP_Role. $ rol = get_role ("administrator"); $ role-> remove_cap (auto :: CAP_METRIC);  // ...

Creăm un nou apel constant CAP_METRIC și setați valoarea acestuia server_metric astfel încât să putem schimba cu ușurință numele capacității ulterior cu ușurință. Ne modificăm alerga adăugați două cârlige.

Registrul_activation_hook rulează când se activează pluginul. Acceptă doi parametri:

(șir) nume fișier: cale către fișierul plugin principal
(suna inapoi) (necesar) Funcția care trebuie rulată când pluginul este activat

register_deactivation_hook rulează atunci când dezactivează pluginul. Acceptă același parametru ca register_activation_hook.

În interiorul fiecărei funcții legate, vom încărca rolul administrator și sunați add_cap sau remove_cap pe obiectul roluri.

Apoi, ne vom modifica add_dashboard_widgets metoda de a înregistra numai widget-urile în cazul în care utilizatorul curent are servermetric capac.

 / ** * Inregistreaza proiectorul widget-ului tabloului de bord pentru a aparea pe tabloul de bord * / function add_dashboard_widgets () if (! Actual_user_can (self :: CAP_METRIC)) return false;  $ widget = Widget :: instanță (); foreach ($ widget-> get_provider () ca $ name => $ furnizor) $ widget-> register ($ name);

Apoi, folosim current_user_can pentru a verifica dacă utilizatorul curent are sau nu capacitatea de solicitare.
Acum, numai administratorul va vedea widget-ul când se încarcă tabloul de bord. Dacă doriți să activați widgetul de stare a serverului pentru alți utilizatori, puteți instala pluginul Editorul rolurilor utilizator pentru a gestiona rolurile și capabilitățile pentru orice utilizator.
Odată instalat și activat, accesați meniul Utilizatori, selectați Utilizator> Capabilități:

Apoi, pe ecranul capabilităților, putem aloca server_metric capac.

Modificați capabilitățile utilizatorilor cu pluginul Editor de roluri utilizator

Folosind roluri și capabilități, am îmbunătățit securitatea pluginului pentru a face ca widgetul nostru să fie disponibil numai utilizatorilor în care avem încredere.

Caching-ul serverului metric

WordPress utilizează API-ul Transients ca API de cache. Datele sunt serializate și stocate în wp_option tabel de WordPress cu un timp de expirare a cache-ului.

În loc să obțineți date metrice cu privire la fiecare solicitare HTTP, putem obține datele o dată și să le stocăm în memoria cache. Cu toate acestea, nu putem pune totul în memoria cache sau să folosim același timp de expirare. De exemplu, spațiul de pe disc poate fi stocat în memoria cache timp de 15 minute, iar informațiile despre server pot fi stocate în cache timp de 60 de minute, deoarece acestea se pot schimba foarte rar. În mod similar, software-ul instalat poate fi stocat în memoria cache pentru o zi, deoarece rar se schimbă odată cu configurarea serverului și este prevăzută pentru producție.

Folosim mai mult get_transient și set_transient când lucrați cu API. Conform documentației WordPress:

get_transient ($ tranzitorie): preluați numele temporar ca șir și returnați datele acestuia. Dacă datele au expirat, acestea returnează false. Ar trebui să folosim === operatorul pentru a verifica, deoarece putem stoca o valoare goală pentru tranzitorie.
set_transient ($ tranzient, valoare $, expirare $): returnează trei parametri: numele tranzitorie, valoarea sa și timpul de expirare al doilea. Rețineți că numele temporar nu trebuie să depășească 45 de caractere.

Cele două opțiuni se referă la examinarea memorării în cache a datelor metrice sau la cachearea datelor HTML generate. Caching-ul datelor HTML poate face site-ul nostru foarte rapid, dar pune o sarcină în baza de date. În acest scop, am putea face referință pentru a decide care este cel mai bine.

Pentru tutorialul nostru, hai să stocăm datele curente. În plus, ar trebui să avem o modalitate de invalidare a memoriei cache - cum ar fi o ancoră - care ne va permite să reîncărcați datele din tabloul de bord și să forțați încărcarea datelor în loc să nu fiți în memoria cache.

Cache Data pentru widget

Putem folosi direct funcția get_transient sau set_transient pentru a lucra cu API tranzitoriu. Cu toate acestea, dacă vom decide să modificăm modul în care am folosit API-ul tranzitoriu, trebuie să mergem peste fiecare loc pe care îl folosim și să îl modificăm pentru fiecare widget.

Să adăugăm încă un strat pentru a rezuma mecanismul de cache. Vom proiecta o clasă cache simplă pentru widget-ul nostru care are trei metode:

a stabilit: setarea datelor cache pentru un widget
obține: obțineți date cache pentru un widget
sarcină: încercați să încărcați din cache, dacă nu există, să calculați datele, să setați cache-ul și să reveniți

Să compunem fișierul widget / cache.php în modul următor. Rețineți că, pe măsură ce convenția noastră de încărcare automată, numele de clasă va fi ascunzătoare și spațiul său de nume este AX \ StatBoard \ Widget

get_metric (); static :: set ($ furnizor, $ date, $ cache_time); returnați date $;

Mai întâi, observați că am marcat metodele noastre caching ca fiind statice. Al nostru a stabilit și obține metodele sunt doar împachetări pentru get_transient și set_transient. sarcină metoda se află pe partea de sus a a stabilit și obține. Toate aceste metode se așteaptă să recupereze obiectul furnizorului widget; prin urmare, în interiorul sarcină metoda pe care o putem invoca get_metric pentru a obține datele reale.
Aici, cel mai important lucru este numele tranzitoriu. Deoarece numele clasei este unic în cadrul aplicației noastre, considerăm că este suficient de unic pentru numele tranzitoriu. funcția get_class returnează numele clasei unui obiect.
E timpul să ne folosim ascunzătoare clasă. Vom încerca să punem în aplicare ascunzătoare pentru widget / software.php. Modificați originalul get_content la:

$ info) $ content. = "$ cmd  $ info
"; echo $ content; // ...

Puteți vedea că ne scapăm de $ cmds = $ this-> get_metric () și pur și simplu înlocuiți-l cu Cache :: încărcare care va încărca datele din memoria cache sau o va încărca din sistem dacă nu există nici o memorie cache.
Asigurați-vă că treceți al doilea parametru pentru cât timp doriți ca datele să fie stocate în cache; în caz contrar, datele sunt stocate doar în cache timp de cinci minute. Deoarece informațiile despre software pe server rareori se modifică într-un termen scurt, setăm timpul cache-ului la 24 de ore.
Acum, că ați avut ideea, puteți să repetați cu fiecare widget pe care doriți să-l cache. Doar înlocuiți get_metric interior get_content cu:

Cache :: încărcare ($ this, $ time_in_second);

pentru ao avea grijă de cache-ul său.
Datele de utilizare a discului pot fi stocate în cache timp de ore, iar interfața Ethernet poate fi cache pentru o zi sau cam asa ceva. Depinde de dvs. să decideți cât timp doriți să îl memorați. Putem crea, de asemenea, o pagină de opțiuni pentru plugin pentru a gestiona această valoare cache pe durata de viață. Acesta poate fi un exercițiu pentru care să lucrați după ce am terminat acest articol.
Avem un exemplu final cu widget / ethernet.php. Putem adăuga capacitatea cache-ului după cum urmează:

funcția publică get_content () 
$ interfaces = Cache :: încărcare ($ this, 3600 * 24 * 7);
$ html = '


„;
foreach ($ interfețe ca $ interfață => $ ip) 
$ html. = "


„;

$ html. = 'Interfață IP
Interfață $ $ Ip
„;
echo $ html;

  // ...

Interfață	IP
Interfață $	$ Ip

Din nou, trebuie doar să înlocuim get_metric cu Cache :: încărcare. Informațiile Ethernet și adresa IP nu se schimbă niciodată, așadar am setat o durată foarte lungă de viață a cache-ului la o săptămână: 3600 secunde * 24 ore * 7 zile.

Forțați încărcarea datelor reale

Odată ce am adăugat o capacitate cache, ar trebui să sprijinim un mecanism astfel încât administratorul să poată trage widget-ul fără a fi stocat în cache. Cel mai simplu mod de a face acest lucru este să utilizați un parametru de interogare special pentru a indica faptul că vrem date reale.

Ce zici de parametrii mici, cum ar fi nocache pentru asta? Deci, în loc de adresa URL a tabloului de bord WordPress implicit domain.com/wp-admin/ putem folosi domain.com/wp-admin/?nocache.

Sunet ușor? S-o facem.

Modificați metoda noastră obține în widget / cache.php

 funcția statică obține (Provider $ provider) if (isset ($ _ GET ['nocache'])) return false;  $ cache_id = get_class ($ provider); dacă (false! == $ data = get_transient ($ cache_id)) returnați $ date;  return false;

Atâta timp cât nocache a existat un parametru de interogare, vom returna instantaneu false și, prin urmare, forțarea datelor reale este obținută în locul datelor stocate în memoria cache.
Acum, să ne gândim la adăugarea acestei caracteristici fără clasa Cache. S-ar putea să trebuiască să mergem la fiecare linie get_transient și verificați dacă există parametrul de interogare acolo. Prin urmare, luați în considerare ruperea lucrurilor în mai multe straturi atunci când proiectați pluginul. Nu puneți totul în același fișier sau copiați codul pastei de mai multe ori.
Acum, să încercăm să vizităm domain.com/wp-admin and domain.com/wp-admin?nocache și observați viteza diferită.

987ms încărcare cu activare cache

Iată rezultatul cu ?nocache = 1 atașat la adresa URL.

3,01 secunde de încărcare fără cache

Folosind cronjob pentru a genera memoria cache

Chiar dacă am implementat și am folosit o memorie cache, dacă memoria cache lipsește, pagina este încă lentă. Încă mai are nevoie de timp pentru a extrage date de pe server. Mai avem încă loc pentru a ne îmbunătăți cu cronjob. Putem programa plugin-ul nostru să fie rulat la un anumit interval. WordPress ne permite să facem asta via wp_schedule_event. În mod ideal, putem folosi wp_schedule_event pentru a programa un cârlig care va fi executat la un anumit interval.

Privind la acest exemplu, plugin-ul nostru poate programa un cârlig pentru a invoca la fiecare trei minute, cârligul, la rândul său, va invoca o altă funcție de preluare a datelor metrice. Datele sunt întotdeauna disponibile în cache și suficient de proaspete.

Deschideți fișierul nostru principal de plugin, serverdashboard.php, și actualizați metoda de rulare pentru a include un nou cârlig, precum și un nou dispozitiv de manipulare a cârligului.

 3 * 60, 'display' => __ ('O dată la fiecare 3 minute')); returnați orarele de $;  / ** * Programul de configurare pentru eveniment. Dacă programul nu există, * îl înregistrăm în * / function setup_schedule () if (! Wp_next_scheduled ('metric_generate_every_3min')) wp_schedule_event (timp (), '3min', 'metric_generate_every_3min');  / ** * Funcția principală care rulează pe cron și * generează date * / function generate_metric () $ widget = Widget :: instanță (); foreach ($ widget-> get_provider () ca $ name => $ provider) // Apelând get_content, declanșăm procesul de încărcare Cache ::. $ Mare furnizor> get_content ();

În primul rând, metoda wp_schedule_event suportă doar trei tipuri de recurență: zilnic, orar și în mod sistematic. Trebuie să adăugăm un nou tip de recurență cu filtrul wp_get_schedules.
Adăugăm încă un tip recurent care rulează la fiecare trei minute. Definiția sa:

 $ schedules ['3min'] = array ('interval' => 3 * 60, 'display' => __ ('O dată la fiecare 3 minute')); returnați orarele de $;

Putem personaliza valoarea intervalului la câte secunde dorim ca lucrarea să fie repetată. Apoi vom configura a metric_generate_every_3min cârlig.

 add_action ('metric_generate_every_3min', array ($ this, 'generate_metric'));

Acesta este cârligul nostru personalizat, nu există în WordPress. Înregistram un mâner cu metoda generate_metric pentru acel cârlig. Oricând metric_generate_every_3min cârligul este invocat, generate_metric va fi executat.
În următoarea afirmație, ne implicăm în acțiune init cu setup_schedule pentru a verifica existența următorului eveniment programat al cârligului metric_generate_every_3min. Dacă nu este încă definită, vom programa un eveniment cu wp_schedule_event, folosind repetarea personalizată pentru fiecare trei minute pentru cârligul respectiv.
În interiorul generate_metric metodă, ne bucuram prin toate widget-ul disponibil oferim, și sunați-le get_content metodă. Prin aceasta, declanșăm Cache :: încărcare proces pentru acea metrică.
WordPress va rula automat acele evenimente programate ori de câte ori cineva vizitează site-ul dvs. WordPress. Acesta va încerca să găsească evenimentul programat care trebuie rulat și să îl invocă.
Cu toate acestea, le puteți rula manual. WordPress rulează cronjob prin vizitarea fișierului wp-content.php cu adresa URL yourdomain.com/wp-cron.php?doing_wp_cron.
Poate doriți să vă actualizați cronjob-ul pentru a adăuga o nouă lucrare care ping adresa URL de mai sus la fiecare minut
Să ne deschidem crontab-ul pe server cu crontab -e și adăugați această linie la sfârșitul acesteia:

0 * * * * wget domain.com/wp-cron.php?doing_wp_cron> / dev / null 2> & 1

Am folosit wget pentru a face o cerere HTTP la fișierul wp-cron.php. Deoarece nu ne pasă de ieșire și de orice problemă de eroare, redirecționăm tot outputul / Dev / null.
Puteți citi mai multe despre configurarea acestor cronjob în următoarele articole:

http://tommcfarlin.com/wordpress-cron-jobs/
http://code.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordp...

Concluzie

Aceasta incheie un tutorial lung cu privire la modul de a construi un widget pentru tabloul de bord pentru server care ofera perspective asupra diferitelor aspecte ale sistemului nostru.
De-a lungul acestei serii am folosit biblioteci de la terți, am făcut o idee, am experimentat cu linia de comandă, am învățat despre roluri și capabilități și am examinat capabilitățile WordPress "tranzitorii, precum și mecanismele de programare a evenimentelor.
În final, am legat-o împreună într-un plugin WordPress.
Vă recomandăm să lăsați un comentariu și să ne comunicați ce idei și schimbări suplimentare ați venit, precum și orice întrebări și / sau comentarii pe care le puteți avea despre această serie.

Cod