De basisprincipes van het bouwen van een WordPress-serverdashboard

Wat je gaat creëren

Mensen klagen vaak dat WordPress traag is. Of dit waar is hangt van veel factoren af, maar als we serverresources in het WordPress-dashboard kunnen zien, kan het inzicht geven in hoe goed onze WordPress-installatie werkt.

In deze zelfstudie maken we een plug-in om de serverstatus weer te geven, inclusief schijfruimte, geheugenconsumpties, CPU-gebruik en procesgebruik.

We zullen ook meer te weten komen over de WordPress cache om te voorkomen dat deze waarden steeds opnieuw worden geraadpleegd en we zullen ook WordPress cron-taken behandelen om deze gegevens automatisch te genereren.

Het beheerdersdashboard presenteert ons standaard een aantal blokken met de naam widgets. Waaronder:

In een oogopslag
Activiteit
Snel concept
WordPress Nieuws
Welkom

De widgets kunnen bij voorkeur opnieuw worden besteld en kunnen worden weergegeven of verborgen. Over het algemeen kan het dashboard worden aangepast.

Omdat widgets zeer flexibel zijn en direct op het eerste scherm van het beheerdersscherm beschikbaar zijn, kunnen we ze gebruiken om serverresources weer te geven: schijfstatus, RAM-gebruik, CPU-gebruik en informatie over het besturingssysteem. We zullen deze bronnen "metrics" noemen.

In deze serie leren we de Dashboard Widgets-API en -rollen en -mogelijkheden om deze widgets beschikbaar te maken voor sommige gebruikers omdat de gegevens gevoelig kunnen zijn.

Om dat te doen, zullen we ook enkele standaard Linux-commando's leren om serverinformatie en seed naar ons widget dashboard te trekken. We gebruiken Transients API om deze gegevens in de cache op te slaan. Cronjobs zullen worden gebruikt om automatisch deze gegevens te verzamelen in plaats van ze op verzoek op te vragen.

Het werk van onze plug-in is geïnspireerd op Linux Dash.

Onze plug-in ondersteunt negen soorten statistieken. Als gevolg hiervan hebben we negen dashboard-widgets.

Serverinformatie: het besturingssysteem, de Linux-kernel, de up-time, enz.
CPU-belasting: gemiddelde belasting van de CPU in 1, 5 en 15 minuten
RAM-gebruik van fysiek RAM en wisselbestand
Schijfgebruik
Geïnstalleerde software
Processen
Ethernet
Netwerkprestaties
IO stat

Vereisten

Een Linux-omgeving. Mac OS X is nog steeds een optie, maar sommige van de opdrachten om de bovenstaande statistieken te controleren zijn niet beschikbaar, dus als u een opdracht niet gevonden foutmelding ontvangt, weet u dat er geen Mac-ondersteuning is voor die opdracht.
Basisbegrip van de schaal
Basic WordPress plugin-begrip.

De plug-in skeletstructuur

Laten we een eenvoudige plug-in maken en deze noemen Server Dashboard. We zullen beginnen met enkele basisdingen. Een traditionele Hallo Wereld zal je helpen om een widget aan het dashboard toe te voegen.

Het is eenvoudig, eigenlijk.

Een mapoproep maken Server Dashboard binnen wp-content / plugins, en een bestand serverdashboard.php. De indeling van de map ziet er als volgt uit. Concentreer u gewoon op het hoofdbestand en negeer de prullenbak, tests, widgets enzovoort.

Gebruik deze code voor serverdashboard.php

rennen(); ?>

Ik heb naamruimte gebruikt AX \ StatBoard om naamsbotsing te voorkomen met verschillende pluginsklasse, functienaam van thema's en andere plug-ins.
Ik heb ook het Singleton-patroon gebruikt voor een uniek exemplaar van de plugin-klasse. Ik heb een methode gemaakt rennen om haak of filter te registreren bij WordPress.
Om een widget toe te voegen, moeten we in actie komen wp_dashboard_setup. Deze hooks verlenen ons toegang tot de aangepaste aanpassingsoptie van Dashboard. Hiermee kunnen we de dashboardwidget van WordPress toevoegen of verwijderen.
Binnen de haakfunctie gebruiken we wp_add_dashboard_widget om een widget te registreren. Het vereist argumenten in deze volgorde:

Widget ID wordt gebruikt om slak te identificeren voor je widget. Deze slug wordt gebruikt bij het renderen van CSS-id, klasse en als sleutels in widgetarray.
Widget titel wordt weergegeven op de titel van de widgetbox
Bel terug om de inhoud van een widget weer te geven. Het zou de inhoud rechtstreeks moeten uitvoeren, hoeft niet terug te keren.

Meestal zullen we callbacks tegenkomen als een enkele functie, een anonieme functie, een array van object en methode, of een array van klasse en statische methode.

Ververs je dashboard. Onze plug-in toont de widget. Let op de ID kaart van widget div element.

Onze plugin is widget wordt weergegeven met zijn ID en inhoud

Laten we dit bevorderen. We zullen een cirkeldiagram tonen met enkele dummy-gegevens. Om het simpel te houden, zal ik de Google Chart API gebruiken. We zullen het later op grote schaal gebruiken voor serverstatistieken, omdat het beter is om dit soort gegevens te visualiseren.

Als u Google Chart niet leuk vindt, kunt u er vanaf en uw favoriete diagrambibliotheek plaatsen. Vergeet niet dat dit een zelfstudie is, dus beperk jezelf niet - gebruik waar je zin in hebt met gebruiken!

We moeten het Google Chart-script laden. Verander jouw rennen() methode om nog een haak te registreren.

 public function run () add_action ('wp_dashboard_setup', array ($ this, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ this, 'add_asset'));

admin_enqueue_scripts is de actie die u moet uitvoeren om uw eigen script toe te voegen in het beheerdersdashboard. We zullen nog een methodeaanroep toevoegen add_asset in onze klas om script laden aan te kunnen. Het werktuig van add_asset.

 / ** * Voeg javascript * / function add_asset () wp_enqueue_script ('google-chart', 'https://www.google.com/jsapi') toe;

We hebben de kaartenbibliotheek. Nu moeten we het in ons dashboard weergeven. Je kunt spelen met Google Chart. We zullen hun voorbeeld nu gewoon hergebruiken.

