Sekretess och optimering av en WordPress Dashboard Widget

Vad du ska skapa

I de två första delarna av den här serien avslutade vi ett komplett plugin som visar vår serverstatus som instrumentbräd widget. Som sådan är den tillgänglig för alla inloggade användare. En del information kan vara känslig och vi vill inte att de ska se det så det är bättre att kontrollera användarrollen för att avgöra om vi ska göra widgeten tillgänglig för dem.

Använda roller eller förmåga att begränsa synligheten

WordPress använder ett koncept Roller, utformat för att ge webbplatsen ägaren möjlighet att styra vad användare kan och inte kan göra inom webbplatsen. Varje roll får utföra en uppsättning uppgifter som heter Kapacitet. Vi kan anpassa rollen och dess funktioner med add_roles och add_cap funktioner.

Vår plugin skapar ett nytt kapacitetssamtal servermetric. Endast användaren som har den möjligheten kan ladda våra widgetar i instrumentbrädan. Vi lägger till denna möjlighet för administratörsroll så alla administratörs användare ser det som standard.

För de andra användarna kan du använda plugin User Role Editor för att hantera funktionerna för en viss användare och tilldela servermetic förmåga för användaren.

Vi använder add_cap för att lägga till en ny funktion, men den här funktionen skriver till databasen, så vi borde bara göra det när du aktiverar plugin. När du har avaktiverat bör vi städa upp databasen genom att ta bort rollen med remove_cap.

klass Dashboard // ... annan kod const CAP_METRIC = 'server_metric'; / ** * Börja med att installera krok * / public function run () 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'));  / ** * Lägg till severmetric förmåga för admin som standard * / funktion add_servermetric_caps () // får författarrollen $ role = get_role ('administrator'); // Det här fungerar bara, eftersom det går åt klassens instans. // skulle tillåta författaren att redigera andras inlägg för aktuellt tema bara $ role-> add_cap (själv :: CAP_METRIC);  funktion remove_servermetric_caps () // get_role returnerar en instans av WP_Role. $ role = get_role ('administrator'); $ roll-> remove_cap (själv :: CAP_METRIC);  // //

Vi skapar ett nytt konstant samtal CAP_METRIC och sätta sitt värde till server_metric så vi kan enkelt ändra kapacitetsnamnet senare lätt. Vi ändrar vårt springa Metod för att lägga till två krokar.

Register_activation_hook körs när du aktiverar plugin. Den accepterar två parametrar:

(sträng) filnamn: sökväg till huvud pluginfilen
(ring tillbaka) (nödvändig) Funktionen som ska köras när plugin är aktiverad

register_deactivation_hook körs när deaktiverar plugin. Den accepterar samma parameter som register_activation_hook.

Inne i varje ansluten funktion laddar vi rollen administratör och ringa add_cap eller remove_cap på rollobjektet.

Därefter kommer vi att ändra vår add_dashboard_widgets Metod för att bara registrera widgets om den nuvarande användaren har servermetric keps.

 / ** * Registrera dashboard widget proider att dyka upp på instrumentbrädan * / function add_dashboard_widgets () if (! Current_user_can (self :: CAP_METRIC)) return false;  $ widget = Widget :: instans (); foreach ($ widget-> get_provider () som $ name => $ provider) $ widget-> register ($ name);

Därefter använder vi current_user_can för att kontrollera om den nuvarande användaren har begäranskapacitet eller inte.
Nu kommer bara administratören att se widgeten när du fyller i instrumentpanelen. Om du vill aktivera serverstatus widgeten för andra användare kan du installera plugin User Role Editor för att hantera roller och funktioner för alla användare.
När du är installerad och aktiverad, gå till menyn Användare, välj Användare> Möjligheter:

Sedan kan vi tilldela server_metric keps.

Redigera användarfunktioner med plugin för användarrollredigerare

Genom att använda roller och funktioner förbättrade vi vår pluginsäkerhet för att göra vår widget tillgänglig för endast användare som vi litar på.

Caching Server Metric

WordPress använder Transient API som ett cache API. Uppgifterna serialiseras och lagras i wp_option tabellen med WordPress med cachens löptid.

Istället för att få metriska data på varje HTTP-förfrågan kan vi hämta uppgifterna en gång och cache den. Vi kan dock inte helt enkelt lägga allt i cachen eller använda samma utgångstid. Diskutrymme kan till exempel cachas i 15 minuter och serverinformation kan cachas i 60 minuter eftersom de sällan ändras. På samma sätt kan installerad programvara cachas för en dag eftersom det sällan ändras när serverns inställning och är avsedd för produktion.

Vi använder mest get_transient och set_transient när du arbetar med API: n. Enligt WordPress-dokumentationen:

get_transient ($ gående): Hämta det transienta namnet som sträng och returnera dess data. Om uppgifterna har löpt ut, returneras det falskt. Vi borde använda === operatör att kontrollera eftersom vi kan lagra ett tomt värde för övergående.
set_transient ($ transient, $ value, $ expiration): hämtar tre parametrar: det transienta namnet, dess värde och dess utgångstid i andra. Observera att det övergående namnet inte ska vara längre än 45 tecken.

