Objektorientert programmering i WordPress Bygg plugin I

På dette punktet i serien er vi endelig kunne begynne å bygge pluginet vårt ved hjelp av objektorienterte teknikker som vi har lært så langt i serien.

Hvis du bare nå blir med oss, anbefaler jeg på det sterkeste å ta opp serien så langt; ellers risikerer du å gå glipp av noen av de viktigste punktene som vi skal demonstrere da vi bygger ut pluginet over de neste artiklene.

1. En introduksjon
2. klasser
3. typer
4. Kontrollstrukturer: betingede uttalelser
5. Kontrollstrukturer: Looper
6. Funksjoner og attributter
7. omfang

Ok, så med det sagt, er det endelig tid å begynne å skrive kode. Før vi begynner, er det viktig å forstå at det å bygge et plugin - eller en hvilken som helst type programvare for det saks skyld - krever en rekke trinn, og selv om vi skal skrive litt kode i denne artikkelen, vil vi ikke være legger til mye funksjonalitet til vi har stillas eller grunnlaget for plugin.

For å gjøre det, må vi gjennomgå flere ting:

1. Definerer funksjonene til pluginet som vi skal skrive,
2. Del alt som vi ikke kan bygge inn i denne første versjonen,
3. Diskuter arkitekturen og filorganisasjonen for plugin.

Så la oss dekke disse punktene veldig raskt, og så kommer vi inn i detaljene i plugin.

Post Meta Viewer

I løpet av de neste par artiklene skal vi bygge et plugin som introduserer en post-meta-boks i single postredigeringsvisningen som viser alle metadataene som er knyttet til gjeldende innlegg.

1. Funksjonene

Pluggen vil være skrivebeskyttet bare fordi du bare kan utsikt metadataene som er knyttet til plugin. Vi vil ikke kunne introdusere nye metadata - i hvert fall ikke for den første versjonen.

De andre funksjonene er at den vil vise den i et rent, organisert format slik at vi enkelt kan identifisere nøkkelen og verdiene for post-ID. Vi vil også introdusere et anker som gjør det mulig for oss å kopiere en linje med kode som lar oss ringe til informasjonen i form av get_post_meta ($ post_id, $ meta_key, $ meta_value);.

2. En sterk 1.0

Før du går videre, er det mange fine funksjoner vi kunne implementere i denne plugin. 

Vi kunne introdusere muligheten til å:

• Legg til nye tilpassede post-metadata
• oppdater eksisterende eksisterende metadata
• Slett eksisterende post-metadata
• sorter kolonnene med metataster
• sorter kolonnene med meta verdier
• … og så videre

Men i tråd med filosofien om å skape en "sterk 1,0", skal vi bygge et mager, fokusert fundament som vi kan fortsette å bygge ut pluginet som vi ser etter denne serien.

Kanskje vi vil dekke noen av de ovennevnte funksjonene før slutten av serien, kanskje du vil presentere ditt eget sett med funksjoner. Uansett er det greit. Bunnlinjen er at vi skal bygge en sterk kjerne av som vi kan fortsette å iterere på for å utvide funksjonaliteten.

3. Arkitektur- og filorganisasjonen

Så med det hele sagt, la oss først snakke gjennom de høye punktene i pluginet, så tar vi en titt på hvordan vi skal organisere filene og komponentene i plugin-modulen.

• Pluggen krever en base plugin-fil som vil tjene som en slags oppstartslader (eller bootstrap-fil) for å registrere seg selv for WordPress og for å laste opp komponentene i plugin-modulen.
• Pluggen trenger en klasse som koordinerer krokene og tilbakekallingene som brukes gjennom plugin. Dette vil bidra til å avkoble funksjonalitet fra krokene og klassene som er ansvarlige for å faktisk vise arbeidet som gjør at vi kan sørge for at hver av våre klasser er spesialisert og ideelt utfører en enkelt jobb.
• Pluggen vil trenge en klasse som vil være ansvarlig for å vise informasjon i det enkle innlegget dashbordet som faktisk vil gjøre meta-boksen. 
• Vi trenger en kjerneplugineklasse som registrerer alle avhengighetene og gir informasjon om pluginversjonen, er klar over lasteren og administrasjonsfunksjonaliteten for å registrere informasjon mellom de to komponentene.
• Og til slutt trenger vi noen stilark for å sikre at informasjonen ser bra ut i dashbordet.

