Bruke navneområder og autolading i WordPress-pluginprogrammer, del 4

Hvis dette er den første opplæringen du leser i denne serien, så anbefaler jeg på det sterkeste å ta opp med det vi har dekket så langt.

I hovedsak kommer du inn på slutten av showet. På dette tidspunktet har vi lagt grunnlaget for pluginet vårt, skrevet pluginet, og definert og utforsket navnerom og autoloaders. Alt som er igjen er å bruke det vi har lært.

Så i denne opplæringen skal vi sette alle delene sammen. Spesielt skal vi besøke kildekoden til pluginet vårt, navneområde alle relevante klasser, og skrive en autoloader slik at vi kan fjerne alle våre inkluderte uttalelser.

Jeg skal diskutere alt i detalj når vi jobber gjennom koden. Igjen, hvis dette er den første opplæringen du leser i denne serien, ta opp med det vi har dekket så langt og gå tilbake til denne opplæringen.

Før vi skriver noen kode

Ved dette punktet bør du være kjent med hvordan vi har satt opp utviklingsmiljøet vårt. Som en oppdatering, her er en rask oversikt over programvaren vi bruker:

  • minst PHP 5,6.20
  • Apache webserveren
  • en MySQL databaseserver
  • WordPress 4.6.1
  • et arbeidskunnskap om WordPress Plugin API

Du skal også ha en kopi av kildekoden til pluginet som vi jobber med. Du kan ta en kopi av den her. Forutsatt at den er installert, aktivert, og du har din IDE kjører, la oss komme i gang.

Namespacing koden

Påminnelse fra forrige veiledning, er jeg fan av å sørge for at navneområdene våre følger organisasjonen av filene på disken. Hvis du ser på katalogstrukturen til plugin-modulen, eller hvis du har fulgt med serien så langt, bør du se noe slikt:

Merk at hvis du har konfigurert pluginet ditt annerledes, er det greit. Ditt navneområde vil trolig være annerledes, men det bør ikke påvirke noe som er dekket i denne serien.

Ved hjelp av katalogstrukturen som en retningslinje, la oss gå gjennom alle PHP-filene som utgjør vårt plugin og definere deres navneområder. Å gjøre dette er enkelt: Det er rett og slett et spørsmål om å bruke navneområdet søkeord og plassere et kvalifisert navn øverst på hver fil.

Jeg vil liste hver enkelt nedenfor.

tutsplus-namespace-demo.php

klasse-meta-box.php

klasse-meta-box-display.php

grensesnitt-assets.php

klasse-css-loader.php

klasse-spørsmålet-reader.php

Det er noen ting å legge merke til om de konvensjonene jeg har brukt ovenfor:

  • Rotenavnene er Tutsplus_Namespace_Demo, som tilsvarer katalognavnet til plugin.
  • Resten av navneområder som Tutsplus_Namespace_Demo \ Admin og Tutsplus_Namespace_Demo \ Admin \ Util svarer også til deres respektive kataloger; men katalognavnet er cased (versus å være i små bokstaver).

Endelig, hvis du har forsøkt å oppdatere siden, eller du har forsøkt å navigere rundt WordPress siden du introduserte namespace-setningene, ser du sannsynligvis en feil i konsollen som ser slik ut:

Og det inkluderer følgende melding:

PHP Advarsel: call_user_func_array () forventer at parameter 1 skal være en gyldig tilbakeringingsfunksjon, 'tutsplus_namespace_demo' ikke funnet eller ugyldig funksjonsnavn i /Users/tommcfarlin/Dropbox/Projects/tutsplus/wp-includes/plugin.php på linje 524

Eller kanskje det viser:

PHP Fatal feil: Klassen 'Meta_Box' ikke funnet i /Users/tommcfarlin/Dropbox/Projects/tutsplus/wp-content/plugins/tutsplus-namespace-demo/tutsplus-namespace-demo.php på linje 48

Eller du kan se et antall andre lignende feilmeldinger. Det er ok. Det er normalt.

Men det reiser spørsmålet: Hva skjer med plugin? Heldigvis, ingenting. Dette er forventet atferd.

Den første meldingen du ser kan være et resultat av et annet plugin du har installert. Jeg kunne ikke reprodusere det på egen hånd; Men når jeg deaktiverer noen av de andre plugins jeg har kjørt, genererte plugin den andre meldingen (som er meldingen jeg ønsket å demonstrere).

Når du namespace-kode, forventer PHP å finne en klasse innenfor et gitt navneområde. Konseptuelt kan du tenke på klassene dine som nå tilhører egen pakke (eller subpackage) eller hvor du definerer den. Og for at en funksjon skal få tilgang til en klasse i en pakke, må den gjøres oppmerksom på pakkene som eksisterer.

