Share
I den forrige artikkelen i denne serien begynte vi endelig å forberede grunnlaget for pluginet som vi skal skrive.
Spesielt tok vi en titt på filorganisasjonen, komponentene og de faktiske detaljene av hva pluginet skal gjøre. Vi stubbed også koden som vi skal fylle ut i denne opplæringen.
I tillegg til at pluginet vårt faktisk gjør noe, skal vi snakke om en rekke forskjellige objektorienterte prinsipper, teknikker og ideer som vi jobber gjennom plugin.
Merk at i denne opplæringen skal vi gjøre svært lite dokumentasjon. Vi har dekket detaljene om dette i forrige artikkel; vi snakker imidlertid mer om det i artikkelen som følger denne.
Som med resten av artiklene i denne serien, vær så snill å ta opp alt vi har dekket så langt i serien som alt vi gjør bygger på de forrige emnene.
Til referanse har vi dekket:
Med det sagt, la oss plukke opp hvor vi sluttet.
Når det kommer til å skrive programvare - uavhengig av det paradigmet som blir brukt - er det ikke gjort på en lineær måte. Det betyr at vi ikke nødvendigvis skriver på startpunktet av programmet. Ofte - men ikke alltid - det kan være en av de sistnevnte delene som vi har rett.
Med det sagt, skal vi begynne å jobbe med hver fil som gjør plugin på en måte som gir mening når vi jobber gjennom plugin. Dermed mener jeg at når vi arbeider gjennom denne artikkelen, kan det virke som spredt i begynnelsen, men skal forhåpentligvis bli litt klarere da vi ser på hver fil.
Den første klassen som vi skal fullføre ligger i includes / class-single-post-meta-leder-loader.php. Hvis du husker fra forrige artikkel, er denne klassen ansvarlig for å koordinere handlinger og filtre mellom kjernepluggen og administrasjonsklassen.
På en måte gir den en wrapper rundt WordPress 'native hook APIs; men det tillater oss å de-parere (og dermed håndheve en adskillelse av bekymringer) våre klasser slik at hver kan spesialisere seg på en bestemt hensikt.
Først, la oss ta en titt på klassen:
Accentsconagua
handlinger = array (); $ this-> filters = array (); offentlig funksjon add_action ($ hook, $ component, $ tilbakeringing) $ this-> actions = $ this-> add ($ this-> handlinger, $ hook, $ component, $ callback); offentlig funksjon add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> legg til ($ this-> filters, $ hook, $ component, $ callback); privat funksjon legg til ($ kroker, $ krok, $ komponent, $ tilbakeringing) $ kroker [] = array ('hook' => $ krok, 'komponent' => $ komponent, 'tilbakeringing' => $ tilbakeringing); returnere $ kroker; public function run () foreach ($ this-> filtre som $ hook) add_filter ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); foreach ($ this-> handlinger som $ hook) add_action ($ hook ['hook'], array ($ hook ['komponent'], $ hook ['callback'])); På dette punktet i serien bør du legge merke til flere viktige ting om klassen basert på diskusjonene som vi har hatt hittil i serien.
beskyttet attributter som hver refererer til arrays som definert i konstruktøren. Den ene er utpekt for handlinger, den andre for filtre.offentlig funksjoner. Den ene er designet for å enkelt legge til handlinger, den andre er laget for å enkelt legge til filtre. Merk at hver aksepterer tre komponenter: kroknavnet, hovedobjektet som har funksjonen som skal ringes, og funksjonen som skal kalles under den faktiske utførelsen av kroken. For mer informasjon om handlinger og filtre, se denne referansen.privat funksjon som brukes til å forenkle de to foregående offentlig Fungerer slik at vi har et enkelt sted å legge kroken til riktig matrise.løpe funksjonen er det som pleide å koble opp alle de definerte krokene. Dette er hva som vil registrere alle våre tilpassede funksjoner med WordPress.Da vi fortsetter å bygge resten av pluginet, ser vi denne spesielle klassen i bruk.
Denne delen av plugin inneholder alle filene som er plassert i admin katalogen. Hvis du husker fra forrige artikkel, har vi en primær klasse, et stilark og en enkelt fil som brukes til å vise visningen av innholdet.
Vi ser på hver av disse filene slik at de blir brukt som start med kjerneadministratorklassen.
Dette er kjerneklassen som er ansvarlig for å registrere stilarkene, meta-boksen, og inkludert filen som vil gjøre innholdet til meta-boksen.
La oss ta en titt på hele koden, og deretter vurderer vi hva den gjør.
versjon = $ versjon; offentlig funksjon enqueue_styles () wp_enqueue_style ('single-post-meta-manager-admin', plugin_dir_url (__FILE__). 'css / single-post-meta-manager-admin.css', array (), $ this-> versjon, falsk); offentlig funksjon add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', array ($ dette, 'render_meta_box'), 'post', 'normal', 'core') ; offentlig funksjon render_meta_box () require_once plugin_dir_path (__FILE__). 'Deltonene / enkelt-post-meta-manager.php'; Dette er en relativt enkel klasse som antar at du er kjent med wp_enqueue_style og add_meta_box. Hvis ikke, vurder de koblede artiklene, og gå deretter tilbake til dette innlegget.
Neste, la oss ta en titt på hva resten av klassen gjør:
privat attributt som brukes til å spore versjonen av pluginet. Denne verdien er overført til klassens konstruktør og brukes primært for å sikre at vi inkluderer den nyeste versjonen av pluginet når du anvender stilarkene våre for å sikre at vi støter på filer som kan bufres når de kjører dette pluginet.offentlig funksjon som brukes til å registrere stilarket som er tilknyttet instrumentbrettet, og vi har en offentlig funksjon som er vant til å legge til en meta-boks til post skriv dashbordet.Selv om vi ser at alt går ut mer detaljert senere, kan du begynne å legge merke til at funksjonen som enker stilarkene, ikke er referert til noe annet sted. Det er her loader klassen vil etter hvert komme til spill.
Noen utviklere liker å skrive oppmerkningen for meta-boksvisninger i PHP og lagre dem i virkelig lange strenger.
Jeg er ikke en fan av denne tilnærmingen fordi visninger (eller deler eller maler, eller hva du vil kalle dem) og vanligvis brukes til å vise data og dermed bestå av mer markup enn noe annet. Til det formål tror jeg at de burde være deres egen fil.
I dette tilfellet ønsker vi å ha en fil som gjør alle metadataene knyttet til gjeldende innlegg i en bord element som er inneholdt i meta-boksen.
Markeringen for denne filen ser slik ut:
$ post_meta_value) ?>
Selv om markeringen og minimum PHP som er inneholdt i denne filen, bør være relativt selvforklarende, det gjør avhengig av din kunnskap om get_post_meta og get_the_ID funksjoner.
Når alle postens metadata er hentet, slår vi gjennom informasjonen (ved hjelp av en av loopkonstruksjonene som vi dekket mye tidligere) og deretter viser både metatasten og verdien.
Det siste vi må gjøre for innholdet i meta-boksen, er å gi stilene i stilarket vi har kalkulert i kjerneadministrasjonsklassen.
For å gjøre det, redigerer vi css / enkelt-post-meta-manager.css.
# single-post-meta-manager-data bredde: 100%; # single-post-meta-manager-data .key font-weight: bold;
Tydeligvis er dette veldig enkelt. Det gir ikke noe annet enn å sette bordets bredde til 100% av beholderen, og det dristes meta-nøkkelverdiene.
Men det er nok for det vi ønsker å gjøre nå.
På dette tidspunktet må vi definere kjernepluginfilen. Dette er filen som definerer plugin-versjonen, pluginets slug (som vanligvis brukes i internasjonalisering og andre funksjoner), instanserer Loader, og registrerer alle nødvendige kroker med WordPress.
La oss ta en titt på koden, og deretter vurdere den når vi har definert alt:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ Dette-> load_dependencies (); $ Dette-> define_admin_hooks (); Private funksjon load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / klasse-single-post-meta-leder-admin.php'; require_once plugin_dir_path (__FILE__). 'Class-single-post-meta-leder-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); privat funksjon define_admin_hooks () $ admin = new Single_Post_Meta_Manager_Admin ($ this-> get_version ()); $ this-> loader-> add_action ('admin_enqueue_scripts', $ admin, 'enqueue_styles'); $ this-> loader-> add_action ('add_meta_boxes', $ admin, 'add_meta_box'); offentlig funksjon løp () $ this-> loader-> run (); offentlig funksjon get_version () return $ this-> versjon; Klassen inneholder følgende attributter:
Ovennevnte attributter er satt i konstruktøren, men det er også anrop til flere andre funksjoner.
load_dependencies brukes for å importere alle filene som brukes i hele dette pluginet, for eksempel Administrasjon og Loader.define_admin_hooks er hvordan vi utnytter Loader for å koordinere funksjonene som er definert i vår Admin-klasse, som enqueue våre stiler og meta-boksen med WordPress. Slik separerer vi bekymringene til pluginet vårt og sørger for at hver klasse er et enkelt formål.løpe er funksjonen som setter alt i bevegelse, slik at alle plugins funksjonalitet kjører når de aktiveres i WordPress.Bortsett fra at vi fortsatt mangler et siste stykke: hvordan instanser vi faktisk kjerneplugineklassen og starter prosessen?
For å gjøre dette, utnytter vi en fil som ligger i roten til plugin-katalogen. Noen kaller dette en plugin bootstrap-fil, noen kaller det en oppstartslader, og noen kaller det hoved pluginfilen.
Uansett hva du velger å kalle det, er dette filen som registrerer seg med WordPress og som setter alt i bevegelse. La oss ta en titt på koden, og så vurderer vi hva den gjør etterpå:
løpe(); run_single_post_meta_manager ();
Kodkommentaren øverst i filen er ansvarlig for å fortelle WordPress at pluginet eksisterer og gir det nok informasjon om pluginet slik at det kan vise det i instrumentbrettet.
Den første betingelsen du ser, forhindrer at pluginfilen nås direkte. Dette er ikke noe mer enn et enkelt sikkerhetsmål.
Til slutt, vi ringer til require_once å inkludere kjernepluginfilen som vi så på ovenfor, og da definerer vi en funksjon og instanserer Single_Post_Meta_Manager og etter som vi kaller løpe som er hva som setter alt i gang.
Til slutt, vi ringer til funksjonen som vi definerte helt på slutten av filen. Dette starter prosessen og bringer pluggen til liv.
På dette tidspunktet har vi fullført funksjonaliteten til pluginet vårt; Vi er imidlertid fortsatt ikke ferdige. Det er fortsatt en ting vi må gjøre for å sikre at vi følger alle de beste praksiser som går inn i et plugin, og det gir dokumentasjon.
I neste innlegg tar vi en pause fra lengre skjemaer, skriver kode, vurderer WordPress-dokumentasjonsstandarder, og så dokumenterer vi pluginet slik at vi fullstendig utrunder alle funksjonene.
I mellomtiden kan du laste ned eksempelpluggen, utforske hvordan alt passer sammen, og vær sikker på å legge igjen noen kommentarer eller spørsmål du har om vårt arbeid så langt.
