Begynnerhåndboken til WordPress-handlinger og -filtre

Når det gjelder profesjonell WordPress-utvikling, er det viktig at utviklere forstår både handlinger og filtre - det er viktig å forstå WordPress-kroker.

Enkelt sagt, kroker er det som gir oss muligheten til å tilpasse, utvide og forbedre WordPress gjennom en API i våre temaer, plugins og andre tilpassede utviklingsarbeid.

Problemet er at disse to funksjonene i WordPress - uten tvil de viktigste aspektene ved å utvikle seg for plattformen - enten er mye misforstått eller helt ignorert.

I dette innlegget skal vi se på livssyklusen på WordPress, forstå hvordan kroker fungerer, og se forskjellene i handlinger og filtre, slik at vi ikke bare blir bedre tema- og / eller plugin-utviklere, men har også en dypere forståelse av hvordan WordPress fungerer.

Merk: Denne artikkelen er spesielt beregnet for nybegynnere, så hvis du er en erfaren utvikler, kan dette være litt av en oppdatering; men hvis du er en nybegynner, vær så snill å legge igjen spørsmål i kommentarområdet på slutten av innlegget.


The WordPress Page Lifecycle

Før vi faktisk begynner å snakke om WordPress-krokene, er det viktig å forstå hvordan WordPress-sidens livssyklus fungerer.

En sides livssyklus er ikke noe mer enn en kombinasjon av hendelsene som finner sted fra når en nettleser ber om en side til når serveren returnerer siden til nettleseren.

La oss for eksempel si at du laster opp en enkelt side. Da, på et høyt nivå, vil WordPress gjøre noe som følger:

  • Se på den forespurte siden ID
  • Spør databasen til siden med sin ID
  • Spør databasen for eventuelle tilknyttede data (for eksempel kategorier, koder, bilder osv.)
  • Spør databasen for kommentarene som er knyttet til den
  • Komme tilbake alle av dataene til nettleseren

Mallfilene og samtalene til API-funksjonene er da ansvarlige for gjengivelse, styling og posisjonering av dataene på skjermen.

Det høres enkelt, men hvis du tenker på noen av de mest komplekse bloggene du leser, eller hvis du tenker selv om noe av det arbeidet du har gjort, kan du begynne å forstå hvor intensiv denne prosessen kan være.

Selvfølgelig er dette på det mest forenklede nivået også. Dette inkluderer ikke noen caching-mekanismer eller noen av de avanserte emnene som andre ofte diskuterer når man bygger WordPress-baserte prosjekter.

En populær WordPress-utvikler Rarst - fyren bak queryposts.com - har satt sammen en relativt detaljert grafikk som viser WordPress-kjernebelastningen:

Gjøre ikke være motløs hvis du ikke kan følge diagrammet ovenfor. Jeg har plassert det her bare som en referanse. Det endelige målet med denne sesjonen er at alle utviklere på slutten er i stand til å forstå det.

Med det sagt, her er nøkkelen til å forstå om kroker under WordPress-siden last livssyklus:

Mens WordPress kjører sin serie spørringer og forbereder seg på å gjengi data tilbake til nettleseren, ser det på alle tilpassede kroker - det vil si handlingene og filtre - som er skrevet og passerer data gjennom disse filtrene før de returnerer data til nettleseren.

På dette punktet er det viktig å definere kroker og se på forskjellene mellom handlinger og filtre og hvordan de spiller inn i hele livssyklusen.


Alt om kroker

WordPress kroker refererer til to ting - handlinger og filtre. Hvis du skulle se på Codex-artiklene på kroker, ser du bare en kort side som lenker til referansene for både handlinger og filtre. Det er akkurat slik det burde være, for det er hvilke kroker er.

Så her er hvordan du tenker på dette:

Kroker gjør det mulig for oss å bokstavelig talt koble til deler av WordPress-livssyklusen for å hente, sette inn eller endre data, eller de tillater oss å ta visse handlinger bak kulissene.

Ganske kul, ikke sant?

Men det er to ting å forstå om dette:

  1. Handlinger er forskjellige enn filtre.
  2. Du kan ikke bare kaste en krok til et vilkårlig utførelsessted. Det er tider hvor visse kroker brenner og optimale tider for at du kan dra nytte av det.