function add_dashboard_widgets () syslog (LOG_DEBUG, "Run"); wp_add_dashboard_widget ('hello_world_dashboard_widget', // A Slug om deze widget 'Hello World', // Widget title function () echo te identificeren <<<'EOD' Hey, I'm the body of widget. Thanks for bring me to the life.  
  EOD;  // functie om de inhoud van de widget weer te geven, ik gebruik hier een afsluiting);

We voegen eenvoudig een extra div-element toe met id hello_piechart en maak grafiek in dat element. Laten we eens kijken wat we nu hebben:

Let op de ID van het widgetelement.

Nu we weten hoe we ons eigen widgetblok aan het dashboard kunnen toevoegen en nu we weten hoe Google Chart informatie kan geven, kunnen we deze combineren om meer informatie te tonen.

In het volgende gedeelte zullen we leren hoe we serverstatistieken kunnen halen en inhoud kunnen weergeven voor elk type serverstatistiek dat we eerder hebben besproken.

Servergegevens ophalen

Wanneer u serverstatistieken ophaalt, gebruiken we de opdracht Linux om deze informatie te verkrijgen. In PHP kunnen we backtick "of shell_exec gebruiken om een shell-commando op te roepen en de uitvoer op te halen.

We kunnen de uitvoer analyseren om servergegevens te ontvangen. Als u bijvoorbeeld de schijfgebruiksstatus wilt verkrijgen, kunnen we de opdracht gebruiken df -h. We kennen het formaat van de uitvoer, zodat we het kunnen analyseren om te krijgen wat we willen.

 $ df = 'df -h'; $ df = exploderen ("\ n", $ df); if (is_array ($ df) && count ($ df)> = 2) array_shift ($ df); // Verlaat de eerste regel $ df = array_map (function ($ line) if (empty ($ line)) return NULL; $ segment = preg_split ('/ \ s + /', $ line); return array ( 'bestandssysteem' => $ segment [0], 'formaat' => $ segment [1], 'gebruikt' => $ segment [2], 'beschikbaar' => $ segment [3], 'use_percent' => $ segment [4],);, $ df); var_dump ($ df);

Schoonmaken met AWK

Om de uitvoer recht uit de shell-opdracht op te schonen, kunnen we combineren met awk. Die link ziet er angstaanjagend uit met veel informatie, maar we gebruiken er maar een heel klein deel van in deze zelfstudie. Het uitleggen van awk valt buiten het bereik van deze tutorial.
Als je meer wilt weten over awk, gebruik dan deze cheatsheet. In principe gebruiken we awk om elke regel met uitvoer te verwerken en op elke regel wordt de tekenreeks opgesplitst op tab of spatie en kan het element toegang hebben als variabele met $ 1 voor het eerste element, $ 2 voor het tweede element enzovoort. De syntaxis is: [command_we_run] | awk 'print $ 1, $ 3, ...'.
Laten we het volgende voorbeeld bekijken:

☁ Server Dashboard [master] ls -lh totaal 32 -rw-r - r-- 1 kureikain-personeel 2,6K 11 apr 00:46 Server Dashboard.php drwxr-xr-x 3 kureikain-personeel 102B 29 maart 01:27 bin - rw-r - r-- 1 kureikain-personeel 98B 5 apr. 18:53 loader.js -rw-r - r-- 1 kureikain-personeel 321B 29 maart 01:27 phpunit.xml drwxr-xr-x 4 kureikain-personeel 136B 29 maart 01:27 tests drwxr-xr-x 12 kureikain-personeel 408B 13 april 17:37 widget -rw-r - r-- 1 kureikain-personeel 1.1K 6 apr 01:04 widget.php ☁ Server Dashboard [master] ls -lh | awk 'print $ 3, $ 4, $ 5, $ 9' kureikain personeel 2.6K Server kureikain personeel 102B bin kureikain personeel 98B loader.js kureikain personeel 321B phpunit.xml kureikain personeel 136B tests kureikain personeel 408B widget kureikain personeel 1.1K widget.php

Zoals je kunt zien, is elke regel van ls -la bevat negen velden:

drwxr-xr-x 4 kureikain-personeel 136B 29 maart 01:27 tests

Door te scheiden door spaties, zijn deze 9 velden:

drwxr-xr-x
4
kureikain
personeel
136B
bederven
29
01:27
testen

Ik kan awk gebruiken om de naam, groep, grootte en bestands- / mapnaam in het bijbehorende veld 3, 4, 5, 9 te pakken awk 'print $ 3, $ 4, $ 5, $ 9' en ik zal zien:

kureikain-personeel 136B-tests

Daarom kunnen we met AWK de uitvoer een beetje meer opruimen voordat we onze PHP-verwerkingsfunctie invoeren.

Opruimen met GREP

Sommige opdrachten voeren extra gegevens uit die we niet nodig hebben; daarom vereist het een beetje extra inspanning met PHP om het op te schonen.

Bijvoorbeeld:

[vagrant @ vagrant-centos64 ~] $ gratis -m totaal gebruikte gratis gedeelde buffers in de cache Mem: 589 537 51 0 8 271 - / + buffers / cache: 258 330 Ruilen: 255 0 255

gratis -m toont ons het RAM-gebruik met geheugen en wisselbestand; nochtans omvat het twee andere lijnen met totaal / gebruikt / vrij en - / + buffers / cache die wij misschien niet nodig hebben.
We willen alleen informatie van Mem en Swap ophalen, dat wil zeggen regel 3 en regel 5. Een van de manieren om dit te bereiken is het gebruik van grep met -E schakelaar. Met deze schakelaar kunt u regulier express gebruiken voor zoeken. Omdat we de regel met woorden Mem en Swap willen vinden, laten we combineren met grep -E "Mem | Swap".
Dit is het resultaat.

[vagrant @ vagrant-centos64 ~] $ free -m | grep -E "Mem | Swap" Mem: 589 536 52 0 8 271 Ruilen: 255 0 255

Dus het is veel schoner. Combineer beide grep en awk we kunnen gegevens opschonen en krijgen alleen datgene wat we nodig hebben.

[vagrant @ vagrant-centos64 ~] $ free -m | grep -E "Mem | Swap" | awk 'print $ 1, $ 2, $ 3, $ 4' Mem: 589 537 52 Ruil: 255 0 255

Linux-opdrachten voor serverinformatie

We moeten enkele opdrachten leren om serverstatistieken op te halen, dus laten we onze servershell openen en proberen hieronder het commando te typen om snel te proeven.

Controleer netwerkverkeer

$ netstat -in Kernelinterfacetabel Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-FOUT TX-DRP TX-OVR Fout eth0 1500 0 5538339494 0 0 0 6216082004 0 0 0 BMRU eth0: 1 1500 0 - geen statistieken beschikbaar - BMRU eth1 1500 0 96707328840 0 0 0 102776317608 0 0 0 BMRU eth2 1500 0 33 0 0 0 7 0 0 0 BMRU lo 16436 0 29461422 0 0 0 29461422 0 0 0 LRU

Controleer schijfgebruik

df -h Bestandsformaat Gebruikt Beschikbaar Gebruik% Gemonteerd op / dev / sda7 2.0G 660M 1.3G 35% / / dev / sda8 1.0T 632G 340G 66% / home / dev / sda6 2.0G 68M 1.9G 4% / tmp / dev / sda5 20G 1.5G 18G 8% / var / dev / sda2 20G 2.1G 17G 12% / usr / dev / sda1 194M 25M 160M 14% / boot / dev / hdb1 459G 277G 159G 64% / backup tmpfs 16G 0 16G 0% / dev / shm

Controleer het RAM-gebruik

gratis -m totaal gebruikte gratis gedeelde buffers in de cache Mem: 32189 32129 59 0 419 9052 - / + buffers / cache: 22656 9532 Ruilen: 32767 4 3276

We zullen later meer commando's gebruiken, maar de bovenstaande geven u een aantal fundamentele commando's om te zien wat we kunnen krijgen van de server op de opdrachtregel.

De Widget bouwen

We zullen onze oorspronkelijke klasse in het vorige gedeelte een beetje refactoren. Merk op dat, tenzij duidelijk anders wordt vermeld, we alle bestanden en mappen zullen maken binnen onze plugin-map.

Allereerst willen we niet handmatig bestanden opnemen. We zullen een autoklasse-lader voor dat doel schrijven. Wanneer een ontbrekende klasse wordt geïnitialiseerd, zullen we de klassenaam controleren en proberen het bronbestand met klassendefinitie op te nemen.

We gebruiken naamruimten als het pad en de klassenaam als de bestandsnaam. Bijvoorbeeld een klas foo in naamruimte AX \ StatBoard moet in de hoofdmap van de plugin-map staan. Een klas gezoem in naamruimte AX \ StatBoard \ Bar zou moeten zijn Bar \ buzz.php

Mappenlay-outstructuur met naamruimte, klassenaam en bestandsnaam voor automatisch laden.

Met dat in gedachten, laten we verder gaan en beginnen met het maken van onze autolader-methode:

_plugin_dir. strtolower (str_replace ('\\', '/', $ classname). '.php'); if (! file_exists ($ filepath)) return false;  include $ filepath;  

 / **
 * Setup-variabele en widget-widget initialiseren
 * /
 function __construct () 
 $ this -> _ plugin_dir = plugin_dir_path (__FILE__);
 spl_autoload_register (array ($ this, 'load_class'));
 

 // ...

Wat gebeurt hier dan? Onze plug-in gebruikt naamruimte AX \ StatBoard. Dus zorgen we ervoor dat de gevraagde klasse onder deze naamruimte wordt afgehandeld door onze plug-in, anders kan onze autolader niet in staat zijn om ze te laden. We strippen dan de AX \ StatBoard in class naam en vervang het door het pad van de plugin map. De backslash \ in naamruimte wordt vervangen door / padscheidingsteken en toevoegen php uitbreiding. Dat betekent dat de naamruimte wordt gebruikt als het pad naar de map een klassenbestand bevat en dat de klassenaam de bestandsnaam is. Inbegrip doet zich alleen voor als het bestand bestaat. Nu hebben we de autolader, we moeten PHP nog laten weten dat we een autolader hebben en we willen het gebruiken. PHP bevat voor dit doel spl_autoload_register. We plaatsen het in onze klassenbouwer.
Ten tweede, laten we onze widgetsklasse ontwerpen. We hebben verschillende typen serverstatistieken om weer te geven. Het is beter om elk van de statistieken in een afzonderlijk widgetblok weer te geven, zodat die widgets kunnen worden gesorteerd of gerangschikt, of aangepast om te verbergen of te tonen. Als alle informatie in dezelfde widget wordt geplaatst, worden de kosten van de controle weergegeven door elk van de statistieken in onze plug-in te verbergen.
Ervan uitgaande dat u weet over de functie wp_add_dashboard_widget, we moeten het de titel en inhoud geven. Overeenkomstig elke widget, hebben we een klasse om de titel en de inhoud ervan te renderen. We noemen deze klasse widget leverancier. Alle widgetproviders moeten definiëren get_title () en Inhoud krijgen() om inhoud weer te geven.
Daartoe zullen we een creëren leverancier interface, en laat onze widgetprovidersklasse deze interface implementeren. We moeten ook nog een methodeaanroep maken get_metric () om servergegevens op te halen.
Maak een bestand aan widget / provider.php met deze inhoud:

Dit is een interface. We vereisten dat elke widgetprovider deze interface moet implementeren en daarom zorgen we ervoor dat de tat widget-providerklasse altijd over deze drie methoden beschikt.
We zullen nog een klas maken widget om deze providers te beheren. We maken providerklassen en geven ze vervolgens uit aan widget klasse en weergave widget Klasse als een enkel punt voor ons om een provider te vragen wanneer dat nodig is. We kunnen alles gewoon in ons hoofdplug-inbestand plaatsen en gewoon klasse-instantie maken met nieuwe wanneer we het nodig hebben, maar het is moeilijk om het later te behouden. 
Wanneer we iets in veel lagen breken, is het gemakkelijker om te testen en uit te breiden. Zodra we alle providers door één enkele klasse laten beheren, kunnen we die ene klasse gebruiken om hetzelfde te doen voor de reeks providers. We kunnen eenvoudig op elk moment meer providers toevoegen door eenvoudigweg een object te maken dat de providerklasse implementeert en voedt widget klasse
Stel een bestand samen widget.php in de hoofdmap van de map van de plug-in.

naamruimte AX \ StatBoard;
gebruik AX \ StatBoard \ Widget \ Provider;

class Widget 
 const WIDGET_SLUG_PREFIX = 'AX';

 beschermd $ _providers = array ();
 beschermd statisch $ _instance;

 static function instance () 
 return self :: $ _ instance = self :: $ _ instance?: new self ();
 

 function __construct () 
 

 / **
 * Voeg een widgetprovider toe
 * @param string widget naam
 * @param provider-object voor het afhandelen van de weergave van widgets
 * / 
 openbare functie add_provider ($ name, Provider $ handler) 
 $ this -> _ providers [$ name] = $ handler;
 stuur $ dit terug;
 

 / **
 * Krijg alle provider of een bepaalde provider
 * /
 openbare functie get_provider ($ name = NULL) 
 if (! $ name) 
 retourneer $ this -> _ providers;
 
 return $ this -> _ providers [$ naam];
 

 / **
 * Registreer een widget om deze te renderen.
 * /
 public function register ($ name) 
 $ slugid = self :: WIDGET_SLUG_PREFIX. name $;
 $ widget_provider = $ this-> get_provider ($ name);
 if (empty ($ widget_provider)) 
 return false;
 

 wp_add_dashboard_widget (
 $ slugid,
 $ Widget_provider-> get_title (),
 array ($ widget_provider, 'get_content'));
 geef waar terug;
 


Nogmaals, we gebruiken het Singleton-patroon voor onze Widget-klasse. Een snelle samenvatting van onze methode hier.
 De add_provider methode voegt een widgetprovider-object toe aan de widgetproviderslijst. We gebruiken ook typehints om ervoor te zorgen dat het object doorgeeft aan add_provider moet een zijn leverancier door onze leverancier interface.
 De get_provider methode kan een lijst van alle providers of een bepaalde provider retourneren.
 De registreren methode zal ons provider-object daadwerkelijk registreren bij WordPress om een dashboardwidget mee te renderen wp_add_dashboard_widget. De ID van de widget wordt gegenereerd op basis van het voorvoegsel, een vooraf gedefinieerde constante en de klassenaam van de widget. De titel zal en de inhoud zal via worden getrokken get_title en get_content van provider. We hebben ervoor gezorgd dat ze onze Provider-interface implementeren. Met deze registermethode abstraheren we de implementatie van het toevoegen van de widget aan het dashboard. Het enige wat we nu hoeven te doen is bellen registreren met de naam van de provider waarmee we eerder hebben toegevoegd add_provider. Met dit in gedachten, wanneer WordPress API verandert, hoeven we niet naar elke plaats te gaan wp_add_dashboard_widget, we updaten gewoon op één plek.
 

Terugkomend op ons originele hoofd-plugin-bestand serverdashboard.php, we zullen alle providers initialiseren en ze toevoegen aan de providerlijst van het Widget-object.
 _plugin_dir = plugin_dir_path (__FILE__); spl_autoload_register (array ($ this, 'load_class')); $ this -> _ dashboard_widget = array ('server', 'cpu_load', 'ram', 'disk', 'diskio', 'software', 'ethernet', 'internetspeed', 'networkio', 'process',); foreach ($ this -> _ dashboard_widget als $ item) if (! file_exists ($ this -> _ plugin_dir. '/ widget /'. $ item. '.php')) ga verder;  $ classname = 'AX \\ StatBoard \\ Widget \\'. ucwords ($ item); Widget :: instance () -> add_provider ($ item, new $ classname ()); 

We zullen alle widgetprovidersklassen onder de naamruimte plaatsen AX \ StatBoard \ Widget en daarom zullen ze in de map gaan zitten widget. We ondersteunen negen soorten statistiek en we noemen de klasse die overeenkomt met de array _dashboard_widgets bovenstaande. 
Voor elk widget maken we een nieuw exemplaar van de provider en voegen we deze toe widget klasse. Dit is wat we later zullen krijgen met deze structuur:
Vergeet niet dat we verslaafd waren wp_dashboard_setup, en daarbinnen noemen we de functie wp_add_dashboard_widget om een nieuwe widget aan het dashboard toe te voegen. Vervolgens hebben we onze registreren methode voor dit doel. We zullen alle toegevoegde providers volgen en registreren. Update de inhoud van add_dashboard_widgets van serverdashboard.php worden:
 
 / ** * Dashboard-widget-proider registreren voor weergave op dashboard * / function add_dashboard_widgets () $ widget = Widget :: instance (); foreach ($ widget-> get_provider () als $ naam => $ provider) $ widget-> registreer ($ naam); 


Vervolgens zullen we inhaken op admin_footer om inline JavaScript aan de onderkant van de beheerpagina uit te voeren voor het initialiseren van het Google Chart-klassenpakket. Onze rennen() methode is ook bijgewerkt voor nieuwe haak.
 / ** * Start met instellen hook * / 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'));  / ** * Inline JavaScript voor chart * / function footer () echo '  '; 

Op dit moment hebben we de basis voltooid en het bestand met de belangrijkste plug-ins zou er als volgt uit moeten zien.
_plugin_dir. strtolower (str_replace ('\\', '/', $ classname). '.php'); if (! file_exists ($ filepath)) return false;  include $ filepath;  / ** * Setup-variabele en widget-provider intialize * / function __construct () $ this -> _ plugin_dir = plugin_dir_path (__FILE__); spl_autoload_register (array ($ this, 'load_class')); $ this -> _ dashboard_widget = array ('server', 'cpuload', 'ram', 'disk', 'software', 'process', 'ethernet', 'networkio', 'iostat',); foreach ($ this -> _ dashboard_widget als $ item) if (! file_exists ($ this -> _ plugin_dir. '/ widget /'. $ item. '.php')) ga verder;  $ classname = 'AX \\ StatBoard \\ Widget \\'. ucwords ($ item); Widget :: instance () -> add_provider ($ item, new $ classname ());  / ** * Maak een uniek exemplaar door de app * / public static function instance () return self :: $ _ instance = self :: $ _ instance?: New self ();  / ** * Start naar setup hook * / 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'));  / ** * Registreer dashboard widget-proider om op dashboard weer te geven * / function add_dashboard_widgets () $ widget = Widget :: instance (); foreach ($ widget-> get_provider () als $ naam => $ provider) $ widget-> registreer ($ naam);  / ** * Activa laden: stylesheet, JS. * / function add_asset () syslog (LOG_DEBUG, "Loaded"); wp_enqueue_script ('google-chart', 'https://www.google.com/jsapi'); // wp_enqueue_script ('plugin_dir_url', plugin_dir_url (__ FILE__). '/loader.js');  / ** * Inline JavaScript voor chart * / function footer () echo '  ';  Dashboard :: instance () -> run (); 
We maken in principe een exemplaar van de hoofdplugineklasse en bellen de run-methode. Die op hun beurt net een lijst met haakjes opzetten. Elke haak is een andere methode binnen de klas. We maken en registreren ook ons provider-object met widget voorwerp.
Wat is het volgende?
Op dit punt tonen we nog steeds niets; We hebben echter een structuur opgesteld voor onze plug-inadvertentie die begon aan Google Charts.
U kunt het volledige script downloaden van de downloadlinks bovenaan dit artikel. We gaan in het volgende artikel in op de details van elke widgetprovider, dus volg het volgende gedeelte. 
Ik hoop dat je dit artikel leuk vond. Laat opmerkingen achter met een van uw gedachten en ik zal ze zeker beantwoorden.




		
			
	   
	




Code