Share
Nøkkelen til WordPress 'fleksible fundament er i bruk av kroker. Det er i temaer, plugins eller kjernen, kroker gir uovertruffen vekst, samtidig som du sikrer kompatibilitet med fremtidige versjoner av WordPress. Som et resultat bør forståelse av dem utvilsomt være en del av en utvikleres repertoar. Bli med som vi avdekker intricacies av dette enkle, men sofistikerte systemet fra innsiden ut.
Som en veikart for denne artikkelen vil vi gå over konseptet bak kroker, deres gjennomføring, og selvfølgelig eksempler.
"Enkelt sagt, en krok er en plassholder for en handling."
Bak noen velskrevet programvare er et solid konsept som svarer på spørsmålene til hva og hvorfor. Kroker er ikke noe unntak. Enkelt sagt, en krok er en plassholder for en handling. Når en signifikant hendelse oppstår, for eksempel publisering av et innlegg, aktiveres en krok, slik at relevante reaksjoner kan finne sted. I utviklingsvilkår kan man tenke på kroker som implementering av et hendelsesdrevet system.
Mer enn bare en definisjon, krever et konsept resonnement som belyser hvorfor det er nyttig. Kroker spiller en viktig rolle i WordPress på grunn av prosjektets evolusjonerende natur. Med hundrevis av utviklere som kontinuerlig oppdaterer systemet, er det ikke mulig å redigere kjernefilene for hvert plugin, tema eller spesiell tilpasning, da disse ofte endres. I stedet er det et rammeverk som er nødvendig for å utvide systemet - slik at ekstern funksjonalitet har like stor effekt som interne manipulasjoner. Kroker er nøkkelen til dette rammeverket.
Som utvikler blir en rolle utvidet til ikke bare å forstå hva noe gjør eller hvorfor det er gjort, men også å innse hvordan det er opprettet. Med andre ord, for å kunne forstå systemet med kroker, må man forstå hvordan de implementeres.
På samme måte som i en multiple choice-test, er det ikke nødvendigvis den beste ideen å se direkte på svarene først. Som mange teststrategier vil foreslå, er det ofte bedre å lese spørsmålet, formulere egne tanker om svaret, og velg deretter det valget som nærmest ligner på tankene dine. En lignende metode kan tas i bruk når man forstår implementering av programvareutvikling; i stedet for å se på andres kode for å forstå hvordan en funksjon blir realisert, er det ofte enda mer nyttig å først implementere det selv og deretter gå tilbake for å undersøke hvordan det faktisk gjøres. Dette er akkurat det vi skal gjøre.
I stedet for å se på andres kode for å forstå hvordan en funksjon er realisert, er det ofte enda mer nyttig å først implementere det selv og deretter gå tilbake for å undersøke hvordan det faktisk gjøres.
For å få innblikk i hvordan et system implementeres, er dokumentasjon ofte en nyttig start. La oss undersøke oppsummeringene av de to kjerne WordPress-krokfunksjonene i henhold til Codex:
Accentsconagua
add_action ($ hook, $ function [, $ priority [, $ numArgs]]) - Angir en funksjonshåndterer, $ funksjon, å bli kalt en gang en bestemt krok, $ krok, er aktivert på grunn av hendelsen. $ prioritet bestemmer om denne funksjonshåndteringen blir kalt før eller etter andre funksjonshåndterere og som standard til 10. Lavere prioriteter fører til at en funksjon blir kalt tidligere og omvendt. $ numArgs er antall argumenter som funksjonshåndtereren vil ta og som standard 1.do_action ($ hook [, $ arg1 [, $ arg2 [, $ arg3 [,?]]]]) - Aktiverer en bestemt krok, $ krok, ved å ringe alle håndteringsfunksjoner med valgfrie argumenter $ arg1, $ arg2, $ arg3, etc.Med dokumentasjonen i hånden er det på tide å gjøre noen anledninger om disse to funksjonene. ADD_ACTION bare trenger å knytte en funksjon, prioritet og antall argumenter med en streng. Dette virker som den perfekte jobben for et PHP-array, som dually fungerer som et hashkart som lagrer nøkkelverdier. do_action er enda mer trivial, som krever en enkel titt opp i samme matrise for å finne de tilsvarende funksjonshåndteringene og deretter ringe dem. Med vår innsikt i tankene er det på tide å gå videre til implementeringen.
Fordi vi gjør dette for å få innblikk i WordPress-kroksystemet, er det ikke nødvendig å implementere disse to funksjonene ordentlig fra dokumentasjonen. I stedet la oss fokusere på deres implementeringer uten valgfrie argumenter for å spare tid og fremdeles få kjennetegnet av det.
Før vi begynner, la oss legge ut en oversikt:
ADD_ACTION vil lagre det oppgitte kroknavnet og et sett med tilsvarende funksjonshåndtere som et nøkkelverdi-par i matrisen.do_action vil hente de tilsvarende funksjonshåndterne for et gitt kroknavn og ringe hver enkelt.Dette gir følgende kode:
$ actions = array (); funksjon add_action ($ hook, $ function) global $ actions; // lage en rekke funksjonshåndterere hvis den ikke allerede eksisterer hvis (! isset ($ actions [$ hook])) $ actions [$ hook] = array (); // legge til gjeldende funksjon i listen over funksjonshåndterere $ actions [$ hook] [] = $ function; funksjon do_action ($ hook) global $ actions; hvis (isset ($ actions [$ hook])) // ring hver funksjonshåndterer tilknyttet denne kroken foreach ($ actions [$ hook] som $ funksjon) call_user_func ($ function);
Det er ikke dårlig; Vi implementerte et allsidig kroksystem i rundt 20 linjer med kode. Nå som vi har fått en ide om hvordan kroker fungerer, la oss dykke inn i WordPress-koden for å bekrefte vår hypotese.
Et verktøy for å raskt navigere gjennom denne koden er Yoasts PHP kryssreferanse av WordPress Source. Leter etter ADD_ACTION gir følgende kode:
funksjon add_action ($ tag, $ function_to_add, $ priority = 10, $ accepted_args = 1) return add_filter ($ tag, $ function_to_add, $ priority, $ accepted_args); funksjon add_filter ($ tag, $ function_to_add, $ priority = 10, $ accepted_args = 1) global $ wp_filter, $ merged_filters; $ idx = _wp_filter_build_unique_id ($ tag, $ function_to_add, $ prioritet); $ wp_filter [$ tag] [$ prioritet] [$ idx] = array ('function' => $ function_to_add, 'accepted_args' => $ accepted_args); unset ($ merged_filters [$ tag]); returnere sant; ADD_ACTION samtaler add_filter som, overraskende, legger til den oppgitte funksjonen til en matrise tastet av kroknavnet, $ tag. Selv om det er litt mer involvert på grunn av $ prioritet og $ accepted_args parametere, er denne funksjonen i hovedsak enig med vår egen, og bekrefter våre mistanke. do_action, om enn lengre og litt mer komplekst, koker ned til følgende kode:
funksjon do_action ($ tag, $ arg = ") [Utelatt kode som registrerer statistikk, behandler argumenter og behandler filtre] gjør foreach ((array) current ($ wp_filter [$ tag]) som $ the_) if is_null ($ _ _''funksjonen '])) call_user_func_array ($ _ _'en, array_slice ($ args, 0, (int) $ the _ [' accepted_args ']); mens (neste ($ wp_filter [$ tag])! == false); [Utelatt kode som rydder opp]
Looping gjennom de tilknyttede funksjonene og ringer hver og en er ikke rart for oss alle på; Faktisk er det akkurat det vi antydet i implementeringen vår. Derfor, ved å begynne med egne tanker om koden, hjalp vi oss ikke bare bedre å forstå det, men også kreves kritisk tenkning og problemløsning som er viktig for programvareutvikling.
Med vår forståelse av hva, hvorfor og hvor godt det er, er det på tide å gå videre til to eksempler. Den første er et spill på RSS; i stedet for å gi varsler via syndikering, hvorfor ikke bruk e-post i stedet?
For å implementere vårt system, må vi se etter når et innlegg publiseres. Men hvilken krok skal vi bruke? API-handlingsreferansen gir en liste over kroker sammen med beskrivelser av de tilknyttede hendelsene som kan hjelpe oss med å identifisere nøyaktig dette. Faktisk, publish_post krokens beskrivelse samsvarer med det vi trenger, så la oss legge til en funksjonshåndterer til det:
add_action ('publish_post', 'notify_via_email'); Alt som er igjen er å sende en e-postvarsling til noen i notify_via_email funksjonshåndterer. Legg merke til at API-handlingsreferansen angir at publish_post krok passerer post-ID som et argument for vår håndteringsfunksjon. Dette vil tillate oss å få informasjon om innlegget via get_post fungere som:
funksjon notify_via_email ($ post_id) $ post = get_post ($ post_id); $ til = '[email protected]'; $ subject = 'Post publisert på'. get_bloginfo ('navn'); $ message = $ post-> post_title. 'ble publisert på'. get_bloginfo ('navn'). 'som av'. $ post-> post_date. '. Du kan se det på '. get_permalink ($ post_id). ''; wp_mail ($ til, $ emne, $ melding);
Etter å ha hentet innlegget, bruker vi tittel, dato og permalink i vår e-postmelding. Det sendes deretter via wp_mail funksjon, som krever mottaker, emne og melding som parametere. Dermed er vårt enkle e-postvarslingssystem fullført. Legg merke til at det ikke anbefales å ringe wp_mail flere ganger på en gang, da det er bundet til å presentere en betydelig forsinkelse i sidetidspunktet når publiseringspostknappen trykkes.
I begynnelsen kan det virke som et tema er et mer egnet medium for en slik kode. Tvert imot, gjennom, som et nettsteds tema er mottakelig for revisjon og endring. Som et resultat kan analysekoden lett gå seg vill i en overgang fra ett tema til et annet.
Selv om det var litt opptatt, var vår første søknad en rask introduksjon til bruk av kroker. Dette andre eksempelet vil imidlertid låne seg mye mer til bruk i sanntid. Vi lager et enkelt Google Analytics-plugin som automatisk legger inn sporingskoden i siden av en side.
I begynnelsen kan det virke som et tema er et mer egnet medium for en slik kode. Tvert imot, gjennom, som et nettsteds tema er mottakelig for revisjon og endring. Som et resultat kan analysekoden lett gå seg vill i en overgang fra ett tema til et annet. Å lage en plugin omgår denne ulempen; fordi den vil forbli aktiv uansett hvilket tema som er ansatt, vil analysekoden fortsatt være til stede og fjerne behovet for temavedlikehold.
Men hvordan plugger vi koden inn i bunnen av et nettsted? Dette gjøres også via kroker. Hvis du har jobbet med WordPress-temaer før, har du sannsynligvis kalt wp_head og wp_footer Fungerer i hodet og bunnen av nettstedet ditt, henholdsvis. Begge disse funksjonene er tilstede for å bare aktivere kroker, slik at plugins enkelt kan sette inn kode i disse vitale områdene på siden. Følgelig vil vi ganske enkelt legge til en handling for wp_footer krok:
add_action ('wp_footer', 'add_google_analytics_code'); Våre add_google_analytics_code funksjon, som navnet antyder, skriver ut Google Analytics-koden:
Husk å endre UA-XXXXX-X til din nettstedsspesifikke ID, og du er helt klar! Bare legg til denne koden til en fil og last den opp til din WordPress plugins katalog. Pass på å sette inn en plugin header, slik som:
Ikke glem å endre forfatternavnet, forfatterens URI, og, selvfølgelig, aktiver pluginet!
Ved å dele kroker inn i et konsept, en implementering og eksempler, har vi effektivt undersøkt dem fra innsiden av WordPress-kjernen til utsiden i en real-world-applikasjon. I stedet for å bare se på WordPress-koden, implementerte vi vår egen versjon av kroker ved hjelp av inference, slik at vi kunne få en dypere, utviklerliknende forståelse av dette kraftige systemet. Endelig oppnådde vi foreløpig innblikk i hvordan nyttige kroker virkelig kan være, med en virkelig Google Analytics Plugin-applikasjon. Sørg for å bli med oss neste gang, og vær så snill å dele dine egne, innovative bruk av kroker i kommentarene nedenfor!
