Slik jobber du med WordPress Post-metadata

I det første innlegget i denne serien ga jeg en oversikt over alle de ulike metadataene som tilbys av WordPress, hvor den holdes, og hva vi skal dekke gjennom hele denne serien. 

Videre definerte jeg hvilke metadata som er; sin rolle innenfor WordPress, og hvordan det er relevant for oss som utviklere. Men introduksjonen var ment å være nettopp det: en undersøkelse av hva vi skal dekke gjennom resten av denne serien.

Fra dette innlegget begynner vi å utforske WordPress Post Meta API for å se hvorfor det er nyttig, hva vi kan gjøre med det, og hvordan du kan dra nytte av metodene som tilbys via WordPress-programmet.

En ansvarsfraskrivelse for alle

Først, hvis du er en avansert utvikler, så er det ikke sannsynlig at denne serien av opplæringsprogrammer skal være til stor hjelp for deg. I stedet er det rettet mot de som har jobbet litt med temaer, kanskje tweaked noen plugin kode, og er klare til å ta det et skritt videre ved å legge til litt ekstra informasjon til innleggene (eller posttypene) som komponerer prosjektet sitt.

For det andre, merk at kodeeksemplene i denne opplæringen er ikkefor bruk i et produksjonsmiljø. I stedet er koden vi skal se på, ikke ment å bli brukt hvor som helst som har offentlig tilgang til nettstedet.

Akkurat nå planlegger jeg å dekke mer avanserte teknikker for dette emnet etter at vi jobber oss gjennom denne serien. Men for nå skal vi bare bekymre oss for å jobbe med APIen.

Men hvorfor? Hva er forsinkelsen i å dekke tilleggsinformasjon? Enkelt sagt, det har å gjøre med nettsikkerhet. Nærmere bestemt, når vi skriver informasjon inn i databasen, må vi anta at dataene ikke er i et format som er trygt for oss å lagre; vi må desinfisere dataene.

Det er et helt annet sett med APIer for sanitering av data vi trenger å utforske som vil fungere sammen med metadata-APIer, men dette er ikke veiledningen for å gjøre det.

Jeg vet at det kan høres litt frustrerende å snakke om disse APIene uten å kunne utnytte dem. Husk, men dette er ment å være en introduksjon til API. Opplæringsprogrammene skal gi deg nok informasjon til å komme i gang med å jobbe med post-metadata på maskinen din, men bør også legge til nok spørsmål slik at vi kan ta en dykker dykk inn i emnet i en fremtidig serie artikler.

Med det sagt, la oss gå videre og komme i gang med WordPress Post Meta API. Og vær advart: Dette er en lang opplæring.

En introduksjon til API

Før vi ser på koden, er det viktig å sørge for at du har de nødvendige verktøyene for å bla gjennom databasen som din WordPress-installasjon kjører. Noen av de tilgjengelige verktøyene inkluderer:

• phpMyAdmin
• Sequel Pro
• MySQL arbeidsbenk
• Adminer

Men vær så snill å bruke det du liker mest. Så lenge du kan se dataene i databasen, er du klar til å gå.

Deretter forstår vi hvordan WordPress definerer innleggsmetadata. I henhold til Codex:

WordPress har muligheten til å tillate postforfattere å tilordne egendefinerte felt til et innlegg. Denne vilkårlig ekstra informasjon er kjent som metadata.

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.

I enklere termer tillater WordPress oss å skrive tilpasset informasjon til databasen, knytte den til et hvilket som helst innlegg vi ønsker, og hente det etter behov. Videre lagres informasjonen ved hjelp av unike nøkkel / verdi par.

Skrive egne metadata

Hvis dette høres utelukkende for deg, ikke engang bekymre deg for det. Tanken er at for hver verdi du lagrer, er den relatert til en unik nøkkel (omtrent som en dørknap har en unik nøkkel for å låse den opp). 

Nøkkelen er hvordan vi kan hente verdien fra innlegget. Men dette reiser et spørsmål: Hva skjer hvis et innlegg har flere biter av metadata knyttet til det? Det vil si at hvis et gitt innlegg kan ha flere stykker metadata lagret sammen med det, hvordan henter vi unike metadata?

