Share
Når det gjelder å skrive WordPress-plugins, er det generelt to måter å gjøre om dette: Objektorientert programmering og funksjonell programmering (med widgets som unntaket - vi vil dekke det senere i artikkelen).
Selv om du generelt har folk som godtar for en form for programmering over hverandre, presenterer hver sitt eget sett med fordeler og ulemper.
I denne todelte serien kommer Stephen Harris og jeg til å bryte ned de to måtene du kan skrive om å skrive WordPress-plugins. Spesielt skal jeg snakke om objektorientert programmering, og han vil dekke funksjonell programmering.
Fordi erfaringsnivået til leserne varierer, skal vi snakke om programmering på høyt nivå, så hvis du er nybegynner, bør du ikke ha noe problem å følge med. Hvis du imidlertid er en mer erfaren utvikler, kan du finne mer nyttig informasjon senere i artikkelen.
Med det sagt, la oss begynne å se på en objektorientert tilnærming til å utvikle WordPress-plugins.
Som nevnt i innledningen, kan plugins utvikles for WordPress på to måter:
Den andre artikkelen i serien vil dekke funksjonell programmering, men la oss gi en arbeidsdefinisjon av objektorientert programmering slik at vi alle er på samme nivå gjennom denne artikkelen.
Wikipedia sier:
Objektorientert programmering (OOP) er et programmeringsparadigme som bruker "objekter" - vanligvis forekomster av en klasse - bestående av datafelt og metoder sammen med deres interaksjoner - for å designe applikasjoner og dataprogrammer.
De som er mer erfarne med dataprogrammering, spesielt de som bruker objektorientert programmeringsteknikker, vil sannsynligvis like den definisjonen.
Men la oss forklare det med hensyn til denne artikkelen:
Objektorientert programmering er en programmeringsteknikk som bruker en samling av relaterte metoder for å definere et dataprogram eller en del av et dataprogram.
Enkelt nok, ikke sant? I vårt tilfelle er våre plugins definitivt del av et dataprogram siden de kobler seg til WordPress.
Selv om vi ser på koden gjennom resten av denne artikkelen, merk at objektorienterte programmer identifiseres ved gruppering av deres relaterte metoder og at er gjort i sammenheng med det som kalles en klasse - som vi dekker kort tid.
Selv om det er sant at WordPress-plugins kan utvikles ved hjelp av OOP eller funksjonell programmering, er det et unntak når det gjelder å utvikle Widgets.
I henhold til Codex-artikkelen om å utvikle widgets, skal følgende struktur brukes til å skrive en widget:
klassen My_Widget utvider WP_Widget offentlig funksjon __construct () // widget aktuelle prosesser offentlig funksjon skjema ($ instance) // utløser opsjonsskjemaet på admin offentlig funksjon oppdatering ($ new_instance, $ old_instance) // prosesser widget alternativer å bli lagret offentlig funksjon widget ($ args, $ forekomst) // output innholdet i widgeten
Dette betyr at alle Widgets skal skrives ved hjelp av OOP. Hvis du ikke har sett kode som ovenfor, vil vi dekke det i neste avsnitt, og det skal gi alt du trenger å vite for å forstå hva som skjer.
Før vi begynner å se på å bygge OOP-baserte plugins for WordPress, la oss se nærmere på det grunnleggende om OOP for å sikre at vi er klare på terminologi, og hvordan paradigmet virker.
Som vi definerte tidligere bruker OOP "en samling av relaterte metoder." Men vi kan ikke stoppe der. Tross alt fungerer funksjonell programmering det samme.
I OOP er disse "relaterte metodene" alle relatert i sammenheng med det som kalles a klasse. I eksempelet Widget ovenfor ser du klasse søkeord som det aller første ordet i koden.
Den begynner på en linje som slutter med en åpningsbrakett (i likhet med funksjoner), og det innkapsler - eller bryter - alle dens relaterte funksjoner før avslutning med sluttbraketten (for nå, ignorere strekker søkeord i Widget-eksempelet - vi berører det om et øyeblikk).
Hvis du bare begynner med skriveklasser og du lurer på om en funksjon tilhører en bestemt klasse, spør deg selv om funksjonen høres ut som noe som en bestemt klasse ville gjøre.
For eksempel, i Widget eksempelet ovenfor, er Oppdater Metode er åpenbart noe som en widget ville gjøre. Men la oss si at du skriver en klasse som skal være ansvarlig for å lese et blogginnlegg til WordPress-databasen. Det ville være fornuftig for den aktuelle klassen å få en funksjon som heter lese eller read_by_id, men skal det ha en funksjon som heter skrive? Hva med slette?
Avhengig av hvordan du har designet klassen din, muligens. Men hvis såle Formålet med klassen er å lese data, så sannsynligvis ikke.
Og det er OOP: Det er logisk å gruppere dine funksjoner sammen i en klasse, men den logiske grupperingen avhenger av ansvaret for at du gir klassen din.
OOP er et kraftig paradigme som er ansatt i hele WordPress-applikasjonen. OOP gir mulighet for avanserte operasjoner som arv (som er representert av strekker søkeord i Widget-klassen), designmønstre som egentlig er eksisterende løsninger på vanlige problemer.
Denne artikkelen forsøker ikke å være et dypt dykk i objektorientert programmering. Det er rett og slett å forsøke å gi et grunnlag som vi kan utforske de to måtene å skrive WordPress-plugins på, men jeg nevner dem her, bør du være interessert i dykking videre i objektorientert programmering.
Nå som vi har definert objektorientert programmering og utforsket akkurat nok til å legge grunnlag, er det på tide å faktisk begynne å snakke om komponentene i OOP-basert utvikling i sammenheng med WordPress-plugins.
Gjennom resten av denne artikkelen skal vi dekke grunnleggende om hva som kreves for å skrive OOP-baserte plugins, og fordelene det bringer.
Før du gjør det hva som helst I objektorientert utvikling må du definere klassen din. Forutsatt at du allerede har en ide om hva klassen din skal gjøre, er dette generelt et spørsmål om å komme opp med det du vil nevne klassen din.
For det meste tror jeg at visningskodekoden alltid er fordelaktig når det faktisk er undervisningskode, så vi tar en titt på WordPress Plugin Boilerplate.
Legg merke til at Plugin Boilerplate er et prosjekt som jeg opprinnelig opprettet for å hjelpe jumpstart OOP-baserte plugins. Det har siden blitt bidratt til av en rekke forskjellige personer. Jeg bruker den i denne artikkelen fordi den demonstrerer emnet for hånden.
Når det er sagt, legg merke til at klassen definisjonen for Plugin Boilerplate ser slik ut:
klasse PluginName // Mer å komme ...
Fordi Plugin Boilerplate er et utgangspunkt for utvikling, ville vi åpenbart omdøpe klassen. For denne artikkelen, la oss kalle det DemoPlugin.
klasse DemoPlugin // Mer å komme ...
På dette tidspunktet er vi klare til å begynne å definere funksjoner som lever i klassen.
I OOP er den første funksjonen du sannsynligvis vil se i en klasse en funksjon kalt "konstruktøren" og PHP er ikke annerledes.
En enkel, fungerende definisjon av konstruktøren er dette:
Konstruktøren er hvor du initialiserer data som skal brukes i hele klassen.
Slik fungerer dette, varierer fra prosjekt til prosjekt, men det er to primære ting vi kan gjøre i sammenheng med et WordPress-plugin:
I vår DemoPlugin, Vi skal bare gjøre det. Vi setter inn et tekstdomenen til demo-plugin og vi registrerer handlinger for registrering og enqueueing et eksempel stilark og et eksempel JavaScript-fil.
For å være komplett i vårt eksempel, registrerer vi også en krok for å legge til litt tekst til slutten av innholdet som vises i et innlegg.
La oss først definere konstruktøren:
klassen DemoPlugin offentlig funksjon __construct ()
Merk at i PHP er en konstruktør definert av en offentlig funksjon som heter konstruere som foregår av to understreker.
La oss da definere tekstdomenet vårt:
Accentsconagua
klassen DemoPlugin offentlig funksjon __construct () load_plugin_textdomain ('demo-plugin', falsk, dirname (plugin_basename (__FILE__)). '/ lang'); Vær oppmerksom på at vi har definert nøkkelen for at tekstdomenet skal være i linjen ovenfor demo-plugin og linjen forventer å finne lokaliseringsfilene i en underkatalog som heter lang i plugin-katalogen.
Fordi lokalisering er ute av bruk for denne artikkelen, vil jeg ikke dykke lenger, men du kan se kildekoden for Plugin Boilerplate for å se hvordan dette er satt opp.
La oss da definere handlingene for å registrere stilarkene våre og JavaScript, samt filteret som vil legge til litt tekst til slutten av innholdet vårt:
klassen DemoPlugin offentlig funksjon __construct () load_plugin_textdomain ('demo-plugin', falsk, dirname (plugin_basename (__FILE__)). '/ lang'); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); add_action ('wp_enqueue_scripts', array ($ dette, 'register_plugin_scripts')); add_filter ('the_content', array ($ this, 'append_post_notification')); Hvis du ikke er kjent med handlinger og filtre, må du lese en av mine nyere artikler her på Wptuts + som det forklarer forskjellen.
Nå, hvis du er kjent med WordPress-temautvikling eller funksjonell programmering, så er du sannsynligvis vant til å se noe som følgende:
add_action ('wp_enqueue_scripts', 'register_plugin_styles'); Heller enn:
add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); Legg merke til at forskjellen i de to samtalene ovenfor er i den andre parameteren. Spesielt, i vår plugin vi passerer en matrise mens den første linjen med kode bare passerer en streng.
Fordi vi utvikler dette pluginet ved hjelp av OOP, må WordPress vite hvor du skal ringe register_plugin_styles metode. Siden det lever i vår klasse, må vi fortelle WordPress å ringe metoden på en forekomst av vår klasse.
Gir mening?
I hovedsak forteller vi WordPress: Jeg har denne metoden kalt register_plugin_styles, men du må ringe det på en forekomst av denne klassen (dermed dette søkeord).
Hvis du er ny til WordPress, men kommer fra en programmeringsbakgrunn, kan du tenke deg at du forteller WordPress å gjøre dette:
$ demo = ny DemoPlugin (); $ Demo-> register_plugin_styles ();
Uansett, bunnlinjen er at hvis du utvikler pluginene dine ved hjelp av OOP, da må registrer krokene dine ved hjelp av en matrise med to indekser: det første vesen $ dette og den andre er navnet på funksjonen.
Avanserte utviklere vil være kjent med PHPs evne til å passere for referanse og pass-by-verdi. I WordPress Development er det ikke så uvanlig å se følgende:
add_action ('wp_enqueue_scripts', array (& $ dette, 'register_plugin_styles')); Hvor dette er sendt ved referanse; Men fra PHP 5.4 har evnen til å passere variabler ved referanse på samtale tid blitt fjernet. Det er derfor denne opplæringen velger å passere etter verdi.
I programmeringen er funksjonene kodenheter som i hovedsak er ansvarlige for å "gjøre noe". I objektorientert programmering er det nyttig å tenke på dem litt annerledes.
I OOP er klasser vanligvis representert av substantiver. I vårt tilfelle har vi en DemoPlugin. Tilsvarende er funksjoner ofte verker. Det vil si at de er handlinger som vårt substantiv kan ta. På dette tidspunktet har vi allerede valgt å definere følgende funksjoner:
register_plugin_stylesregister_plugin_scriptsappend_post_notificationLegg merke til hvordan hvert funksjonsnavn representerer en handling som kan tas. Dette er en god tommelfingerregel å ansette når du skriver funksjoner.
I funksjonell programmering er det egentlig bare bare ideen om funksjoner; I OOP finnes det imidlertid flere forskjellige typer funksjoner, hvorav to er "offentlige" funksjoner og "private" funksjoner.
Offentlige funksjoner er funksjoner som er tilgjengelige utenfor klassen. Dette betyr at du kan ringe disse metodene når du har ordnet kurset.
Dette er akkurat det vi gjorde tidligere i følgende kode:
$ demo = ny DemoPlugin (); $ Demo-> register_plugin_styles ();
I utgangspunktet er disse funksjonene tilgjengelige for offentligheten (hvor offentligheten kan være en programmerer eller et annet objekt).
Funksjonene som vi skriver for å registrere stilarkene våre, JavaScript, og at vi skriver for å legge til tekst i et innlegg ha å bli merket som offentlig fordi det vil Vær en tredjepart som ringer på dem - WordPress.
La oss definere de to funksjonene for wp_enqueue_scripts handling:
offentlig funksjon register_plugin_styles () wp_register_style ('demo-plugin', plugins_url ('demo-plugin / css / plugin')); wp_enqueue_style ('demo-plugin'); offentlig funksjon register_plugin_scripts () wp_register_script ('demo-plugin', plugins_url ('demo-plugin / js / display.js')); wp_enqueue_script ('demo-plugin'); Igjen, merk at disse to funksjonene forventer at stilarkene og JavaScript ligger i css og js underkataloger, henholdsvis. For å se dette i aksjon, husk å sjekke ut Plugin Boilerplate.
Til slutt, la oss definere funksjonen for innholdet filter:
offentlig funksjon append_post_notification ($ content) $ notification = __ ('Denne meldingen ble vedlagt en Demo Plugin.', 'Demo-plugin-Locale'); returner $ innhold. $ Varsling; Vær oppmerksom på at vi bruker funksjonen __ for å sikre at vårt skript er lokalisert med TEXTDOMAIN som vi definerte i konstruktøren.
Hvis offentlige metoder er tilgjengelige for alle, vil det innebære at private funksjoner er tilgjengelige for ingen, ikke sant? For det meste er det riktig: Den eneste personen - eller ting - som kan ringe private metoder er klassen de er definert i.
Det betyr at WordPress, tredjepartsobjekter, eller programmører kan programmere ringe private funksjoner. Private funksjoner kan bare hentes fra den klassen de benyttes.
Generelt er private funksjoner svært nyttige når du skriver hjelpemetoder - det vil si, de er nyttige for å manipulere data internt for å hjelpe en annen funksjon å utføre jobben sin.
For å gi et fungerende eksempel, la oss definere en privat funksjon som returnerer en lokalisert streng som vår append_post_notification funksjonen kan bruke:
privat funksjon get_localized_notification () return __ ('Denne meldingen ble vedlagt en Demo Plugin.', 'demo plugin-locale'); Neste, la oss reflektere append_post_notification funksjon for å ringe denne nye hjelperen:
offentlig funksjon append_post_notification ($ content) return $ content. $ Dette-> get_localized_notification ();
Legg merke til at vi har forenklet den første funksjonen ved å legge til en annen funksjon. Du kan også hevde at vi har økt lesbarheten til den opprinnelige funksjonen ved å legge til et anrop til en funksjon med et navn som bidrar til å avklare hva som skjer.
Kanskje det viktigste å merke seg er at for å ringe til private funksjoner må du prefikse funksjonssamtalen med $ dette søkeord og ->. Dette forteller PHP: "Ring til get_localized_notification funksjon som lever i dette klasse."
I hvert fall har vi gitt hver metode et enkelt ansvar - en annen god praksis i objektorientert programmering - og vi har vist bruken av både offentlige og private funksjoner.
I objektorientert programmering er det også andre typer funksjoner som ikke er omfattet av denne artikkelen.
For å være komplett ønsket jeg å oppsummere dem her:
DemoPlugin :: use_this_static_method (). På dette punktet har vi slått alle de høye notatene for objektorientert WordPress-utvikling. For å oppsummere fordelene:
Når du bruker objektorientert programmering, trenger du ikke å prefikse en funksjon med navnet på temaet eller navnet på pluginet du jobber med, og du må heller ikke bekymre deg for å navngi en funksjon noe som kan forstyrre en WordPress-funksjon, et annet tema, eller en annen plugin-funksjon.
I stedet lever alle funksjoner i sammenheng med en annen klasse. Det eneste du må forsikre deg om er at klassen din ikke heter noe som interfererer med en annen eksisterende klasse.
Ved å bruke objektorientert programmering, kan du programmatisk ringe på pluginet ditt utenom standard WordPress API.
La oss si at du utvikler et tema, og du vil ha noe å gjengi på sidelinjen som plugin gir deg. I sidebaremalen kan du faktisk instantiere pluginet ditt og deretter ringe metoder på det for å få det til å skrive informasjon ut i sidebjellet.
Dette er spesielt nyttig når du arbeider med en mal og vil gi noen standarddata hvis brukeren ikke skriver inn noe manuelt.
Som vi sa i begynnelsen av artikkelen: Dette er bare en måte at du kan utvikle WordPress-pluginene dine. Stephens artikkel vil dekke hvordan man gjør det ved hjelp av funksjonell programmering.
Etter å ha lest denne artikkelen, bør du ha en bedre forståelse av objektorientert programmering, dets fordeler, og du bør kunne følge med kode som er dokumentert i Widget API, i min relaterte Widget Boilerplate, og til og med overalt i WordPress-kodebase.
