Grunnleggende om å bygge et WordPress Server Dashboard

Hva du skal skape

Folk klager ofte på at WordPress er treg. Hvorvidt dette er sant, avhenger av mange faktorer, men hvis vi kan se serverressurser inne i WordPress-dashbordet, kan det gi litt innsikt om hvor godt vår WordPress-installasjon er i drift.

I denne opplæringen skal vi lage et plugin for å vise serverstatus, inkludert diskplass, minneforbruk, CPU-bruk og prosessbruk.

Vi vil også lære om WordPress-cache for å unngå å spørre disse metriske om og om igjen, og vi vil også dekke WordPress cron-jobber for å generere disse dataene automatisk..

Administratorens dashboard presenterer som standard oss et par blokker kalt widgets. Disse inkluderer:

Med et blikk
Aktivitet
Raskt utkast
WordPress News
Velkommen

Widgetene kan bestilles på nytt, og kan vises eller skjules - generelt sett kan dashbordet tilpasses.

Siden widgets er svært fleksible og tilgjengelige rett på den første skjermen på administrators skjermen, kan vi bruke dem til å vise serverressurs: diskstatus, RAM-bruk, CPU-bruk og operativsysteminformasjon. Vi vil kalle disse ressursene "beregninger" for kort.

Gjennom dette seriøse lærer vi Dashboard Widgets API og roller og evner for å gjøre disse widgets tilgjengelige for noen brukere fordi dataene kan være sensitive.

For å gjøre det, vil vi også lære noen grunnleggende Linux-kommandoer for å trekke serverinformasjon og frø til vårt widgetdashboard. Vi vil bruke Transients API til å cache disse dataene. Cronjobs blir leveraged til å trekke disse dataene automatisk i stedet for å få dem på forespørsel på hver forespørsel.

Arbeidet med vårt plugin er inspirert av Linux Dash.

Vårt plugin støtter ni typer beregninger. Som et resultat vil vi ha ni dashbord-widgets.

Serverinformasjon: operativsystemet, Linux-kjernen, oppetiden, osv.
CPU-belastning: gjennomsnittlig belastning på CPU i 1, 5 og 15 minutter
RAM-bruk av fysisk RAM og byttefil
Diskbruk
Installert programvare
prosesser
Ethernet
Nettverksytelse
IO stat

Krav

Et Linux-miljø. Mac OS X er fortsatt et alternativ, men noen av kommandoene for å sjekke overstående beregninger er ikke tilgjengelige, så hvis du mottar en kommando ikke funnet feil, vet du at det ikke er Mac-støtte for den kommandoen.
Grunnleggende forståelse av skallet
Grunnleggende WordPress plugin forståelse.

Plugin Skeleton Structure

La oss lage en enkel plugin og ringe den Server Dashboard. Vi vil begynne med noen grunnleggende ting. En tradisjonell Hei Verden vil hjelpe deg å få en smak av å legge til en widget på dashbordet.

Det er enkelt, faktisk.

Opprette et mappeanrop Server Dashboard innsiden wp-innhold / tillegg, og en fil serverdashboard.php. Mappeoppsettet ser slik ut. Bare fokus på hovedfilen og ignorere bin, tester, widgets og så videre.

Bruk denne koden for serverdashboard.php

løpe(); ?>

Jeg brukte navneområde AX \ StatBoard for å unngå navnekollisjon med forskjellige plugins-klasser, funksjonsnavn for temaer og andre plugins.
Jeg brukte også Singleton Pattern for å få et unikt eksempel på plugin-klasse. Jeg opprettet en metode løpe å registrere krok eller filter med WordPress.
For å legge til en widget må vi koble til handling wp_dashboard_setup. Disse krokene gir oss tilgang til Dashboards relaterte tilpasningsalternativ. Det gjør at vi kan legge til eller fjerne dashbord-widgeten fra WordPress.
Inne i krokfunksjonen bruker vi wp_add_dashboard_widget å registrere en widget. Det krever argumenter i denne rekkefølgen:

Widget ID brukes til å identifisere slug for widgeten din. Denne slug brukes når du gjengir CSS ID, klasse og som nøkler i widget array.
Widget Tittel viser på tittelen på widget-boksen
Ring tilbake å gjengi innholdet av widgeten. Det skal skrive ut innhold direkte, trenger ikke å returnere.

Mesteparten av tiden møter vi tilbakeringinger som en enkelt funksjon, en anonym funksjon, en rekke objekt og metode, eller en rekke klassiske og statiske metoder.

Oppdater dashbordet ditt. Vårt plugin viser sin widget. Legg merke til id av widget div element.

Vår plugin er widgeten vises med sin ID og innhold

La oss fremme dette. Vi viser et kakediagram med noen dummy-data. For å holde ting enkelt, bruker jeg Google Chart API. Vi vil i stor utstrekning bruke den senere til servermålinger fordi det er bedre å visualisere denne typen data.

Hvis du ikke liker Google-diagram, kan du kvitte seg med det og sette favorittkortbiblioteket ditt. Husk at dette er en veiledning, så begrens ikke deg selv - bruk hva du er komfortabel med å bruke!

Vi må laste inn Google Chart-skriptet. Forandre din løpe() metode for å registrere en mer krok.

 Public Function Run () add_action ('wp_dashboard_setup', array ($ dette, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ dette, 'add_asset'));

admin_enqueue_scripts er handlingen du må koble til for å legge til ditt eget skript i administratorens dashbord. Vi vil legge til en ekstra metodeanrop add_asset i vår klasse for å håndtere skriptlasting. Redskapet av add_asset.

 / ** * Legg til javascript * / funksjon add_asset () wp_enqueue_script ('google-chart', 'https://www.google.com/jsapi');

Vi har kartbiblioteket. Nå må vi gjøre det inne i dashbordet vårt. Du kan leke med Google Chart. Vi vil bare gjenta deres eksempel nå.