Som vi ser når vi begynner å se på noen av eksemplskoden under, i tillegg til å bruke nøkkelen som brukes til lagring av data, må vi også sende innleggets unike ID til funksjonen.

Ingenting fungerer bedre enn å se det i aksjon, skjønt. Så forutsatt at du har WordPress satt opp på din lokale maskin, og at du er ok med redigering functions.php i kjernen til standardtemaet, la oss komme i gang.

For referanse

Jeg bruker følgende verktøy:

• WordPress 4.4
• Twentysixteen temaet
• Atom
• Sequel Pro

Det viktigste er at du kjører både WordPress og temaet som er nevnt ovenfor.

Til slutt, hvis du er mer komfortabel med en annen IDE og database front-end, er det helt greit.

Vi har dekket mye informasjon i introduksjonen av denne artikkelen, men det kommer til nytte når vi begynner å se ikke bare på Post Meta API, men også de andre APIene. Så vær så snill. Jeg vil også referere til denne artikkelen i fremtidige artikler.

La oss grave inn i API-en.

En veldig viktig kommentar

Måten vi skal innlemme koden på er ikke den profesjonelle måten å gjøre endringer i temaet ditt, implementere denne funksjonaliteten eller grensesnitt med en API. Vi gjør dette for en nybegynners første skritt i WordPress-utvikling. 

I en oppfølgingsserie skal vi ta det arbeidet vi har gjort i denne serien og trekke den ut i et mer vedlikeholdbart plugin som også inkluderer et større fokus på vedlikehold, sikkerhet og mer.

For tiden fokuserer vi på grunnlinjen til APIen.

Forbereder temaet

Husk at jeg bruker en grunnleggende installasjon av WordPress sammen med det twentysixteen temaet for demoer som vi kommer til å se gjennom denne opplæringen og resten av opplæringen i serien.

For det andre skal vi gjøre endringer i functions.php. Dette er vanligvis ikke det beste stedet å gjøre denne endringen; Vær imidlertid oppmerksom på at du har lest notatet ovenfor før du fortsetter.

Med det sagt, la oss anta at du har serveren din, din IDE opp og klar, og functions.php i redaktøren din. Selv om skjermbildet ditt kan se litt annerledes ut, bør det ligne dette:

Utfordringen med å jobbe med functions.php er at den allerede er full av kode som bidrar til å makt det eksisterende temaet. Selv om vi til slutt skal flytte koden til et plugin i en fremtidig serie, la vi i det minste ta det første skrittet i å lage vår fil slik at vi kan selv inneholde vår kode.

Bruk din IDE av valg:

1. Opprett en ny fil i rotkatalogen av temaet twentysixteen.
2. Gi filen navnet tutsplus-metadata.php.

Når du er ferdig, bør du ha noe sånt på filsystemet ditt:

Til slutt må vi sørge for at vi inkluderer dette functions.php. For å gjøre det, legg til følgende linje av kode like under åpningen PHP-taggen. 

Last inn nettleseren din. Hvis alt går bra, bør du se temaet akkurat som det var før du lagde filen til functions.php. 
La oss nå komme på jobb.
Starter
Husk vår tidligere diskusjon at vi trenger tre ting for å legge til metadata i databasen:
 
en post-ID
 
en unik nøkkel som vi kan identifisere metadataene til
 
en verdi som vi skal lagre som vi vil senere hente
 