Våra två alternativ är att överväga att cache de metriska data eller cache genererade HTML-data. Cachning av HTML-data kan göra vår webbplats mycket snabb, men den lägger en belastning på databasen. För det ändamålet kunde vi göra riktmärke för att bestämma vilket som är bäst.

För vår handledning, låt oss bara cache metriska data. Dessutom bör vi ha ett sätt att invalidera cacheminnet - som ett ankare - som gör det möjligt för oss att ladda om instrumentpaneldata och tvinga in data i stället för från cacheminnet.

Cachningsdata för widgeten

Vi kan direkt använda funktionen get_transient eller set_transient att arbeta med Transient API. Om vi bestämmer oss för att ändra hur vi använde Transient API måste vi dock gå över alla ställen vi använder det och ändra det för varje widget.

Låt oss lägga till ytterligare ett lager för att abstrakt cachemekanismen. Vi kommer att designa en enkel cacheklass för vår widget som har tre metoder:

uppsättning: Ange cacherdata för en widget
skaffa sig: Hämta cacherdata för en widget
ladda: Försök ladda från cacheminne, om det inte existerade, beräkna data, ställ in cacheminnet och returnera

Låt oss komponera filen widget / cache.php på följande sätt. Observera att klassnamnet kommer att vara vår automatiska laddningskonvention cache och dess namnrymd är AX \ StatBoard \ Widget

get_metric (); statisk :: set ($ provider, $ data, $ cache_time); returnera $ data;

Först märker vi att vi har markerat våra caching-metoder som statiska. Vår uppsättning och skaffa sig metoder är bara wrappers för get_transient och set_transient. De ladda Metoden sitter ovanpå uppsättning och skaffa sig. Alla dessa metoder förväntar sig att hämta widgetleverantörsobjektet; därför inuti ladda metod vi kan åberopa get_metric metod för att få den verkliga data.
Här är det viktigaste saken det övergående namnet. Eftersom klassnamnet är unikt inom vår ansökan anser vi det vara unikt nog för det övergående namnet. get_class-funktionen returnerar klassnamnet på ett objekt.
Tid för att använda vår cache klass. Vi kommer att försöka genomföra cache för widget / software.php. Ändra vårt original get_content metod för att

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

Du kan se att vi blir av med $ cmds = $ this-> get_metric () och ersätt det enkelt med Cache :: belastning som laddar data från cacheminnet, eller laddar det från systemet om ingen cache existerade.
Var noga med att skicka den andra parametern i hur länge du vill att data ska cachas. Annars cachas data endast i fem minuter. Eftersom programvaruinformation på servern sällan ändras på kort sikt ställer vi cachetiden till 24 timmar.
Nu när du har tanken kan du repetera med alla andra widgets som du vill cache. Byt bara ut get_metric inuti get_content med:

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

att få det ta hand om sin caching.
Uppgifterna om diskanvändning kan cachas i timmar, och Ethernet-gränssnittet kan vara cache för en dag eller så. Det är upp till dig att bestämma hur länge du vill cache det. Vi kan också skapa en options sida för plugin för att hantera detta livstid cachevärde. Det kan vara en övning för dig att arbeta på när vi har slutfört denna artikel.
Vi har ett slutligt exempel med widget / ethernet.php. Vi kan lägga till cache-förmåga enligt följande:

offentlig funktion get_content () 
$ gränssnitt = Cache :: ladda ($ this, 3600 * 24 * 7);
$ html = '


';
foreach ($ gränssnitt som $ interface => $ ip) 
$ html. = "


";

$ html. = 'Gränssnitt IP
$ Gränssnitt $ Ip
';
echo $ html;

  // ...

Gränssnitt	IP
$ Gränssnitt	$ Ip

Återigen behöver vi bara byta ut get_metric med Cache :: belastning. Ethernetinformationen och dess IP-adress förändras troligen aldrig så jag ställer in en mycket lång cache livstid till en vecka: 3600 sekunder * 24 timmar * 7 dagar.

Kraften laddar in reella data

När vi har lagt till en cache-förmåga bör vi stödja en mekanism så att administratören kan dra widgeten utan att den cachas. Det enklaste sättet att göra detta är att använda en särskild sökparameter för att indikera att vi vill ha riktiga data.

Vad sägs om liten parameter som nocache för detta? Så istället för standard WordPress dashboard URL med domain.com/wp-admin/ vi kan använda domain.com/wp-admin/?nocache.

Ljud lätt? Vi gör det.

Redigera vår metod skaffa sig i widget / cache.php

 statisk funktion get (Provider $ provider) if (isset ($ _ GET ['nocache']))) return false;  $ cache_id = get_class ($ provider); om (false! == $ data = get_transient ($ cache_id)) returnera $ data;  returnera false;

