Bruke navnegrupper og autolading i WordPress-plugins, del 2

I den tidligere opplæringen begynte vi å snakke om navneområder og autoloading med PHP i sammenheng med WordPress-utvikling. Og selv om vi aldri faktisk introduserte noen av disse to emnene, definerte vi dem og begynte å legge grunnlaget for hvordan vi skal introdusere dem i en kommende opplæringsveiledning.

Før vi gjør det, er det imidlertid noen funksjonalitet som vi må fullføre for å rulle ut pluginet vårt. Målet er å fullføre pluginet og dets funksjonalitet slik at vi har et grunnleggende, objektorientert plugin som er dokumentert og fungerer bra med en advarsel; det bruker ikke navneområder eller autolading.

Dette vil igjen gi oss sjansen til å se hva et plugin ser ut som før og etter å introdusere disse emnene.

Før jeg fortsetter, anbefaler jeg å lese den forrige opplæringen. På denne måten har du forståelse for hvilke navneområder og autolading, du vil ha den aktive versjonen av plugin-modulen til dette punktet (siden vi skal bygge på det), og da vil du være klar til å Fortsett fra det punktet fremover.

Når du har lest det, vær så snill å komme tilbake til denne opplæringen og gjenoppta arbeidet ditt.

Før vi begynner

Som med alle mine opplæringsprogrammer, antar jeg at du har et utviklingsmiljø på din maskin. Dette inkluderer følgende:

• Et lokalt utviklingsmiljø som inkluderer PHP 5.6.20, Apache-webserveren og en MySQL-databaseserver.
• En katalog ut av hvilken WordPress 4.6 er vert.
• En tekstredigerer eller IDE etter eget valg som du er komfortabel med å bruke til å skrive et plugin.
• Et arbeidskunnskap om WordPress Plugin API.

Hvis du er så langt inn i serien (eller har lest noe av mitt tidligere arbeid), så antar jeg at du allerede har noe som ovenfor allerede på plass. 

Og når du gjør det, er vi klare til å komme i gang.

Hva vi bygger

Husk fra forrige veiledning:

Vi skal bygge et plugin som gjør det enkelt å laste inn stilark og JavaScript-stiler i pluginet vårt, og det viser en meta-boks som ber brukeren om et spørsmål for å hjelpe dem med å brainstorme noe om å blogge.

Ja, det er enkelt og det er ikke sannsynlig noe som noen vil bruke utenfor å studere konseptene vi dekker i denne bloggen. Men måten vi lærer på de konseptene vi bruker, er det som er viktig.

Denne plugin gir oss muligheten til å gjøre akkurat det.

På slutten av den siste opplæringen, dro vi med et plugin som viser et tilfeldig spørsmål til forfatteren øverst på sidepanelet på skjermbildet for WordPress-innlegget.

Hver gang du oppdaterer siden, lastes et nytt spørsmål. Som det står, er det ikke dårlig, men det er noen forbedringer vi kan gjøre når det gjelder stilen av innholdet i meta-boksen.

Det vil si, vi kan presentere stilark som vil hjelpe oss med å skape en litt mer visuelt tiltalende presentasjon. I tillegg vil det gi oss en sjanse til å utforske noen flere objektorienterte teknikker som vi kan bruke når vi jobber med eiendeler som stilark.

Så la oss begynne.

Innføring av stilark

I forbindelse med denne opplæringen skal jeg ikke bruke noen form for preprosessor. Jeg skal bare bruke vanilje CSS. Men måten vi anvender eiendeler på, vil være litt mer objektorientert enn hva mange WordPress-utviklere er vant til å se. 

Dette vil alle bidra til målet om å bruke navneområder og autoloading i denne serien. Men først, la oss begynne med å introdusere disse stilarkene, skape de nødvendige klassegrensesnittene, klassene og kommunikasjonen med WordPress API.

Legg til CSS-filen

I admin katalog, opprett en underkatalog som heter eiendeler. Innen eiendeler katalog, opprett en underkatalog som heter css og legg deretter til filen admin.css. 

Den endelige katalogstrukturen skal se slik ut:

Vi er ikke klare til å gi noen form for stiler ennå. I stedet må vi være oppmerksom på server-side-koden som er ansvarlig for å inkludere dette stilarket.

Legg inn stilarket

Når det gjelder å registrere og enqueuing både stilark og JavaScript, er de fleste WordPress plugin-utviklere kjent med kroker som er nødvendige for å gjøre nettopp det. Spesielt refererer jeg til admin_enqueue_scripts og wp_enqueue_style.

Og selv om vi skal bruke disse krokene, skal vi sette det opp på en enkel, objektorientert måte. Nei, denne serien er ikke ment å ta et dypt dykk inn i objektorienterte prinsipper, men når det er relevant, er jeg glad for å prøve å vise dem til deg.

Aktivitetsgrensesnittet

I objektorientert programmering defineres et grensesnitt som slik:

Et grensesnitt er en programmeringsstruktur / syntaks som gjør at datamaskinen kan håndheve bestemte egenskaper på en klasse.

En annen måte å tenke på er dette: 

Hvis du har en klasse som implementerer et grensesnitt, er klassen må definer funksjonalitet som grensesnittet dikterer.