Lyd forvirrende? Forhåpentligvis ser det å se og se på filstrukturen og den grunnleggende prøvekoden, slik at dette fortsetter å gi mer mening.

Med det sagt, la oss ta et høyt nivå på komponentene som vil samhandle med hverandre, så tar vi en titt på hvordan filene skal organiseres. Etter det kommer vi til å stikke ut koden for pluginet som vi skal fylle ut i neste artikkel.

Plugin komponenter

Spesielt vil plugin-modulen bestå av følgende komponenter - eller filer - som vil utgjøre kilden til plugin-modulen. Etter å ha tatt en titt på filoppføringen, tar vi en titt på et diagram over hvordan alle stykkene vil samhandle.

• single-post-meta-manager.php er den primære filen som registrerer pluginet med WordPress og setter alt i gang.
• klasse-single-post-meta-leder-admin.php er filen som er ansvarlig for å registrere og enqueueing stilark samt vise brukergrensesnittelementene som vil inneholde post-metadataene.
• single-post-meta-leder-admin.css er stilarket som vil stile brukergrensesnittet.
• klasse-single-post-meta-leder-loader.php er filen som koordinerer handlinger og filtre mellom kjernepluggen og administrasjonsklassen.
• klasse-single-post-meta-manager.php er kjernepluginfilen som opprettholder pluginversjonsinformasjon, plugin-slug-informasjon, referanser til lasteren og filen der vi instruerer lasteren hvilke objekter og funksjoner som er ansvarlige for visning av det administrative brukergrensesnittet.
• README.md gir de vanlige instruksjonene for hvordan du kommer i gang med plugin.
• CHANGES.md gir en liste over endringer som skjer i hver versjon av pluginet som vi slipper ut.

Avhengig av nivået på erfaring med objektorientert programmering, kan dette eller ikke virke som mange filer for et relativt enkelt sett med funksjoner; Det er imidlertid enda mer til det: Vi kommer ikke til å slippe alle disse filene inn i roten til plugin-katalogen.

I stedet skal vi ta det et skritt videre og organisere ting i riktige kataloger også. Når vi vurderer det, tar vi en titt på organisasjonen av komponentene i form av et diagram, og vi vurderer koden som gir stillestillingen for plugin-modulen.

Fil Organisasjon

Filorganisasjonen er relativt enkel og er sannsynligvis best demonstrert ved bruk av et bilde:

For å være klar, her er nedbrytningen av det du ser på skjermbildet over:

• admin / klasse-single-post-meta-leder-admin.php
• admin / css / single-post-meta-manager.admin.css
• includes / class-single-post-meta-leder-loader.php
• omfatter / klasse-en-post-meta-manager.php
• språk /
• single-post-meta-manager.php
• CHANGES.md
• README.md
• LICENSE.txt

Dette er viktig å gjenkjenne og det er et par steder i koden der vi skal registrere avhengigheter, og det er viktig å vite hvor avhengighetene er slik at vi kan gi de riktige banene til dem.

Bygg pluggen

På dette tidspunktet er vi klare til å begynne å stikke ut klassene som vi skal bruke. Det er flere viktige ting å merke seg om koden du skal se:

• Vi kommer bare til å være stubbende ut i klassene og metodene - vi vil ikke introdusere noen reell funksjonalitet i denne artikkelen.
• Ved slutten av implementeringen, plugin bør vises i WordPress dashbordet og kan aktiveres (selv om ingenting faktisk vil skje).
• Til tross for at jeg tror at dokumentasjonen er nøkkelen til kvalitetsutvikling, vil vi ikke introdusere kommentarene i denne artikkelen fordi det er en bytte som skal gjøres: Denne artikkelen kan bli for lang med en ekstraordinær detalj, eller vi kan fortsette å ta hvert aspekt av denne serien trinnvis. Jeg velger å gjøre sistnevnte slik at vi ikke er overveldet med mengden informasjon.

Med det sagt, hvis du har spørsmål om koden, er du velkommen til å legge igjen kommentarer om dette. Imidlertid kan jeg si vente til neste artikkel for å se svaret.

Nå, videre til koden.

Kjernepluginfilen

Kjernepluginfilen er ansvarlig for å registrere pluginet med WordPress, og vil i siste instans være ansvarlig for å importere kjerneplugineklassen (som vi vurderer på litt) og faktisk sette plugin på plass.

Legg merke til at det er betinget at vi har bunnen av filen. Dette vil sørge for at pluginfilen ikke kan nås direkte i nettleseren.
Administrative filer
Alle disse filene ligger i admin katalog som nevnt ovenfor.
Den Enkle Post Meta Manager Admin Class
Denne klassen vil enqueue stilarket og gjøre meta-boksen som vil bli brukt til å vise det oppgitte innlegget meta.
versjon = $ versjon;  offentlig funksjon enqueue_styles ()  offentlig funksjon add_meta_box () 
Legg merke til at den har et enkelt beskyttet attributt for denne klassen $ versjon av plugin. Dette attributtet er oppsett i konstruktøren til klassen.
Vi ser hvordan dette passer sammen senere i koden.
Enkelt innlegg Meta Manager Stylesheet
Akkurat nå er det ingen kode som skal vises for denne filen. Men gå videre og legg den til admin / css underkatalog som det vi vil bruke til å stylere dashbordet.
inkluderer
Dette er kjernepluginfiler som er ansvarlige for å koordinere informasjon mellom de ulike krokene og det administrative området av plugin.
Enkelt innlegg Meta Manager Loader
Denne klassen vil bli brukt av den primære plugin-klassen til å koordinere alle kroker som finnes i plugin og administrativ klasse som vi definerte ovenfor.
Legg merke til at i klassen ovenfor har vi merket attributter som beskyttet. Dette er gjort slik at denne klassen har tilgang til sine attributter, men ingen andre klasser gjør det.
I tillegg har vi gått videre og gjort dette bare hvis vi underklasser denne klassen i en fremtidig iterasjon av plugin.
Enkelt innlegg Meta Manager
Endelig har vi den primære plugin-klassen som er ansvarlig for å laste avhengighetene, sette inn lokalen og koordinere kroker.
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.1.0';  privat funksjon load_dependencies ()  privat funksjon define_admin_hooks ()  offentlig funksjon run ()  offentlig funksjon get_version () return $ this-> versjon; 
Legg merke til i koden ovenfor, vi har ekstra beskyttet attributter, et par privat funksjoner og a offentlig funksjon som brukes som getter som vi skal bruke som vi fortsetter å bygge ut pluginet.
I neste artikkel vil vi tilbringe mye tid i denne klassen, da dette er inngangspunktet for hvor mye funksjonaliteten skjer.
Nestemann
Vi har dekket mye materiale i denne artikkelen, men det er åpenbart mye mer å gjøre. Bortsett fra å gi dokumentasjon for våre funksjoner, må vi faktisk implementere funksjonalitet som bringer denne stillaset til livs.
I den neste artikkelen i serien, skal vi bare gjøre det, og deretter vil vi være oppmerksom på å dokumentere koden.
Som tidligere nevnt, vær så snill å forlate noen spørsmål og / eller kommentarer om koden ovenfor. For de som er interessert, kan du alltid bla gjennom den nåværende tilstanden til prosjektet på GitHub.
Frem til neste artikkel!



		
			
	   
	




Kode