Bruke WordPress for webapplikasjonsutvikling tilgjengelige funksjoner, del 5 - henting av data

Nå vet du at formålet med denne serien er å demonstrere hvordan WordPress kan brukes som grunnlag for webapplikasjonsutvikling.

Vi startet med å se et høyt nivå på mange webapplikasjonsdesignmønstre, hvordan WordPress er forskjellig, og hvorfor WordPress bør anses å være mer av et grunnlag enn et rammeverk.

I løpet av de siste artiklene har vi tatt en titt på brukerroller, tillatelser, øktstyring, e-post og dataserialisering. Men hvis du skal lagre data i databasen, er det bare fornuftig at du skal hente den, riktig?

Heldigvis, APIene som WordPress har tilgjengelig gjør det veldig enkelt å hente informasjon fra databasen. På toppen av det, hvis du fant den siste artikkelen lett å følge, bør du ikke ha noe problem å følge sammen med denne artikkelen, da mange av prinsippene er de samme:

Vi henter informasjonen fra databasen ved hjelp av den unike IDen vi leverte ved lagring av informasjonen
Vi unnslipper dataene for å sikre at det er trygt å gjengi til nettleseren
Vi returnerer det til kallfunksjonen

Ingenting veldig komplisert, riktig?

Og det er egentlig ikke særlig fordi det handler om å utnytte de samme APIene (om enn forskjellige funksjoner) som vi brukte til å lagre informasjon til alternativtabellen og metadatabordene. I denne artikkelen skal vi fortsette vår diskusjon om hvordan du henter informasjon, samt hvordan du skal sørge for at vi skikkelig slipper informasjon for å sikre at dataene er sikre og rene for å gjengis i nettleseren.

Datainnhenting

Som jeg nevnte i tidligere artikler, er en av de primære differensierne mellom en vanlig nettside og en webapplikasjon datalagring.

Og siden WordPress bruker sin egen database til å administrere datalagring, så vel som gjør APIer tilgjengelig for oss å bruke til egne prosjekter, er det åpenbart en webapplikasjon.

Videre, bare jeg diskuterte i den siste artikkelen, er det veldig enkelt å forstå hvordan du lagrer data ved hjelp av riktige APIer, og når du har lært å bruke en, er det nesten like enkelt å bruke resten av dem. På den måten er det muligens enda enklere å lære å hente data.

Når det er sagt, er det noen få nyanser som vi må vurdere når vi går videre når vi henter data. Men først skal vi se gjennom databasen, ta en titt på hvordan du henter informasjon, og så ser vi på hvordan du skal rømme informasjonen riktig før du returnerer den til nettleseren.

Forstå databasen

I den forrige artikkelen har vi en detaljert oversikt over tabellene som du kan skrive. Du kan lese om dette mer detaljert i den første artikkelen, men her er en oppsummering av tabellene som vi diskuterte:

wp_options
wp_posts
wp_postmeta
wp_comments
wp_commentmeta

Husk at du kan se gjennom alt dette og mer på databasebeskrivelsessiden i WordPress Codex.

Lesing fra databasen

Så med det som vår oppdatering, er det på tide å faktisk se på hvordan du henter informasjon fra databasen.

Heldigvis handler det bare om å skrive informasjon til databasen. De to hovedforskjellene er:

Vi bruker litt forskjellige funksjoner.
Det er litt arbeid vi trenger å gjøre for å sikre at dataene vi viser er rent formatert for nettleseren.

Før vi ser på hvordan vi håndterer data, la oss først se på hvordan du leser alternativer fra databasen.

Alternativtabellen

Husk fra den siste artikkelen at måten vi går på å skrive data til alternativtabellen, er ved å bruke add_option eller get_option funksjoner.

Husk: Hver tar inn en unik nøkkel som brukes til å identifisere verdien i databasen, og verdien som er knyttet til den aktuelle nøkkelen. I vårt tidligere eksempel demonstrerte jeg følgende:

 $ clean_value = strip_tags (stripslashes ($ _POST ['value'])); add_option ('minverdien', $ clean_value);

Dette betyr at vi har sanitisert og lagret informasjon til databasen ved hjelp av my-verdi nøkkel.

For å hente denne informasjonen fra databasen, gjør vi følgende anrop:

 $ my_value = get_option ('min-verdi');

Det er nesten for enkelt.

Men det er en fangst til get_option funksjon: Vi kan faktisk angi en standardverdi som skal returneres hvis en ikke allerede eksisterer.

For eksempel, la oss si at vi skal slå opp en verdi for nøkkelen your-verdi, som ikke eksisterer.

 // $ your_value vil faktisk svare til FALSE $ your_value = get_option ('din-verdi');

I så fall returnerer funksjonen FALSK; Men hvis vi angir en andre parameter, kan vi returnere en standardverdi:

 // $ din_verdien vil faktisk være lik en tom streng $ your_value = get_option ('din verdi', ');