funksjon add_dashboard_widgets () syslog (LOG_DEBUG, "Run"); wp_add_dashboard_widget ('hello_world_dashboard_widget', // En slug for å identifisere denne widgeten 'Hello World', // Widget title function () echo <<<'EOD' Hey, I'm the body of widget. Thanks for bring me to the life.  
  EOD;  // funksjon for å gjengi innhold av widget, jeg bruker en nedleggelse her);

Vi legger bare til ett div div med id hello_piechart og gjengi diagram i det elementet. La oss se hva vi fikk nå:

Legg merke til ID av widgetelementet.

Nå som vi vet hvordan du legger til vår egen widgetblokk i dashbordet, og nå som vi vet hvordan du får Google-diagram til å gjengi informasjon, kan vi kombinere de to for å vise mer informasjon.

I neste avsnitt lærer vi hvordan vi tar tak i servermålinger, og gir innhold for hver type servermåling som vi tidligere har diskutert.

Trekker Server Metrics

Når du trekker server beregninger, bruker vi kommandoen til Linux for å få denne informasjonen. I PHP kan vi bruke backtick "eller shell_exec for å påkalle en shell-kommando, og hente utgangen.

Vi kan analysere utdataene for å få serverdata. For eksempel, for å få diskbruksstatus kan vi bruke kommandoen df -h. Vi vet formatet for produksjonen, så vi kan analysere det for å få det vi ønsker.

 $ df = 'df -h'; $ df = eksplodere ("\ n", $ df); hvis (is_array ($ df) && count ($ df)> = 2) array_shift ($ df); // Slett den første linjen $ df = array_map (funksjon ($ linje) hvis (tom ($ linje)) return NULL; $ segment = preg_split ('/ \ s + /', $ linje) 'filesystem' => $ segment [0], 'size' => $ segment [1], 'used' => $ segment [2], 'tilgjengelig' => $ segment [3], 'use_percent' => $ segment [4];);, $ df); var_dump ($ df);

Rengjøring med AWK

For å hjelpe rydde utgangen rett fra skallkommandoen, kan vi kombinere med awk. Denne lenken ser skummel ut med mye informasjon, men vi vil bare bruke en liten mengde av det i denne opplæringen. Forklare awk er utenfor omfanget av denne opplæringen.
Hvis du vil lære mer om awk, bruk dette cheatsheet. I utgangspunktet bruker vi awk til å behandle hver utgangslinje, og på hver linje blir strengen delt med tabulator eller mellomrom, og elementet kan være tilgang som variabel med $ 1 for første element, $ 2 for andre element og så videre. Syntaxen er: [command_we_run] | awk 'skriv ut $ 1, $ 3, ...'.
La oss se på følgende eksempel:

☁ Server Dashboard [master] ls -lh totalt 32 -rw-r - r-- 1 kureikain-ansatte 2.6K Apr 11 00:46 Server Dashboard.php drwxr-xr-x 3 kureikain-ansatte 102B Mar 29 01:27 bin - rw-r - r-- 1 kureikain-stab 98B Apr 5 18:53 loader.js -rw-r - r-- 1 kureikain-stab 321B 29. mars 01:27 phpunit.xml drwxr-xr-x 4 kureikain-ansatte 136B Mar 29 01:27 tester drwxr-xr-x 12 kureikain-ansatte 408B Apr 13 17:37 widget -rw-r - r-- 1 kureikain-ansatte 1.1K Apr 6 01:04 widget.php ☁ Server Dashboard [master] ls -lh | awk 'print $ 3, $ 4, $ 5, $ 9' kureikain staff 2.6K Server kureikain staff 102B bin kureikain staff 98B loader.js kureikain staff 321B phpunit.xml kureikain staff 136B tester kureikain staff 408B widget kureikain staff 1.1K widget.php

Som du kan se hver linje av ls-la inneholder ni felt:

drwxr-xr-x 4 kureikain-stab 136B 29. mars 01:27 tester

Separering av mellomrom, disse 9 feltene er:

drwxr-xr-x
4
kureikain
personale
136B
mar
29
01:27
tester

Jeg kan bruke awk til bare å ta navn, gruppe, størrelse og fil / mappe navn i tilsvarende felt 3, 4, 5, 9 awk 'skriv ut $ 3, $ 4, $ 5, $ 9' og jeg vil se:

kureikain ansatte 136B tester

Derfor, ved å bruke awk, kan vi rydde opp produksjonen litt mer før vi går inn i vår PHP-behandlingsfunksjon.

Rengjør med GREP

Noen kommandoer gir ekstra data som vi ikke trenger; Derfor krever det litt ekstra innsats med PHP for å rydde opp det.

For eksempel:

[vagrant @ vagrant-centos64 ~] $ gratis -m totalt brukt gratis delte buffere cached Mem: 589 537 51 0 8 271 - / + buffere / cache: 258 330 Bytte: 255 0 255

gratis -m viser oss RAM-bruken med minne og bytte-fil; men det inkluderer to andre linjer med totalt / brukt / gratis og - / + buffere / cache som vi kanskje ikke trenger.
Vi ønsker bare å trekke informasjon om Mem og swap - det vil si linje 3 og linje 5. En av måtene å oppnå dette er å bruke grep med -E bytte om. Denne bryteren tillater bruk å bruke vanlig ekspres for søking. Fordi vi ønsker å finne linjen med ord Mem og bytte, la kombinere med grep -E "Mem | Swap".
Her er resultatet.

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

Så det er mye renere. Kombiner begge grep og awk Vi kan rydde opp data og få bare det vi trenger.

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

Linux-kommandoer for å få serverinformasjon

Vi må lære noen kommandoer for å trekke serveren beregninger, så la oss åpne serveren vår, og prøv å skrive under kommandoen for å få en rask smak.

Sjekk nettverkstrafikk

$ netstat-i Kernel Interface-tabell Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 5538339494 0 0 0 6216082004 0 0 0 BMRU eth0: 1 1500 0 - ingen statistikk tilgjengelig - 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

Sjekk diskbruk

df -h Filsystemstørrelse Brukt Avail Bruk% Montert på / dev / sda7 2.0G 660M 1.3G 35% / / dev / sda8 1.0T 632G 340G 66% / hjem / 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

Sjekk RAM-bruk

gratis -m totalt brukt gratis delte buffere cached Mem: 32189 32129 59 0 419 9052 - / + buffere / cache: 22656 9532 Bytte: 32767 4 3276

Vi vil bruke mer kommando senere, men over dem gir deg en grunnleggende kommando for å se hva vi kan få fra serveren rett på kommandolinjen.

Byg widgeten

Vi vil refactor vår opprinnelige klasse i forrige seksjon litt. Vær oppmerksom på at, med mindre det er klart annet, lager vi alle filer og mapper innenfor vår plugin katalog.

Først vil vi ikke manuelt inkludere filer. Vi vil skrive en automatisk klasselaster for det formålet. Når en manglende klasse er initialisert, vil vi sjekke klassenavnet og prøve å inkludere kildefilen som holder klasses Definisjon.

Vi bruker navneområder som banen og klassenavnet som filnavn. For eksempel en klasse foo i navneområde AX \ StatBoard bør være i roten til plugin-mappen. En klasse buzz i navneområde AX \ StatBoard \ Bar bør være i Bar \ buzz.php

Mappe layout struktur med navneområde, klassenavn og filnavn for automatisk lasting.

Med det for øye, la oss gå videre og begynne å lage vår auto loader-metode:

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

 / **
 * Setup variabel og intialize widget leverandør
 * /
 funksjon __construct () 
 $ dette -> _ plugin_dir = plugin_dir_path (__FILE__);
 spl_autoload_register (array ($ this, 'load_class'));
 

 // ...

Så hva skjer her? Vårt plugin bruker navneområde AX \ StatBoard. Så vi sørger for at den forespurte klassen under dette navneområdet skal håndteres av pluginet vårt, ellers er ikke vår autoladere i stand til å laste dem. Vi striper deretter AX \ StatBoard i klassenavn og erstatt den med banen til plugin-mappen. Bakslaget \ i navneområdet erstattes med / bane separator, og legge til php forlengelse. Det betyr at navneområdet vil bli brukt som banen til mappen inneholder klassefil, og klassenavnet er filnavnet. Inkludering skjer bare hvis filen eksisterer. Nå har vi automatisk laster, vi trenger fortsatt å la PHP vite at vi har en automatisk laster, og vi vil bruke den. PHP inkluderer spl_autoload_register til dette formålet. Vi legger den i vår klassekonstruktør.
For det andre, la oss designe vår widget-klasse. Vi har flere typer server-metriske å vise. Det er bedre å vise hver av metriske i en separat widget blokk, slik at disse widgets kan sorteres eller ordnes, eller tilpasses for å skjule eller vise. Hvis du legger all informasjon inn i samme widget, vil kostnadene for kontroll vise / gjemme hver av metriske til vårt plugin.
Forutsatt at du vet om funksjonen wp_add_dashboard_widget, Vi må gi tittelen og innholdet. I samsvar med hver widget, vil vi ha en klasse for å gjengi tittel og innhold for det. Vi kaller disse klassene er widget Forsørger. Alle widgetleverandører må definere get_title () og get_content () å gjengi innhold.
For det formål vil vi opprette en Forsørger grensesnitt, og har vår widgetleverandørklasse implementere dette grensesnittet. Vi må også opprette en ekstra metallsamtale get_metric () å trekke serverdata.
Opprett fil widget / provider.php med dette innholdet:

Dette er et grensesnitt. Vi krevde at alle widgetleverandører må implementere dette grensesnittet, og derfor sikrer vi at tat-widgetleverandørklasse alltid har disse tre metodene.
Vi vil opprette en annen klasse Widget å administrere disse leverandørene. Vi lager leverandørklasser, og leverer dem til Widget klasse og visning Widget klassen som et enkelt poeng for oss å be om en leverandør når vi trenger det. Vi kan ganske enkelt sette alt inn i vår hovedpluginfil, og bare opprette klasseeksempel med ny operatør når vi trenger, men det er vanskelig å vedlikeholde senere. 
Når vi bryter ned i mange lag, er det lettere å teste og utvide. Når vi får alle tilbydere til å bli administrert av en enkelt klasse, kan vi bruke den ene klassen til å gjøre det samme over settet av leverandører. Vi kan enkelt legge til flere leverandører når som helst, ved å bare opprette et objekt som implementerer leverandørklassen og mate dem til Widget klasse
Skriv en fil widget.php i rotkatalogen av plugin-mappen.

navneområde AX \ StatBoard;
bruk AX \ StatBoard \ Widget \ Provider;

klassen Widget 
 const WIDGET_SLUG_PREFIX = 'AX';

 beskyttet $ _providers = array ();
 beskyttet statisk $ _instance;

 statisk funksjon forekomst () 
 returnere selv: $ _ instance = self :: $ _ instance?: nytt selv ();
 

 funksjon __construct () 
 

 / **
 * Legg til en widgetleverandør
 * @param streng widget navn
 * @param leverandørobjekt for å håndtere widgetinnholdsgjengivelse
 * / 
 offentlig funksjon add_provider ($ navn, Provider $ handler) 
 $ dette -> _ leverandører [$ navn] = $ handler;
 returner $ dette;
 

 / **
 * Få alle leverandører eller en bestemt leverandør
 * /
 offentlig funksjon get_provider ($ name = NULL) 
 hvis (! $ navn) 
 returnere $ dette -> _ leverandører;
 
 returner $ dette -> _ leverandører [$ navn];
 

 / **
 * Registrer en widget for å gjengi den.
 * /
 offentlige funksjonsregister ($ navn) 
 $ slugid = selv :: WIDGET_SLUG_PREFIX. $ Navn;
 $ widget_provider = $ this-> get_provider ($ navn);
 hvis (tomt ($ widget_provider)) 
 returner falsk;
 

 wp_add_dashboard_widget (
 $ slugid,
 $ Widget_provider-> get_title (),
 array ($ widget_provider, 'get_content'));
 returnere sant;
 


Igjen bruker vi Singleton-mønsteret til vår Widget-klassen. Et raskt sammendrag av vår metode her.
 De add_provider Metoden vil legge til et widgetleverandobjekt til widgetleverandørlisten. Vi bruker også typen hinting for å sikre at objektet passerer til add_provider må være a Forsørger ved å implementere vår Forsørger grensesnitt.
 De get_provider Metoden kan returnere en liste over alle leverandører, eller en bestemt leverandør.
 De registrere Metoden vil faktisk registrere vårt leverandørobjekt med WordPress for å gjengi en dashbord-widget med wp_add_dashboard_widget. IDen til widgeten er generert basert på prefikset, en forhåndsdefinert konstant og klassenavnet til widgeten. Tittelen vil og innholdet vil trekke via get_title og get_content av leverandøren. Vi sørget for at de implementerer vårt leverandørgrensesnitt. Med denne registreringsmetoden abstrakt vi implementeringen av å legge til widgeten i dashbordet. Alt vi trenger å gjøre nå er å ringe registrere med navnet på leverandøren som vi legger til før med add_provider. Med dette i bakhodet, når WordPress API endres, trenger vi ikke å gå til alle steder wp_add_dashboard_widget, Vi oppdaterer nettopp på ett sted.
 

Kommer tilbake vår opprinnelige hoved plugin-fil serverdashboard.php, Vi vil initialisere alle tilbydere og legge dem til leverandørliste over Widget-objekt.
 _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 ($ dette -> _ dashboard_widget som $ element) hvis (! file_exists ($ this -> _ plugin_dir. '/ widget /'. $ item. '.php')) forts;  $ classname = 'AX \\ StatBoard \\ Widget \\'. ucwords ($ element); Widget :: instance () -> add_provider ($ item, new $ classname ()); 

Vi vil sette alle widgetleverandørklasser under navneområde AX \ StatBoard \ Widget og derfor vil de sitte inne i mappen widget. Vi støtter ni typer metriske og vi heter klassen som svarer til matrisen _dashboard_widgets ovenfor. 
For hver av widgetene lager vi en ny forekomst av leverandøren, og legger til i Widget klasse. Her er hva vi får senere med denne strukturen:
Husk at vi hekta inn wp_dashboard_setup, og inne i det kaller vi funksjonen wp_add_dashboard_widget å legge til ny widget i dashbordet. Deretter har vi vår registrere metode for dette formålet. Vi slår over alle tilføyede leverandører, og registrerer dem. Oppdater innholdet av add_dashboard_widgets av serverdashboard.php bli til:
 
 / ** * Registrer dashboard widget proider å dukke opp på dashbordet * / funksjon add_dashboard_widgets () $ widget = Widget :: forekomst (); foreach ($ widget-> get_provider () som $ name => $ leverandør) $ widget-> register ($ navn); 


Deretter vil vi hekte inn admin_footer for å sende inn inline JavaScript nederst på admin siden for å initialisere Google Chart Class-pakken. Våre løpe() Metoden er også oppdatert for ny krok.
 / ** * 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'));  / ** * Inline JavaScript for diagram * / funksjon footer () echo '  '; 

For øyeblikket fullførte vi grunnleggende, og hovedinnstillingsfilen skulle se slik ut.
_plugin_dir. strtolower (str_replace ('\\', '/', $ classname). '.php'); hvis (! file_exists ($ filepath)) return false;  inkluderer $ filepath;  / ** * Oppsettvariabel og intialiser widgetleverandør * / funksjon __construct () $ this -> _ plugin_dir = plugin_dir_path (__FILE__); spl_autoload_register (array ($ this, 'load_class')); $ this -> _ dashboard_widget = array ('server', 'cpuload', 'ram', 'disk', 'programvare', 'prosess', 'ethernet', 'networkio', 'iostat'); foreach ($ dette -> _ dashboard_widget som $ element) hvis (! file_exists ($ this -> _ plugin_dir. '/ widget /'. $ item. '.php')) forts;  $ classname = 'AX \\ StatBoard \\ Widget \\'. ucwords ($ element); Widget :: instance () -> add_provider ($ item, new $ classname ());  / ** * Lag en unik forekomst gjennom app * / offentlig statisk funksjon instans () returner selv: $ _ instance = self :: $ _ instance?: Nytt selvtillit ();  / ** * Begynn å konfigurere krok * / offentlig funksjon kjøre () add_action ('wp_dashboard_setup', array ($ this, 'add_dashboard_widgets')); add_action ('admin_enqueue_scripts', array ($ dette, 'add_asset')); add_action ('admin_footer', array ($ this, 'footer'));  / ** * Registrer dashboard widget proider å dukke opp på dashbordet * / funksjon add_dashboard_widgets () $ widget = Widget :: forekomst (); foreach ($ widget-> get_provider () som $ name => $ leverandør) $ widget-> register ($ navn);  / ** * Aktiver laster: stilark, JS. * / funksjon add_asset () syslog (LOG_DEBUG, "Loaded"); wp_enqueue_script ('google-diagram', 'https://www.google.com/jsapi'); // wp_enqueue_script ('plugin_dir_url', plugin_dir_url (__ FILE__). '/loader.js');  / ** * Inline JavaScript for diagram * / funksjon footer () echo '  ';  Dashboard :: forekomst () -> run (); 
Vi lager i utgangspunktet en forekomst av hovedtilleggsklassen og kaller løpemetoden. Som i sin tur bare sette opp en liste over krok. Hver krok er en annen metode inne i klassen. Vi lager og registrerer også leverandørobjektet vårt med Widget gjenstand.
Hva blir det neste?
På dette punktet viser vi fortsatt ikke noe; Men vi la ut en struktur for vår plugin-annonse begynte å knytte seg til Google Charts.
Du kan laste ned hele skriptet fra nedlastingslinkene øverst i denne artikkelen. Vi vil gå inn i redigeringsdetaljene til hver widgetleverandør i neste artikkel, så sørg for at du følger neste del. 
Jeg håper du likte denne artikkelen. Legg igjen kommentarer med noen av dine tanker, og jeg vil være sikker på å svare på dem.




		
			
	   
	




Kode