For denne opplæringen er alt vi er opptatt av å legge til metadata som vises på standardinnstillingen Hei Verden! post som kommer som standard i hver installasjon av WordPress.
La oss si at vi vil legge til noen metadata som inneholder navnet vårt. Så meta-nøkkelen vi skal bruke er mitt navn og verdien som vi skal bruke er hva navnet ditt er. I mitt tilfelle er det "Tom McFarlin".
Det første vi ønsker å gjøre er å definere en funksjon som kroker inn innholdet. Dette vil tillate oss å skrive ut vår tekst når funksjonen kjører. Hvis du ikke er kjent med kroker, vennligst les denne serien.
Din første kode skal se slik ut:
Når du kjører denne koden, må strengen "[Vi er her.]" Vises over innleggets innhold før noe annet, og det skal bare skje på Hei Verden! post. Dette skyldes at vi sjekker for at IDen er 1 før vi ekko strengen.
Merk at den endelige versjonen av koden som deles på slutten av dette innlegget, vil være komplett med kommentarer. Inntil da forklarer jeg hva koden gjør når vi legger til hvert nytt brikke i koden vår.
Legge til metadata
La oss nå legge til noen faktiske metadata. For å gjøre dette, legg til denne koden i betingelsen, slik at vi er sikre på at vi gjør det for Hei Verden. Siden vi allerede ser etter ID-en 1 i betinget, kan vi bare fjerne koden vi la til i forrige seksjon, og oppdatere den.
Innenfor betingelsens kropp skal vi ringe til add_post_meta API-funksjonen som ser slik ut:
Det ville vært fint om vi kunne gjøre noe med denne informasjonen. Før vi gjør det, er det noe mer informasjon vi trenger å dekke. Nemlig om oppdatering av metadata (og hvordan det adskiller seg fra å legge til metadata) sammen med noen nyanser du kanskje ikke forventer når du arbeider med API.
Oppdaterer metadata
Det er en subtil forskjell mellom å legge til metadata og oppdatere metadata. Du vet hvordan en nøkkel unikt identifiserer en verdi som er knyttet til den? Vel, det er delvis nøyaktig.
Når du ringer add_post_meta, du lager en oppføring hver eneste gang du foretar samtalen. Så i koden ovenfor, hvis du oppdaterer siden tre ganger, så kommer du til å se noe slikt:
Nysgjerrig, ikke sant? Husk hva Codex sier:
Merk at hvis den oppgitte nøkkelen allerede eksisterer blant egendefinerte felt i det angitte innlegget, blir et annet egendefinert felt med samme nøkkel lagt til med mindre det unike argumentet er satt til ekte, i så fall blir det ikke gjort noen endringer.
Ah, det er en valgfri parameter som funksjonen aksepterer. Det er en boolsk kalt $ unik, og det tillater oss å passere ekte hvis vi bare vil sørge for at verdien som er lagt til er unik.
Du vil kanskje slette dine eksisterende poster på dette punktet. Hvis ikke, det er greit, bare bruk en annen verdi for mitt navn nøkkel.
Dette betyr at vi kan oppdatere koden vår slik at den ser slik ut:
Nå lager du bare en enkelt oppføring. Videre, hvis du skulle prøve å endre verdien av nøkkelen i koden, så det ville ikke bli overskrevet i databasen. Når du har skrevet posten, er metadata fullført, det lagres som det var første gang.
Men det må ikke være slik, og det er der update_post_meta kommer inn i spill. Faktisk, update_post_meta kan brukes mer enn add_post_meta, avhengig av brukstilstanden din.
Før du tar en titt på koden, sjekk ut hva Codex har å si:
 
Funksjonen update_post_meta () oppdaterer verdien av en eksisterende meta-nøkkel (egendefinert felt) for det angitte innlegget.
 
Dette kan brukes i stedet for add_post_meta () -funksjonen. Det første som denne funksjonen vil gjøre, er å sørge for at $ meta_key allerede eksisterer på $ post_id. Hvis ikke, blir add_post_meta ($ post_id, $ meta_key, $ meta_value) kalt i stedet og resultatet returneres.
 
Fikk du det? Det kan "brukes i stedet for add_post_meta", som er nyttig fordi dette betyr:
 
Hvis postmetadataene allerede eksisterer for en gitt nøkkel,
 
Hvis du bruker update_post_meta,
 
Du vil overskrive den forrige verdien.
 
