Personvern og optimalisering av en WordPress Dashboard Widget

Hva du skal skape

I de to første delene av denne serien fullførte vi et fullverdig plugin som viser oss serverstatus som dashbord-widget. Som sådan er den tilgjengelig for alle innloggede brukere. Enkelte opplysninger kan være følsomme, og vi vil ikke at de skal se det, så det er bedre å sjekke at brukerrollen skal avgjøre om vi skal gjøre widgeten tilgjengelig for dem. 

Bruk roller eller evner for å begrense synligheten

WordPress bruker et konsept med roller, designet for å gi nettstedseieren muligheten til å kontrollere hva brukerne kan og ikke kan gjøre innenfor nettstedet. Hver rolle har lov til å utføre et sett med oppgaver kalt Evner. Vi kan tilpasse rollen og dens evner med add_roles og add_cap funksjoner.

Vårt plugin vil skape et nytt funksjonsanrop servermetric. Bare brukeren som har den muligheten, kan laste inn modulene våre på dashbordet. Vi legger til denne muligheten for administratorroll, slik at alle administratorbrukerne ser det som standard. 

For de andre brukerne kan du bruke Plugin User Role Editor til å administrere evnen til en bestemt bruker, og tilordne servermetic mulighet for brukeren.

Vi bruker add_cap for å legge til en ny funksjon, men denne funksjonen skriver til databasen, så vi bør bare gjøre det når du aktiverer plugin. Når deaktiveres, bør vi rydde opp databasen ved å fjerne rollen med remove_cap.

klasse Dashboard // ... annen kode const CAP_METRIC = 'server_metric'; / ** * Begynn å konfigurere krok * / offentlig funksjon kjøre () add_action ('wp_dashboard_setup', array ($ dette, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ dette, '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'));  / ** * Legg til severmetric evne for admin som standard * / funksjon add_servermetric_caps () // får forfatterrollen $ role = get_role ('administrator'); // Dette virker bare, fordi det åpner klasseeksemplet. // vil tillate forfatteren å redigere andres innlegg for nåværende tema kun $ role-> add_cap (selv :: CAP_METRIC);  funksjon remove_servermetric_caps () // get_role returnerer en forekomst av WP_Role. $ role = get_role ('administrator'); $ roll-> remove_cap (selv: CAP_METRIC);  // //

Vi lager en ny konstant samtale CAP_METRIC og sett verdien til server_metric slik at vi enkelt kan endre kapasitetsnavnet senere. Vi endrer vår løpe Metode for å legge til to kroker.

Register_activation_hook kjører når du aktiverer plugin. Den aksepterer to parametere:

1. (streng) filnavn: bane til hovedpluginfilen
2. (Ring tilbake) (nødvendig) Funksjonen som skal kjøres når plugin er aktivert

register_deactivation_hook kjører når deaktiverer plugin. Den aksepterer samme parameter som register_activation_hook.

Innenfor hver tilkoblet funksjon vil vi laste inn rollen administrator og ring add_cap eller remove_cap på rollen objektet.

Deretter vil vi endre vår add_dashboard_widgets metode for å bare registrere widgets hvis den nåværende brukeren har servermetric lokk.

 / ** * Registrer dashboard widget proider å dukke opp på dashbordet * / funksjon add_dashboard_widgets () hvis ! Current_user_can (selv: CAP_METRIC)) return false;  $ widget = Widget :: forekomst (); foreach ($ widget-> get_provider () som $ name => $ leverandør) $ widget-> register ($ navn); 

Deretter bruker vi current_user_can for å sjekke om den nåværende brukeren har forespørselsevnen eller ej.
Nå vil bare administratoren se widgeten når du laster oversikten. Hvis du vil aktivere serverstatus widgeten for andre brukere, kan du installere plugin User Role Editor for å administrere roller og evner for alle brukere. 
Når du er installert og aktivert, gå til menyen Brukere, velg Bruker> Muligheter:

Deretter på funksjonsskjerm, kan vi tilordne server_metric lokk.

Rediger brukerfunksjoner med plugin for User Role Editor

Ved å utnytte roller og evner, forbedret vi vår plugin-sikkerhet for å gjøre widgeten tilgjengelig for kun brukeren vi stoler på.

Caching Server Metric

WordPress bruker Transient API som en cache API. Dataene er serialisert og lagret i wp_option tabell av WordPress med en utløpstid for cachen. 

I stedet for å få metriske data på hver HTTP-forespørsel, kan vi få dataene en gang og cache den. Vi kan imidlertid ikke bare legge alt i cachen eller bruke samme utløpstid. For eksempel kan diskplass lagres i 15 minutter, og serverinformasjon kan bufres i 60 minutter siden de sjelden endres. På samme måte kan installert programvare bufres for en dag, da det sjelden endres når serveroppsettet og forutsatt produksjon.

Vi bruker det meste get_transient og set_transient når du arbeider med API. I følge WordPress-dokumentasjonen:

1. get_transient ($ forbigående): Hent det forbigående navnet som streng og returner dets data. Hvis dataene er utløpt, returnerer den falsk. Vi burde bruke === operatør å sjekke fordi vi kan lagre en tom verdi for forbigående.
2. set_transient ($ forbigående, $ verdi, $ utløp): henter tre parametere: det forbigående navnet, dets verdi og dets utløpstid i andre. Merk at det forbigående navnet ikke skal være lengre enn 45 tegn.
   

Våre to alternativer er å vurdere å cache de metriske dataene eller cache de genererte HTML-dataene. Caching HTML-dataene kan gjøre nettstedet vårt veldig fort, men det legger en last på databasen. For det formål kunne vi gjøre mål for å bestemme hvilket som er best. 

For vår veiledning, la oss bare cache de metriske dataene. Dessuten bør vi ha en måte å ugyldiggjøre cachen - som et anker - som gjør at vi kan laste om dataene på dashbordet og tvinge dataene i stedet for fra cachen.

Caching Data for Widget

Vi kan direkte bruke funksjonen get_transient eller set_transient å jobbe med Transient API. Men hvis vi bestemmer oss for å endre måten vi brukte Transient API, må vi gå over hvert sted vi bruker det og endre det for hver widget. 

La oss legge til ett lag til å trekke opp cachemekanismen. Vi vil designe en enkel hurtigbufferklasse for vår widget som har tre metoder:

1. sett: Angi cacherdata for en widget
   
2. få: Få cacherdata for en widget
   
3. laste: Prøv å laste fra cache, hvis ikke eksistert, beregne data, angi cachen og returnere
   

La oss komponere filen widget / cache.php på følgende måte. Vær oppmerksom på at klassenavnet som vår automatisk lastekonvensjon vil være cache og navnets navn er AX \ StatBoard \ Widget

get_metric (); statisk :: sett ($ leverandør, $ data, $ cache_time); returner $ data;  

Merk først at vi har merket våre caching-metoder som statiske. Våre sett og få metoder er bare wrappers for  get_transient og set_transient. De laste Metoden sitter på toppen av sett og få. Alle disse metodene forventer å hente widgetleverandørobjektet; derfor, inne i laste Metode vi kan påberope get_metric metode for å få de virkelige dataene. 
Her er det viktigste navnet det forbigående navnet. Siden klassenavnet er unikt i vår søknad, anser vi det unikt nok for det forbigående navnet. get_class-funksjonen returnerer klassenavnet til et objekt.
Tid for å bruke vår cache klasse. Vi vil prøve å implementere cache til widget / software.php. Endre vår original get_content metode for å:

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