Selv fortsatt, ingenting veldig komplisert, riktig?

Hva om tema mod?

Før vi ser på hvordan vi henter informasjon fra metabordene, er det verdt å nevne at akkurat som vi angir informasjon ved hjelp av set_theme_mod, Vi kan også hente temainnstillinger ved hjelp av get_theme_mod.

Rett fra WordPress Codex:

Henter en endringsinnstilling for det aktuelle temaet. Sammen med set_theme_mod () Denne funksjonen kan noen ganger tilby temautviklere et enklere alternativ til Innstillings-API når det er behov for å håndtere grunnleggende temaspesifikke innstillinger.

Igjen er dette åpenbart ment for å arbeide med temaer; Jeg ville imidlertid nevne det her for å være ferdig, og for å avrunde diskusjonen som ble startet i forrige artikkel.

Annet enn dette, er dette bare ment å vise frem hvordan mulighetene kan lagres basert på hvordan du kan jobbe med temautvikling; Det er imidlertid virkelig utenfor rekkevidden av serien på applikasjonsutvikling.

Postmeta og Meta-tabellene for kommentar

Nå, tilbake til å snakke om databasetabellene som er mer anvendelige for applikasjonsutvikling og til og med innholdshåndtering.

I den siste artikkelen demonstrerte jeg API-funksjonene som er ansvarlige for å skrive informasjon til metatatabordene. Spesielt skisserte jeg følgende funksjoner:

add_post_meta
update_post_meta
add_comment_meta
update_comment_meta

På samme måte som resten av Options API, er det enkelt å hente informasjon fra hver av disse tabellene, bortsett fra at det kommer med en enkelt "gotcha" som standard, blir all informasjon som returneres fra disse funksjonene gjort i form av en matrise.

Dette betyr at hvis du skal ringe:

 $ my_data = get_post_meta (get_the_ID (), 'min-post-informasjon');

Da blir dataene returnert til deg i en matrise; men hvis du skal passere EKTE til funksjonen når du ringer det, vil dataene bli returnert til deg i en streng:

 $ my_data = get_post_meta (get_the_ID (), 'min-post-informasjon', SANT);

Selvfølgelig er det nei Ikke sant måte å gjøre dette på. I stedet avhenger det av informasjonen du vil returnere og / eller hvordan du vil at den returneres. Fordi det ikke er en eneste måte å gjøre dette på, må du dømme bruken din basert på søknadens implementering.

Unnslippe data

Nå, akkurat som vi trengte å sanitere informasjon før du faktisk skrev den til databasen, er det også viktig at vi helt unnslipper dataene etter å ha hentet den fra databasen, men før du gjør det til nettleseren.

Unnslippe data er prosessen som sikrer at dataene som vi skal gjengi til brukeren, er sikre. Det er i utgangspunktet sanitiseringen gjort til data; men det er gjort etter dataene er hentet fra databasen i stedet for gjort før du skriver det til databasen.

Når det gjelder å akseptere data, er det fire hovedfunksjoner som vi bør være oppmerksomme på:

esc_html brukes til å unnslippe HTML-blokker.
esc_url er når du trenger å rense nettadresser som skal skrives ut til tekstelementer, attributt noder eller andre steder i oppslaget.
esc_js brukes til å unnslippe tekststrenger som brukes til å ekko JavaScript - primært, inline JavaScript.
esc_attr koder for flere tegn som kan mangle utdata hvis det ikke håndteres riktig.

Det fulle med dette er at de vanligvis fungerer nøyaktig samme måte, og måten å bestemme hvilken du må bruke er relativt enkel:

Hvis du gjør inline JavaScript, bruk da esc_js,
Hvis du gir et attributt for et element, bruker du esc_attr.

Lett nok, rett?

Så, for eksempel, la oss si at du ønsket å unnslippe en attributt for et inputfelt som kommer fra $ _POST samling. For å gjøre dette, skriver du følgende kode:

 '; ?>

Det er små ting som dette kan gå langt for å sikre at søknaden din er robust i både dataserialisering og datainnhenting..

Og nå, på å omskrive URL

Vi har dekket mye bakken i denne serien, men det er mer å gå.

Case in point: En av de fineste funksjonene i noen av de mer populære webapplikasjonene er hvordan de håndterer nettadresser. Kort sagt gir de rene URL-ordninger som gjør det veldig enkelt å forstå de ulike handlingene som er tilgjengelige for datamodellene som brukes i hele applikasjonen.

Utenfor boksen tilbyr WordPress ikke de reneste eller klareste nettadressene; imidlertid dette kan modifiseres ved bruk av omskrivnings-API. I neste artikkel skal vi se nærmere på hvordan vi kan introdusere egendefinerte regler for rene nettadresser som ligner på noe du vil se i et webprogram snarere enn i et innholdssystem eller en blogg.

Kode