På dette tidspunktet vil du kanskje slette informasjonen du har i databasen din, eller opprette et nytt par nøkler og verdier. Dette betyr at vi kan oppdatere koden vår slik at den ser slik ut:
Dette bringer noen iboende farer med det, skjønt. 
Hvis du overskriver en verdi som du aldri hadde tenkt å overskrive på, er den verdien borte, og den kan ikke gjenvinnes (med mindre du gjør mer avansert arbeid som er utenfor rekkevidden av denne serien).
Det er et valgfritt endelig argument for update_post_meta, skjønt, og det er det $ prev_value argument. Det vil si, du kan angi hvilken verdi du vil overskrive.
Ta for eksempel tilfelle der du har flere poster med samme nøkkel opprettet med add_post_meta og du vil bare oppdatere en av disse postene. For å oppdatere dataene, vil du passere i verdien som tilsvarer den ene posten.
Hva er forskjellen?
Forskjellen mellom add_post_meta og update_post_meta kan betraktes som subtile, men det avhenger av brukssaken din. 
Jeg vil prøve å slå dem ned så enkelt som mulig her fordi, selv om det kan virke komplisert gitt eksemplene vi har sett ovenfor, er det mer greit når du legger alt ut.
 
 add_post_meta er nyttig når du vil introdusere en rekord i databasen. Hvis verdien allerede finnes, kan den nye verdien eller ikke skrives. Hvis du passerer ekte for $ unik parameter for funksjonen, vil bare den første posten bli opprettet, og ingenting vil overskrive det unntatt update_post_meta.
 
 update_post_meta kan brukes i stedet for add_post_meta og vil alltid overskrive den forrige verdien som eksisterte. Hvis du jobber med flere poster opprettet av add_post_meta, da må du kanskje angi en tidligere verdi som du ønsker å overskrive.
 
Og det er alt. Selvfølgelig må vi fortsatt håndtere opptakene fra databasen og vise dem på skjermen.
Henter metadata
Når det gjelder å hente postmetadata, er det to hovedtrekk du må huske:
 
Metadata kan hentes som en streng.
 
Metadata kan hentes som en matrise.
 
Noen ganger er det avhengig av hvordan du lagret den opprinnelige informasjonen; andre ganger er det basert på hvordan du vil jobbe med det.
Før vi ser på de ulike måtene vi kan hente informasjon, la oss først se på det grunnleggende API-anropet for å gjøre det. Spesielt snakker jeg om get_post_meta. Hvis du har fulgt sammen så langt, bør forståelse av API være relativt enkelt.
Funksjonen aksepterer tre parametere:
 
ID av posten
 
metadata nøkkelen
 
en valgfri boolesk verdi for hvis du vil hente verdien som en streng eller som en matrise (der en matrise er standardverdien hvis ingenting er angitt)
 
Fra Codex:
Hent postmeta-feltet for et innlegg. Vil være en matrise hvis $ single er feil. Vil være verdien av meta data feltet hvis $ single er sant.
Virker lett nok. Så gitt hvor den siste delen av kildekoden sitter akkurat nå, vil jeg si at vi kan hente informasjon ved å ringe som get_post_meta (get_the_ID (), 'my_name');.
Koden, som den står over, vil returnere en matrise. 
Flere verdier
Når du hører uttrykket "flere verdier", kan det være nyttig å tenke på en matrise eller en slags datainnsamling i programmeringsspråket du bruker.
I eksemplene våre, tenk på når vi lagret den samme nøkkelen flere ganger med add_post_meta. Som en oppdatering, her var det som databasen så ut som:
Hvis jeg skulle hente informasjonen med nøkkelen, hva ville jeg komme tilbake? Siden jeg ikke angav at jeg ønsket en streng, ville jeg få tilbake en rekke av alle postene. Dette vil tillate meg å iterere gjennom hver av dem.
Hvis jeg derimot skulle spesifisere sant for å ønske å få tilbake en streng, så ville jeg bare få den første raden som ble opprettet ved hjelp av add_post_meta.
Til dette formål, hvis du ønsker å få tilbake flere verdier for en gitt nøkkel, vil koden din se slik ut:
Legg merke til at jeg bruker var_dump for å gjøre det enklere å se hvilken informasjon som returnerer fra WordPress i nettleseren; Jeg er imidlertid mer av en fan av å bruke en debugger, noe som vi kan diskutere i et fremtidig innlegg. 
Enkeltverdier
La oss si at du vil få enkle verdier lagret for ett innlegg. I dette tilfellet trenger du fortsatt post-ID og metadatastasten; Du må imidlertid også gi ekte som den tredje parameteren til get_post_meta.
Som nevnt ovenfor, hvis du arbeider med en situasjon der flere rader er opprettet ved hjelp av add_post_meta, så skal du komme tilbake den første raden som ble opprettet; Men hvis du bruker denne funksjonen sammen med update_post_meta så får du tilbake en strengverdi av dataene som ble lagret.
Siden vi har dekket den tidligere, men ikke dekket sistnevnte, her ser koden ut:
Og så får du tilbake hvilken verdi du lagret som meta-verdien når du ringer til funksjonen. Det er ganske enkelt i forhold til å måtte jobbe med et sett med poster og arrays som kanskje inneholder eller ikke inneholder lignende opplysninger.
Slette metadata
Den siste delen av arbeidet med post-metadata har alt å gjøre med å kunne slette det. Det er enkelt, men det er bare noen få nyanser som vi trenger å forstå for å sikre at vi gjør det effektivt.
Men først, her er definisjonen fra Codex:
Denne funksjonen sletter alle egendefinerte felt med den angitte nøkkelen, eller nøkkel og verdi, fra det angitte innlegget. 
Kort, søt og til poenget. Funksjonen aksepterer tre argumenter:
 
