I den forrige artikkelen diskuterte vi å jobbe med postmetadata i WordPress ved hjelp av de angitte APIene. Vi dekket også en rekke verktøy, sikkerhetsideer og hva som ville være nødvendig for å sette opp miljøet for å jobbe med koden som ville bli gitt gjennom hele opplæringen.
Hvis du ikke har lest denne artikkelen, anbefaler jeg at du vurderer det ikke bare fordi det dekker hvordan du arbeider med post-metadata, men også fordi det treffes på noen viktige emner som er relevante for resten av artiklene i denne serien (og det refererer til noen som kommer senere i år).
Forutsatt at du er helt opptatt og klar til å lære om en annen metadata-API, så la oss komme i gang med WordPress User Meta API.
Tilbakekall fra tidligere i denne serien, definerer WordPress metadata på følgende måte:
Metadata håndteres med nøkkel / verdi par. Nøkkelen er navnet på metadataelementet. Verdien er informasjonen som vil vises i metadata-listen på hvert enkelt innlegg som informasjonen er knyttet til.
Når vi fortsetter å jobbe med de ulike metadata-APIene, kommer du til å oppdage at denne definisjonen gjelder uansett hvilken API som undersøkes.
Det fine er at når du har fått et håndtak på å håndtere en metadata-API, har du en generell ide om hvordan hver av de tilknyttede APIene vil fungere. Jo, det kan være nyanser her og der, men den generelle funksjonaliteten vil være den samme.
Når vi så på WordPress Post Meta API, vurderte vi og brukte følgende funksjoner:
add_post_meta
update_post_meta
get_post_meta
delete_post_meta
Ja, det er idiosynkrasjoner blant dem, spesielt når det gjelder hvordan add_post_meta
og update_post_meta
arbeid og de ulike måtene get_post_meta
og delete_post_meta
arbeid, og APIene vi skal undersøke, vil fungere mye på samme måte.
For resten av denne artikkelen antar jeg at du har en lokal webserver, tilgang til en databasefront-end, en IDE, og at du er komfortabel med å jobbe med filen tutsplus-metadata.php
.
Hvis du er nysgjerrig, bruker jeg følgende sett med verktøy:
Merk at brukerens metadata blir lagret i wp_usermeta
database tabell, så vi refererer til det i noen skjermbilder av databasen. I motsetning til metadatabasen for første innlegg, er det faktisk noen data som allerede finnes i metadatabordet til brukeren.
Dette skyldes noen av dataene som er lagret på brukerprofil-skjermen:
Likevel vil API-en tillate oss å skrive vår egen informasjon til bordet. Så med alt det sagt, la oss gå videre og se på hvordan du arbeider med funksjonene som tilbys av WordPress.
Merk at gjennom alle eksemplene som er gitt, skal vi passere 1
for den første parameteren til API-funksjonene, siden den første brukeren alltid er nettstedadministratoren. Dette er vanligvis garantert å være til stede i en gitt installasjon.
Du kan finne en referanse til add_user_meta
funksjon i Codex. Definisjonen av funksjonen er omtrent så kortfattet som mulig:
Legg til metadata i en brukers rekord.
Hvor gunstig er dette? Det vil si hvis du skulle jobbe med et plugin eller et webprogram som er bygget på WordPress, og du ønsker å forlenge hva en person er i stand til å knytte til profilen sin, så er dette en måte å gjøre det på.
Det kan være noe så enkelt som å gi brukerens profil på et gitt sosialt nettverk, eller det kan være noe mer avansert hvor du kan forbinde brukeren med data i et annet bord, en rekke opplysninger eller noe annet.
Uansett, dette er hvordan du går om å gjøre det. Her er ting, men: Husk hvordan du skriver metadata for et innlegg ved hjelp av add_post_meta
funksjon resulterte i at flere rader kunne skrives med samme tast?
Det samme er mulig å bruke add_user_meta
. Imidlertid aksepterer API-funksjonen en valgfri fjerde parameter på om en verdi som er satt inn skal være unik eller ikke.
Så først, la oss ta en titt på koden for å legge til noen brukermetadata, og la oss gjøre det ved ikke å spesifisere at det skal være unikt.
Koden for å gjøre dette vil se slik ut:
Legg merke til at vi bruker den samme strategien som tidligere brukt i denne serien:
- Vi hekker inn
innholdet
.- Vi sjekker for å se om vi er på Hei Verden post.
- I så fall legger vi til metadataene til brukeren.
- Vi returnerer
$ innhold
til WordPress.Med denne koden på plass og med Hei Verden posten lastet inn i nettleseren din, oppdater siden noen ganger.
Når det er gjort, vil den resulterende databasetabellen se slik ut:
Som jeg sa, ligner det veldig på hvordan metadata-API-en utfører.
Unike verdier
Bruk databasens frontend, slett radene som ble opprettet, eller vær så snill å velge en ny nøkkel (kanskje noe som
instagram_username
). Jeg skal slette radene.For det andre skal jeg også skape en annen funksjon i stedet for å endre den over, slik at jeg kan tilby den komplette kildekoden på slutten av opplæringen, så les følgende kode tett:
Først gir du en unik verdi for metaværdien (eller det tredje argumentet) i funksjonssamtalen. Oppdater siden noen ganger, og ta en titt på databasen. Det skal se slik ut:
Legg merke til hva som er interessant? Det er fortsatt flere verdier, men de er alle de samme.
Prøv nå å endre meta-verdi-argumentet et par ganger, og ta en titt på databasen, og du bør se noe slikt:
Legg merke til forskjellen? Nøyaktig-det er ikke en. Det er fordi vi sa at det bare kunne være en unik nøkkel. Så det betyr ikke nødvendigvis at bare en plate er opprettet. Det betyr at flere poster vil bli opprettet når funksjonen kalles, men den vil alltid bruke den første verdien som den lagret som er knyttet til nevnte nøkkel.
Hvis du vil, kan du gå videre og slette rader som vi nettopp har opprettet, da dette gir en flott segue til neste funksjon.
Oppdaterer bruker Meta
På samme måte som Post Meta API fungerer, fungerer oppdateringsfunksjonaliteten på følgende måte:
Oppdater bruker meta-feltet basert på bruker-ID. Bruk parameteren $ prev_value til å skille mellom metafelt med samme nøkkel og bruker-ID. Hvis metafeltet for brukeren ikke eksisterer, blir det lagt til.Når du arbeider med denne funksjonen, hjelper det å tenke på dette i to scenarier:
- når tidligere metadata er lagt til ved hjelp av
add_user_meta
funksjon og det er flere poster med samme informasjon- når ingen metadata er lagt til, og vi legger til en ny post og ønsker at den skal være unik
I det første tilfellet bidrar det til å gi
$ prev_value
fordi du forteller WordPress som verdi for å målrette og å oppdatere.Når vi har lagt til metadata
For eksempel, anta at vår database ser ut som den gjorde tidligere i opplæringen:
Og vi vil oppdatere postene som har forrige verdi av
https://twitter.com/tommcfarlin/
. For å gjøre det, vil vi oppdatere koden som ser slik ut.Og så vil oppdateringen til databasen se slik ut:
Vær oppmerksom på at denne oppdateringen alle verdier som er knyttet til denne metatasten. Selvfølgelig er det bare en bruk av funksjonen.
Når du legger til nye metadata
I andre tilfelle trenger du ikke å spesifisere en tidligere verdi fordi du skal legge til informasjon for første gang.
For å avklare, kan du bruke
update_user_meta
funksjon når du vil legge til informasjon i databasen. Det trenger ikke å eksistere før du bruker det.Dette er nyttig når du vil legge til en enkelt, unik plate som ennå ikke er lagt til i databasen. Bruk av funksjonen er enkel. La oss si at vi vil lagre brukerens søskenavn.
I dette tilfellet vil vi gjøre dette:
Og dette resulterer i at følgende post blir lagt inn i databasen:
Hvis du oppdaterer siden flere ganger og deretter sjekker databasetabellen, vil du legge merke til at bare en enkelt forekomst av verdien er skrevet versus flere verdier som kommer når du bruker
add_user_meta
.Så hvis vi ville endre den verdien, ville vi oppdatere metaværdien som er knyttet til den angitte metatasten, og den ville oppdatere den enkelte platen.
Henter bruker Meta
Når det gjelder å hente bruker metadata, har vi
get_user_meta
funksjon. På dette tidspunktet bør det være klart at de forventede parametrene vil være bruker-ID og meta-nøkkelen.Men hva med meta verdien?
Husk når vi henter informasjon, trenger vi bare bruker-IDen og metatasten siden det er identifikasjonsinformasjonen for en bestemt verdi.
Men hva skjer hvis utvikleren har flere poster for en enkelt nøkkel? Nærmere bestemt, hva hvis de har brukt
add_user_meta
fungere som vi har gjort ovenfor og har flere poster?Her kommer den valgfrie fjerde parameteren til spill: En boolsk verdi som vi spesifiserer hvis vi ønsker å hente en enkelt verdi eller en rekke verdier. Standardverdien (den som er bestått hvis den ikke er angitt) er
falsk
så vi får alltid tilbake en matrise med mindre vi angir noe annet.Henter alle poster
La oss anta at vi jobber av samme sett med data fra tidligere i opplæringen. Det vil si at vi har flere oppføringer for en brukers Twitter-konto. Husk at databasen så slik ut:
For å få all denne informasjonen ut av databasen og vist på skjermen, bruker vi følgende kode:
Forutsatt at alt gikk bra, bør du se noe som dette på toppen av din Hei Verden post:
[0] => streng (32) "https://twitter.com/tommcfarlin/" [1] => streng (32) "https://twitter.com/tommcfarlin/" [2] => streng 32) "https://twitter.com/tommcfarlin/" [3] => streng (32) "https://twitter.com/tommcfarlin/"Hvis ikke, dobbeltklikk anropet til var_dump du har laget, og kontroller at informasjonen er i databasen klar til å bli hentet.
Henter en enkelt post
I tilfelle du vil hente en enkelt post, kan du passere sann som den siste parameteren til funksjonen. Dette henter den første platen som ble opprettet i strengformat.
Og resultatet av denne koden vil skrive ut dette øverst på siden Hei Verden innlegg som vi har jobbet med fra:
https://twitter.com/tommcfarlin/Merk at hvis du bruker
update_user_meta
og du ikke spesifisereekte
Som den endelige parameteren vil du få en enkeltindeksarrangering sendt tilbake til deg.array (1) [0] => streng (32) "https://twitter.com/tommcfarlin/"Dermed, hvis du leter etter en strengrepresentasjon av informasjon, må du alltid passere
ekte
.Sletter Bruker Meta
Det siste vi må dekke er hvordan du faktisk sletter dataene som vi har skrevet til databasen. Hvis du har fulgt sammen med denne serien så langt, så vil du sannsynligvis utvikle en slags intuisjon om hvordan denne spesielle funksjonen skal fungere.
Fra den medfølgende Codex-siden:
Fjern metadata-matchende kriterier fra en bruker. Du kan matche basert på nøkkelen, eller nøkkel og verdi. Fjerning basert på nøkkel og verdi, vil fortsette å fjerne dupliserte metadata med samme nøkkel. Det tillater også å fjerne alle metadata matching nøkkel, om nødvendig.Merk at denne funksjonen er utformet for å fungere i tilfelle der det finnes flere poster som eksisterer, og du vil slette dem alle, eller når du har en enkelt plate som eksisterer og du vil fjerne den.
Slette flere poster
Først tar vi en titt på hvordan du bruker denne funksjonen når det er flere poster med samme informasjon. La oss anta at databasen ser slik ut i dette eksemplet:
Her har vi flere poster. For å slette poster som har samme nøkkel, bruker vi en enkelt samtale til
delete_user_meta
funksjon og pass bruker-ID og metatast.Og hvis du oppdaterer informasjonen i databasetabellen, merker du at alle postene er slettet:
Selv om dette er en enkel funksjon å bruke, er det viktig å huske at det kan slette flere rader i en enkelt samtale, så bruk den med forsiktighet.
En enkelt post
Hvis du derimot har en enkelt post for å slette, trenger du tre opplysninger:
- brukerens ID
- meta-nøkkelen
- meta verdien
Å ha alle tre verdiene vil tillate deg å slette en enkelt post. Det er klart at det gir mye mer presisjon enn forrige bruk av denne funksjonen.
Så, i vårt eksempel, la oss si at vi har to poster, som begge har
twitter_account
metatast. Hver nøkkel har følgende verdi:
https://twitter.com/tommcfarlin
https://twitter.com/pressware
I vårt eksempel er vi bare opptatt av å fjerne den andre verdien. For å gjøre det, bruker vi følgende kode:
Og så hvis du oppdaterer databasen din, bør du se følgende (eller noe lignende):
Det er fint når en API utfører akkurat som du forventer.
Den komplette kildekoden
Her er en kopi av all kildekoden vi dekket i denne artikkelen. Vær oppmerksom på at
ADD_ACTION
samtaler har blitt kommentert som du trenger å uncomment dem basert på hva du vil gjøre når du eksperimenterer med koden.I tillegg kan du legge til dette i filen som vi opprettet i den forrige opplæringen. Det var det jeg gjorde da jeg jobbet med eksemplene; Du kan imidlertid være forsiktig når du arbeider på filen slik at den er riktig
ADD_ACTION
samtaler er satt basert på hva det er du vil gjøre.Konklusjon
Som nevnt tidligere i artikkelen, kan du gjennomgå hver av funksjonene i WordPress Codex, som alltid bør være et klikk unna for en WordPress-utvikler.
I den endelige artikkelen i denne serien skal vi se på hvordan vi skal håndtere kommentat metadata. Gitt det vi har lært så langt, bør det være noe som er relativt enkelt å plukke opp.
Selvfølgelig forlater det oss fortsatt metadata relatert til taksonomier. På grunn av arten av taksonomier, vilkår og APIene, vurderer vi de i oppfølgingsserien.
For nå, fortsett å eksperimentere med koden som er gitt i denne artikkelen. Husk at den kun er ment for demonstrasjonsformål, og bør ikke kjøres i et produksjonsmiljø.
Gjennom hele denne serien prøver vi å legge grunnlaget for fremtidige WordPress-utviklere å bygge fra når de går frem og jobber med løsninger for arbeidsgiver, deres kunder eller for egne prosjekter.
Med det sagt, gleder jeg meg til å fortsette denne serien. Husk at hvis du bare har begynt, kan du sjekke ut serien min om hvordan du kommer i gang med WordPress, som fokuserer på temaer spesielt for WordPress-nybegynnere.
I mellomtiden, hvis du leter etter andre verktøy for å hjelpe deg med å bygge ut ditt voksende sett med verktøy for WordPress eller koden for å studere og bli mer kjent med WordPress, ikke glem å se hva vi har tilgjengelig i Envato Marked.
Endelig kan du se alle mine kurs og opplæringsprogrammer på min profilside, og du kan lese flere artikler om WordPress og WordPress-utvikling på bloggen min. Følg med på Twitter også på @tommcfarlin hvor jeg snakker om ulike programvareutviklingspraksis og hvordan vi kan bruke dem i WordPress.
Ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under, og jeg vil sikte på å svare på hver av dem.
ressurser