Så hvis grensesnittet har to metode signaturer med en bestemt synlighet og navn, må klassen som implementerer grensesnittet ha to metoder med samme synlighet og navn, samt en faktisk metodeimplementering..

Og det er det vi skal gjøre. Først må vi definere grensesnittet vårt. Så i util katalog, opprett grensesnitt-assets.php og legg deretter til følgende kode:

Legg merke til at grensesnittet egentlig ikke definerer funksjonalitet. I stedet spesifiserer den hva klassene som implementerer dette grensesnittet bør definere. 
Som du kanskje tror, ​​vil klassene som vil implementere dette grensesnittet ha to metoder ovenfor sammen med en faktisk implementering for hver funksjon. Og vi får se hvordan dette fungerer kort tid.
Deretter må du huske å inkludere denne filen i hovedpluginfilen:
Deretter må vi lage en fil som implementerer dette grensesnittet. Siden vi jobber med CSS-filer, oppretter vi en CSS-laster.
CSS Loader
Dette er klassen som er ansvarlig for å implementere grensesnittet og gjør det faktiske arbeidet med å registrere funksjonen med den nødvendige WordPress-kroken (og faktisk gi implementeringen til nevnte funksjon).
Hvis du ser koden under, bør den se veldig ut som noe du har sett eller kanskje jobbet med i et tidligere prosjekt:
Koden ovenfor bør Vær relativt lett å følge med kodenes kommentarer, men jeg vil skissere hva som skjer:
 
 i det og Enqueue Er begge funksjonene kreves når klassen implementerer Assets_Interface.
 
Når i det kalles, registrerer den Enqueue Funger med kroken som er ansvarlig for å registrere et stilark.
 
De Enqueue metode registrerer admin.css fil og bruk filemtime som en måte å vite om filen har endret seg eller ikke (noe som gjør at vi kan buste enhver cached versjon av filen når den serveres).
 
I denne gjennomføringen, den faktiske admin.css filen er lagt til på hver side. Legge til en betingelse for å sjekke hvilken side som for tiden er aktiv og deretter bestemme om stilarket skal legges til eller ikke, kan legges til som en opplæringsøvelse. For et hint, sjekk ut get_current_screen ().
Deretter må vi inkludere denne filen i hoved plugin-filen:
Deretter må vi instantiere CSS-lasteren og ringe den i det metode i hovedsak tutsplus_namespace_demo funksjon:
i det();
Forutsatt at du har gjort alt riktig, bør du kunne oppdatere Legg til nytt innlegg side, se kilden og se admin.css oppført som et tilgjengelig stilark.
Vi har en ting å gjøre før vi er klare til å pakke opp denne delen av opplæringen. Vi må faktisk skrive noen CSS.
Stil meta-boksen
Siden flertallet av opplæringen har fokusert på noen objektorienterte teknikker, og vi fortsatt har noen nye emner å utforske i denne serien, vil vi gjøre denne delen relativt enkel.
Snarere enn å bare bruke noen standardstiler som tilbys av WordPress, la oss forbedre meta-boksen bare litt. 
Finn først gjengi fungere i Meta_Box_Display klasse. La oss endre det slik at det utdataer innholdet i filen i et avsnitt med ID-attributten for "tutsplus-author prompt".
For å gjøre dette, skal vi introdusere en ny metode som vil bruke en WordPress API-metode for sanitizing HTML. 
 array ('id' => array (),),); returnere wp_kses ($ html, $ allowed_html); 
Vi kaller deretter denne funksjonen inne fra gjengi Metode for å vise innholdet i meta-boksen.
question_reader-> get_question_from_file ($ file); $ html = "
$ spørsmålet
"; ekko $ this-> sanitized_html ($ html);
Nå kan vi åpne admin.css og gjøre noen små endringer for å oppdatere utseendet på meta-boksen i Legg til nytt innlegg skjerm. La oss legge til følgende CSS:
# tutsplus-forfatter-prompt font-style: kursiv; tekst-align: center; farge: # 333;  
Og nå må meta-boksen nå se slik ut som:
Som nevnt i begynnelsen er det ikke noe stort, men det er noe som forsterker utseendet på spørsmålet bare litt.
Hva blir det neste?
På dette tidspunktet har vi introdusert en rekke forskjellige klasser, grensesnitt og andre objektorienterte funksjoner. Vi har et plugin som bruker data fra en tekstfil, som kommuniserer med WordPress API, og som sanitiserer informasjon før den gjøres til hjemmesiden.
Vi har et godt grunnlag for å begynne å snakke om navneområder. Så i neste opplæring, skal vi gjøre akkurat det. Hvis du ennå ikke har lyst på resten av serien, anbefaler jeg det som vi bare skal fortsette å bygge videre på det vi har lært.
Hvis du i mellomtiden leter etter annet WordPress-relatert materiale, kan du finne alle mine tidligere opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min eller på Twitter.
Inntil da, ikke glem å laste ned arbeidsversjonen av pluginet (versjon 0.2.0) som er vedlagt dette innlegget. Koblingen er tilgjengelig i sidefeltet under en knapp med tittelen Last ned vedlegg. Og, som vanlig, ikke nøl med å stille spørsmål i kommentarene!
ressurser
 
grensesnitt
 
 get_current_screen ()
 
wp_enqueue_style
 
admin_enqueue_scripts
 
wp_kses
 



		
			
	   
	




Kode