ID av posten
 
meta-nøkkelen
 
meta verdien
 
Meta verdien er valgfri, men det kommer til nytte hvis du har jobbet med add_post_meta og vil slette en av de spesifikke oppføringene som er opprettet ved flere samtaler til den funksjonen (som vi har sett andre steder i hele denne opplæringen).
Selv om du ringer til delete_post_meta er like enkelt som å sende en post-ID, meta-nøkkelen og valgfri meta-verdi, returnerer funksjonen en boolsk verdi som angir om dataene ble fjernet.
Eksempelkoden for å slette noen av postmetadataene som vi har sett på så langt, kan se slik ut:
Implementeringen din kan imidlertid variere. Hvis du jobber med flere stykker metadata, og hvis du vil bekrefte at det var en vellykket sletting, kan du kaste koden i en betinget.
Et siste eksempel på kode
Nedenfor finner du en lang, dokumentert kodebit som skal utgjøre flertallet av det vi har snakket om i denne opplæringen. Legg merke til at funksjonene er festet inn innholdet.
Dette er bare for demonstrasjonsformål, slik at du enkelt kan utløse avfyring av disse funksjonene når du laster inn en bestemt side.
Vanligvis finner du metadatafunksjoner knyttet til andre kroker, for eksempel lagre post og lignende operasjoner, men dette er et emne for mer avansert arbeid. Kanskje vi vil dekke det i en annen serie senere i år.
Konklusjon
Hver eneste av API-funksjonene er tilgjengelig i WordPress Codex, så hvis du ønsker å hoppe videre og gjøre litt mer lesing før neste artikkel i serien, så vær så snill å gjøre det.
Som tidligere nevnt, er dette en introduksjon til WordPress Post Meta API. Gjennom informasjonen som er gitt i Codex, i denne opplæringen og i kildekoden som er oppgitt, bør du kunne begynne å skrive tilleggsinnhold til databasen relatert til hvert av innleggene dine.
Husk at dette er ment for demonstrasjonsformål, da vi har mer informasjon å dekke. Nærmere bestemt må vi undersøke data sanitisering og data validering. Selv om vi har flere emner som dekker først (for eksempel brukermetadata, kommentarmetadata og så videre), vil vi snart gå videre til mer avanserte emner snart.
Til slutt prøver vi å legge grunnlaget for fremtidige WordPress-utviklere å bygge fra når de går frem og arbeider med løsninger for andre, for deres byråer eller til og med for sine 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.
Husk at du kan fange alle mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter 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
 
Egendefinerte felt
 
add_post_meta
 
update_post_meta
 
get_post_meta
 
delete_post_meta
 
Post Meta Funksjon Eksempler
 
ekko
 
var_dump
 



		
			
	   
	




Kode