Du kan se at vi blir kvitt $ cmds = $ this-> get_metric () og bare erstatte det med Cache :: belastning som vil laste data fra cachen, eller vil laste det fra systemet hvis det ikke finnes noen buffer. 
Pass på at du passerer den andre parameteren for hvor lenge du vil at dataene skal bufres Ellers blir dataene bare bufret i fem minutter. Fordi programvareinformasjon på server sjelden endres på kort sikt, setter vi hurtigbuffertiden til 24 timer.
Nå som du har ideen, kan du gjenta med hver annen widget som du vil cache. Bare erstatt get_metric innsiden get_content med:

Cache :: load ($ dette, $ time_in_second);

å få det ta seg av sin caching.
Dataene for diskbruk kan bufres i flere timer, og Ethernet-grensesnittet kan være cache for en dag eller så. Det er opp til deg å bestemme hvor lenge du vil cache den. Vi kan også opprette en opsjonsside for plugin-modulen for å administrere denne levetidens cache-verdi. Det kan være en øvelse for deg å jobbe på etter at vi har fullført denne artikkelen.
Vi har et siste eksempel med widget / ethernet.php. Vi kan legge til cache-evne som følger:

offentlig funksjon get_content () 
$ grensesnitt = Cache :: load ($ dette, 3600 * 24 * 7);
$ html = '


';
foreach ($ grensesnitt som $ grensesnitt => $ ip) 
$ html. = "


";

$ html. = '
Interface
IP
$ Grensesnitt
$ Ip
';
ekko $ html;

  // ... 

Igjen, vi trenger bare å erstatte get_metric med Cache :: belastning. Ethernetinformasjonen og dens IP-adresse sannsynligvis aldri endres, så jeg legger en veldig lang cache livstid til en uke: 3600 sekunder * 24 timer * 7 dager.

Kraft laster inn ekte data

Når vi har lagt til en cache-evne, bør vi støtte en mekanisme slik at administratoren kan trekke widgeten uten at den blir cached. Den enkleste måten å gjøre dette på er å bruke en spesiell søkeparameter for å indikere at vi vil ha ekte data. 

Hva med liten parameter som nocache for dette? Så i stedet for standard WordPress dashboard URL med domain.com/wp-admin/ Vi kan bruke domain.com/wp-admin/?nocache. 

Lyd lett? La oss gjøre det.

Rediger vår metode få i widget / cache.php

 statisk funksjon får (Provider $ provider) if (isset ($ _ GET ['nocache']))) return false;  $ cache_id = get_class ($ leverandør); hvis (false! == $ data = get_transient ($ cache_id)) return $ data;  returner falsk; 

Så lenge som nocache forespørselsparameter eksisterte, returnerer vi falsk umiddelbart, og derfor tvinges de virkelige dataene til å bli hentet i stedet for bufret data.
La oss nå tenke på å legge til denne funksjonen uten hurtigbufferklassen. Vi må kanskje gå til hver linje av get_transient og sjekk etter forespørselsparameteren der. Derfor, vurder å bryte ting ned i mange lag når du designer pluginet ditt. Ikke legg alt i samme fil eller kopier pastakode igjen og igjen.
Nå, la oss prøve å besøke domain.com/wp-admin og domain.com/wp-admin?nocache og legg merke til den forskjellige hastigheten.987ms loading med hurtigbuffer aktivering

Her er resultatet med ?nocache = 1 lagt til URL-adressen.

3,01 sekunder lasting uten cache

Bruk cronjob til å generere cache

Selv om vi implementerte og brukte en cache, er siden fortsatt sakte hvis cachen mangler. Det trenger fortsatt tid til å trekke data fra serveren. Vi har fortsatt plass til å forbedre med cronjob. Vi kan planlegge vårt plugin for å bli kjørt på et bestemt intervall. WordPress tillater oss å gjøre dette via wp_schedule_event. Ideelt sett kan vi bruke wp_schedule_event å planlegge en krok som vil bli utført ved et bestemt intervall.

Når vi ser på dette eksempelet, kan plugin-modulen planlegge en krok for å påkalle hvert tredje minutt, kroken vil igjen påkalle en annen funksjon for å hente metriske dataene. Dataene er alltid tilgjengelige i cache og frisk nok.