Dette er der ekstra navneplassfunksjonalitet og autoloading kommer inn i spill. Så før vi går om å prøve å få tilgang til koden via deres navneområder, la oss jobbe med en autoloader.

Alt om autoloading

Skrive en autoloader vil kreve følgende:

  1. forstå en PHP-funksjon kalt spl_autoload_register
  2. skriver en funksjon som automatisk laster inn våre navngitte filer
  3. inkludert vår egendefinerte autoloading-funksjon

Ikke la navnet spl_autoload_register skremme deg. Det betyr bare at dette er en funksjon som er en del av "Standard PHP Library", og det er hvordan vi "registrerer" en "autoload" -funksjon. Det er en munnfull å si og mange tegn å skrive, men det er bare en funksjon som vi skal bruke for å fortelle PHP hvordan man analyserer namespaces og klassenavn og hvor den kan finne våre filer.

Denne funksjonen gjør det mulig for oss å skrive vår egen tilpassede kode for autoloading-filer og deretter koble den aktuelle funksjonen til PHP. Det vil si, vi skal fortelle PHP hvor du skal finne våre filer og hvordan du analyserer navnerom, filnavn og så videre slik at det vil inkludere filene.

Med alt det som er sagt, er vi klare til å faktisk skrive en autoloader.

Skrive en autoloader

Når du skriver en autoloader, er tingen å huske på hvordan våre filer er organisert. Det vil si, vi vil vite hvordan å kartlegge våre navneområder til våre kataloger. 

I eksemplet vi bruker, er det enkelt: Navneområdene er forkortede versjoner av katalogstrukturen. Dette gjelder ikke alltid for andre prosjekter; Det er imidlertid enda en grunn til at jeg logisk organiserer filene mine basert på deres fysiske plassering.

Når PHP prøver å laste inn en klasse, må vår autoloader nødt til å gjøre følgende:

  1. Del opp navneområdet opp basert på skråstreket.
  2. Del pakken og delpakken opp basert på underskrifter og erstatt dem med bindestreker (om nødvendig).
  3. Vet hvordan du kartlegger klassenavn, grensesnitt og så videre til filnavn.
  4. Opprett en strengrepresentasjon av filnavnet basert på informasjonen ovenfor.
  5. Inkluder filen.

Med alle disse punktene har vi fått vårt arbeid skåret ut for oss. I plugin-katalogen, opprett en underkatalog som heter inc, og i inc katalog opprette en fil som heter autoload.php.

Innenfor den filen, la oss gå videre og stub ut funksjonen som vi skal bruke for å autoload våre filer. Det skal se slik ut:

Det er åpenbart at dette ikke gjør noe enda.

En sideanvisning om å skrive en autoloader

Merk at jeg skal skrive koden og kodekommentarene for å forklare hva vi gjør. Hvis du bare venturer inn i dette på egen hånd for første gang, kan det være litt frustrerende å skrive en autoloader sammen med å bruke navneområder og arbeide med filer. Det er her en debugger og bruk av loggfiler kan komme til nytte. 

Dette er utenfor omfanget av denne opplæringen, men vet at det å skrive en autoloader ikke er noe du kan få riktig første gang du gjør det.

Fullfører Autoloader

La oss begynne å legge til noen funksjonalitet gitt trinnene som er oppført i begynnelsen av denne delen.

Først må vi sette opp en sløyfe som skal iterere bakover gjennom delene av filnavnet som sendes inn i autoloading-funksjonen. Vi gjør dette fordi det gjør det enklere å bygge en bane til filen til autoload.

 0; $ i--) // Mer å komme ... 

Etter dette må vi se på $ file_parts og erstatt alle forekomster av understrekingen med en bindestrek, fordi alle våre klassenavn og brukergrensesnitt understreker mens våre filnavn bruker bindestreker.

Følgende to linjer er de to første linjene innsiden av løkken som vi stubbet ut over:

Deretter skal vi trenge en betinget som gjør noen ting.

  1. Det må sjekke for å se hvilken oppføring av banen til filnavnet som vi leser.
  2. Hvis vi er på den første oppføringen, så er vi på filnavnet; Ellers er vi på sitt navneområde.
  3. Neste, hvis vi leser den første oppføringen, må vi avgjøre om vi prøver å autoload et grensesnitt eller vi laster inn en klasse.
  4. Hvis det er det første, må vi justere navnet på grensesnittet slik at vi laster det riktig på grunnlag av filnavnet. ellers laster vi klassen basert på verdien i $ strøm variabel.

Det leser som mye, men det bør ikke være veldig komplisert å lese. Se kommentert kode nedenfor:

Når det er gjort, er det på tide å bygge en fullstendig kvalifisert sti til filen. Heldigvis er dette lite mer enn grunnstrengssammenheng:

Til slutt må vi sørge for at filen eksisterer. Hvis ikke, viser vi en standard WordPress-feilmelding:

Og på dette tidspunktet har vi en full autoloader (som kan hentes ved å laste ned filene fra koblingen i sidelinjen til dette innlegget som kildekoden ville være litt lang tid å legge inn her i opplæringen).

Endelig er det viktig å merke seg at denne funksjonen kunne (eller burde) bli omskrevet som en klasse. Videre skal klassen bestå av flere mindre funksjoner som kan testes, ha et enkelt ansvar, og les mer tydelig enn hva som er nevnt ovenfor. Kanskje i en bonusopplæring, vil jeg gå gjennom prosessen med det som ville se ut.

Men vi inneholder fortsatt filer

Hvis du ser nær toppen av hovedpluginfilen (eller bootstrap-filen som vi ofte har kalt det), vil du legge merke til flere inkludere uttalelser som ser slik ut:

Gitt det arbeidet vi har gjort opp til dette punktet, kan vi endelig fjerne disse uttalelsene og erstatte dem med bare ett:

For å være klar erstatter vi den med vår autoloader. På dette tidspunktet bør vi gjøres med vårt plugin.

Sette alt sammen

Nå som vi har navngitt vår kode for å gi en logisk organisering av relaterte klasser og skrevet en autoloader for automatisk å inkludere filer basert på hver klasses navneområde og filplassering, bør vi kunne starte pluginet og få det til å kjøre akkurat som det gjorde under den første vellykkede iterasjonen.

Det siste vi må gjøre er å sørge for at vi oppdaterer bootstrap-filen, slik at vi instruerer PHP til å bruke navneområdene for Meta_Box, Meta_Box_Display, de Question_Reader, og CSS_Loader.

i det(); $ Meta_box-> init (); 

Legg merke til i koden ovenfor bruker vi PHP bruk søkeord, og vi prefikserer våre klassenavn med sine umiddelbare underpakker. Du kan lese mer om bruk i håndboken, men kort av det er:

De bruk Søkeordet må deklareres i det ytre omfanget av en fil (det globale omfanget) eller innenfor navneområdedeklarasjoner. Dette skyldes at importen er ferdig på kompileringstid og ikke kjøretid, slik at den ikke kan blokkeres. 

Med det sagt og antar alt arbeidet riktig, bør du kunne navigere til Legg til nytt innlegg side (eller Rediger innlegg), se vår meta-boks, og se et spørsmålstegn langs toppen av sidefeltet:

Hvis ja, så gratulerer. Du har opprettet pluginet ditt til navneområder og autolading. Hvis ikke, dobbeltkryss koden mot det vi har delt her, gjennomgå feilloggene dine, og kontroller at ingenting vises utenom det vanlige i WordPress-administrasjonsskjermbildet.

Hvis du gjøre se noe, odds er det har å gjøre med noe mindre. Gå gjennom koden vi har dekket, sammenlign den med hva som er vedlagt her til dette innlegget (i sidefeltet sammen med den store blå knappen), og se om du kan begrense problemet.

Konklusjon

På dette tidspunktet har vi nådd slutten av serien vår. Gjennom de siste fire opplæringsprogrammene har vi dekket mye grunnlag:

  • Vi har bygget et plugin som ber om brukere med spørsmål for å hjelpe kickstart deres blogging.
  • Vi har brukt PHP-funksjoner for å lese filer fra filsystemet og gjengi det i displayet.
  • Vi har definert namespaces og autoloading, og tatt en titt på hvordan de kan brukes.
  • Vi har organisert vår kode og skrevet vår egen autoloader, noe som gjør koden mer lesbar, organisert og mindre rotete.

Til slutt kan mye av materialet dekket gjennom denne serien brukes i eksisterende og fremtidige prosjekter som du kan jobbe med. 

Husk at du også kan finne andre WordPress-relaterte produkter i vår markedsplass. Og hvis du vil lære mer om å utvikle løsninger for WordPress, kan du finne alle mine opplæringsprogrammer og serier på min profilside. Ikke nøl med å følge meg på bloggen min eller på Twitter når jeg diskuterer programvareutvikling i forbindelse med WordPress nesten daglig.

Og husk, linken er for nedlasting av den endelige kildekoden er i sidefeltet under en knapp med tittelen Last ned vedlegg. Selvfølgelig, ikke nøl med å stille spørsmål i kommentarene!

ressurser

  • spl_autoload_register
  • bruk