Når det er sagt, la oss først definere handlinger og filtre, så vurderer vi når du skal brenne hva.


Handle

Så hva er handlinger? Den enkleste definisjonen er dette: Handlinger indikerer at noe har skjedd. Det er det. Men hvor bra er den definisjonen? Og hvordan får vi ikke det forvirret med hendelser?

Slik holder jeg det rett:

Handlinger er hendelser i WordPress-sidens livssyklus når visse ting har oppstått - visse ressurser er lastet, enkelte fasiliteter er tilgjengelige, og avhengig av hvor tidlig handlingen har skjedd, har noen ting ennå ikke lastet inn.

Siden vi har diskutert WordPress-siden livscyklus, er handlinger i utgangspunktet visse poeng i livet der du kan introdusere din egen funksjonalitet.

Dette betyr at du har muligheten til å få noe til å skje mens en side lastes inn.

The Codex gir en flott ressurs på handlingene som er bygget inn i WordPress, så vel som rekkefølgen der de brenner. Bookmark, refer ofte, og lær dette.

Det er grunnleggende å lære å koble seg til WordPress på bestemte punkter i løpet av utførelsen og Doing It Right ™.

Case in point: Jeg ser ofte utviklere henger inn i i det handling altfor ofte. Jo, det er tid for å gjøre dette. Men si at du ville gjøre noe like før du fikk innleggene. Da ville det være fornuftig å bruke pre_get_posts krok heller enn i det, Ikke sant?

det er hvorfor det er viktig å forstå handlinger.


Filtrer alle ting

Filtre, derimot, er helt forskjellige fra handlinger. Som handlinger, er de lignende punkter som oppstår under WordPress-sidens livssyklus; men hva de gjøre er annerledes.

Slik definerer jeg filtre:

Filtre er funksjoner som WordPress passerer data gjennom under visse punkter i sidens livssyklus. De er primært ansvarlige for å avskjære, administrere og returnere data før de gjøres til nettleseren eller lagrer data fra nettleseren til databasen.

Anta et øyeblikk at en besøkende på nettstedet skal legge inn et innlegg. Fra det vi forstår av WordPress-sidens livssyklus, vil WordPress spørre databasen for det innlegget, og deretter returnere det til nettleseren. Før du gjør det, vil det imidlertid løpe dataene gjennom eventuelle filtre som er etablert.

På dette tidspunktet vil filtrene ta tiltak på data som sendes til dem. For eksempel, si at du ønsket å legge til en kort setning om forfatteren på slutten av innholdet. For å gjøre dette, ville du registrere en egendefinert funksjon med innholdet filtrer og legg til setningen din til innholdet.

Hvordan å gjøre dette er utenfor rammen av denne artikkelen, men vi tar sikte på å dekke dette i en fremtidig artikkel i økten.

Akkurat som med handlinger, inneholder Codex en omfattende liste over tilgjengelige filtre. Og på samme måte, Bookmark, refer ofte, og lær dette.

Når du har en solid forståelse av filtre, kan du begynne å manipulere datainnhenting og serialisere av Doing It Right ™ i stedet for å omgå WordPress API. Det gir en kraftig, veldig enkel måte å gjøre manipulere data på.

det er hvorfor det er viktig å forstå filtre.


Men når gjør jeg ... ?

På dette punktet oppstår det uunngåelige spørsmålet alltid.

Når bruker jeg hvilken krok?

Og her er det rådet jeg vanligvis gir:

  • Bruk handlinger når du vil legge til noe på den eksisterende siden, for eksempel stilark, JavaScript-avhengigheter, eller send en e-post når en hendelse har skjedd.
  • Bruk filtre når du vil manipulere data som kommer ut av databasen før du går til nettleseren, eller kommer fra nettleseren før du går inn i databasen.

Det er det! Enkelt nok håper jeg.


konklusjoner

På dette punktet anbefaler jeg på det sterkeste å vurdere følgende ressurser:

  • Plugin API som også gir noen flott informasjon som også kan brukes i Theme Development.
  • Handlingsreferansen
  • Filterreferansen

Vi planlegger å fortsette å kjøre flere innlegg i sesjonen som følger med denne artikkelen, så vel som Pippins artikkel om utvidbare plugins, så vær sikker på å holde deg oppdatert på denne økten for mer informasjon om kroker.