Så länge som nocache frågeparametern existerade, returnerar vi falskt omedelbart och därför tvingas den verkliga data hämtas i stället för cachad data.
Låt oss nu tänka på att lägga till den här funktionen utan cacheklassen. Vi kan behöva gå till varje rad av get_transient och kontrollera efterfrågeparametern där. Därför överväga att bryta saker ner i många lager när du utformar ditt plugin. Lägg inte allt i samma fil eller kopiera pastakod om och om igen.
Nu ska vi försöka besöka domain.com/wp-admin och domain.com/wp-admin?nocache och märka den olika hastigheten.

987ms laddar med cache-aktivera

Här är resultatet med ?nocache = 1 bifogas URL-adressen.

3,01 andra laddning utan cache

Använda cronjob för att generera cache

Även om vi genomförde och använde en cache, är det fortfarande långsamt om cacheminnet saknas. Det behöver fortfarande tid att dra data från servern. Vi har fortfarande utrymme att förbättra med cronjob. Vi kan schemalägga vårt plugin för att köras vid ett visst intervall. WordPress tillåter oss att göra detta via wp_schedule_event. Idealiskt kan vi använda wp_schedule_event att schemalägga en krok som kommer att utföras vid ett visst intervall.

Om vi tittar på det här exemplet kan vårt plugin schemalägga en krok för att anropa var tredje minut, kroken kommer i sin tur att påkalla en annan funktion för att hämta metriska data. Uppgifterna är alltid tillgängliga i cache och tillräckligt färskt.

Öppna vår huvudsakliga pluginfil, serverdashboard.php, och uppdatera körmetoden för att inkludera ny krok samt ny krokhanterare.

 3 * 60, 'display' => __ ('En gång var tredje minut')); returnera $ scheman;  / ** * Inställningsschema för händelse. Om schemat inte finns, * registrerar vi det till * / funktion setup_schedule () if (! Wp_next_scheduled ('metric_generate_every_3min')) wp_schedule_event (time (), '3min', 'metric_generate_every_3min');  / ** * Huvudfunktionen som körs på cron och * genererar data * / funktion generate_metric () $ widget = Widget :: instance (); foreach ($ widget-> get_provider () som $ name => $ provider) // Genom att ringa get_content utlöser vi Cache :: load process. $ Operatörs-> get_content ();

För det första stöder metoden wp_schedule_event endast tre återkommande typer: dagligen, timme och twicedaily. Vi måste lägga till en ny typ av återkommande med wp_get_schedules filter.
Vi lägger till en återkommande typ som körs var tredje minut. Dess definition:

 $ scheman ['3min'] = array ('interval' => 3 * 60, 'display' => __ ('En gång var tredje minut')); returnera $ scheman;

Vi kan anpassa intervallvärdet till hur många sekunder vi vill att jobbet ska upprepas. Därefter installerar vi a metric_generate_every_3min krok.

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

Detta är vår anpassade krok, det finns inte i WordPress. Vi registrerar ett handtag med metod generate_metric för den kroken. Närhelst metric_generate_every_3min krok påkallas, generate_metric kommer att utföras.
I nästa uttalande kopplas vi till handling i det med setup_schedule metod för att kontrollera att det finns nästa planerade händelse i kroken metric_generate_every_3min. Om det ännu inte är definierat planerar vi en händelse med wp_schedule_event, Använd vår anpassade återkommande för var tredje minut för den där kroken.
Inuti generate_metric metod, vi slår igenom all tillgänglig widget tillhandahålla och ringa deras get_content metod. Genom att göra det utlöser vi Cache :: belastning bearbeta för den metriska.
WordPress kör automatiskt de schemalagda händelserna när någon besöker din WordPress-webbplats. Det kommer att försöka hitta den schemalagda händelsen som måste köras och åberopa den.
Du kan dock också köra dem manuellt. WordPress kör cronjob via att besöka filen wp-content.php med webbadressen yourdomain.com/wp-cron.php?doing_wp_cron.
Du kanske vill uppdatera din cronjob för att lägga till ett nytt jobb som pingar ovanstående URL varje minut
Låt oss öppna din crontab på server med crontab -e och lägg till den här raden i slutet av den:

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

Vi använde wget för att göra en HTTP-begäran till wp-cron.php-filen. Eftersom vi inte bryr oss om produktionen och eventuella fel saker, omdirigerar vi all utdata till / Dev / null.
Du kan läsa mer om hur du konfigurerar dessa cronjob i följande artiklar:

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

Slutsats

Detta avslutar vår långa handledning om hur man bygger en server-instrumentbräd widget som ger insikter till olika aspekter av vårt system.
Under hela serien har vi använt bibliotek från tredje part, tagit en idé, experimenterat med kommandoraden, lärt sig Roller och förmågor och granskade WordPress 'Transient-funktioner samt dess schemaläggningsmekanismer.
Slutligen bundet vi allt ihop i ett WordPress-plugin.
Tänk på att lämna en kommentar och meddela oss vilka ytterligare idéer och ändringar du kommer med, liksom eventuella frågor och / eller kommentarer du kanske har om den här serien.

Koda