Åpne vår hoved plugin-fil, serverdashboard.php, og oppdater løpemetoden for å inkludere ny krok samt ny krokhåndterer.

 3 * 60, 'display' => __ ('En gang hvert tredje minutt')); returner $ tidsplaner;  / ** * Oppsettplan for hendelsen. Hvis tidsplanen ikke eksisterer, * registrerer vi det til * / funksjon setup_schedule () if (! Wp_next_scheduled ('metric_generate_every_3min')) wp_schedule_event (tid (), '3min', 'metric_generate_every_3min');  / ** * Hovedfunksjonen som kjører på cron og * genererer data * / funksjon generate_metric () $ widget = Widget :: forekomst (); foreach ($ widget-> get_provider () som $ name => $ leverandør) // Ved å ringe get_content, utløser vi Cache :: load prosess. $ Av operatør> get_content (); 

For det første støtter wp_schedule_event-metoden bare tre gjentatte typer: daglig, time og twicedaily. Vi må legge til en ny type gjentakelse med wp_get_schedules filter. 
Vi legger til en gjenværende type som kjører hvert tredje minutt. Dens definisjon:

 $ tidsplaner ['3min'] = array ('interval' => 3 * 60, 'display' => __ ('En gang hvert tredje minutt')); returner $ tidsplaner;

Vi kan tilpasse intervallverdien til hvor mange sekunder vi vil at jobben skal gjentas. Neste settes vi opp a metric_generate_every_3min krok.

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

Dette er vår tilpassede krok, den finnes ikke i WordPress. Vi registrerer et håndtak med metode generate_metric for den kroken. Når som helst metric_generate_every_3min krok er påkalt, generate_metric vil bli utført.
I neste utsagn henger vi i handling i det med setup_schedule Metode for å sjekke at eksistensen av den neste planlagte hendelsen på kroken finnes metric_generate_every_3min. Hvis det ikke er definert, planlegger vi et arrangement med wp_schedule_event, bruker vår egendefinerte gjentagelse hvert tredje minutt for den kroken.
Inne i generate_metric metode, vi sløyfe gjennom all tilgjengelig widget gi, og ringe deres get_content metode. Ved å gjøre det, utløser vi Cache :: belastning prosess for den metriske.
WordPress vil automatisk kjøre de planlagte hendelsene når noen besøker ditt WordPress-nettsted. Det vil forsøke å finne den planlagte hendelsen som må kjøres og påkalle den.
Du kan imidlertid også kjøre dem manuelt. WordPress kjører cronjob via å besøke filen wp-content.php med nettadressen yourdomain.com/wp-cron.php?doing_wp_cron.
Du vil kanskje oppdatere cronjoben din for å legge til en ny jobb som pinger nettadressen ovenfor hvert minutt
La oss åpne crontab på server med crontab -e og legg til denne linjen på slutten av den:

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

Vi brukte wget til å lage en HTTP-forespørsel til wp-cron.php-filen. Siden vi ikke bryr oss om utdata og noe feil, omdirigerer vi alle utdataene til / Dev / null.
Du kan lese mer om hvordan du konfigurerer disse cronjobene i følgende artikler:

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

Konklusjon

Dette avslutter vår lange opplæring om hvordan du bygger en serverdashboard-widget som gir innblikk i ulike aspekter av systemet vårt.
Gjennom hele denne serien har vi brukt tredjepartsbiblioteker, tatt en ide, eksperimentert med kommandolinjen, lært om Roller og evner, og gjennomgått WordPress 'Transient-kapasiteter, så vel som hendelsesplanleggingsmekanismer.
Endelig bundet vi alt sammen i et WordPress-plugin.
Vennligst vurder å legge igjen en kommentar og gi oss beskjed om hvilke ekstra ideer og endringer du møter, samt eventuelle spørsmål og / eller kommentarer du måtte ha om denne serien.