Hur man arbetar med WordPress Post-metadata

I det första inlägget i den här serien gav jag en översikt över alla olika typer av metadata som erbjuds av WordPress, där den hålls och vad vi ska täcka genom hela serien. 

Vidare definierade jag vad metadata är; sin roll inom WordPress, och hur det är relevant för oss som utvecklare. Men introduktionen var tänkt att vara just det: en undersökning av vad vi ska täcka över resten av serien.

Med början i det här inlägget kommer vi att börja utforska WordPress Post Meta API för att se varför det är användbart, vad vi kan göra med det och hur du utnyttjar de metoder som erbjuds via WordPress-programmet.

En ansvarsfriskrivning för alla

Först om du är en avancerad utvecklare, är det inte troligt att den här serien av handledning kommer att vara till stor hjälp för dig. I stället är det mer anpassat mot dem som har arbetat lite med teman, kanske tweaked plugin-kod och är redo att ta det ett steg längre genom att lägga till extra information till inläggen (eller posttyperna) som komponerar sitt projekt.

För det andra, notera att kodexemplen i denna handledning är inteför användning i en produktionsmiljö. Istället är koden vi ska titta på inte avsedd att användas överallt där någon har allmänhetens tillgång till webbplatsen.

Just nu planerar jag att täcka mer avancerade tekniker för detta ämne efter att vi arbetar igenom denna serie. Men för tillfället kommer vi bara att ägna oss åt att arbeta med API: n.

Men varför? Vad är förseningen när det gäller att täcka ytterligare information? Enkelt uttryckt, det har att göra med webbplats säkerhet. När vi skriver information i databasen, måste vi utgå ifrån att data inte finns i ett format som är säkert för oss att lagra; vi måste sanitera uppgifterna.

Det finns en helt annan uppsättning API för sanering av data vi behöver utforska som kommer att fungera i samband med metadatap API, men det här är inte handledningen för att göra det.

Jag vet att det kanske låter lite frustrerande att prata om dessa API utan att kunna utnyttja dem. Kom ihåg, men det här är meningen att vara en introduktion till API: n. Tutorialsna bör ge tillräckligt med information för att du ska kunna börja arbeta med postmetadata på din maskin, men borde också lämna tillräckligt med frågor så att vi kan ta en djupare in i ämnet i en kommande serie artiklar.

Med det sagt, låt oss gå vidare och komma igång med WordPress Post Meta API. Och varnas: Detta är en lång handledning.

En introduktion till API: n

Innan vi tittar på koden är det viktigt att du har nödvändiga verktyg för att bläddra i databasen där din WordPress-installation körs. Några av de tillgängliga verktygen är:

• phpMyAdmin
• Sequel Pro
• MySQL Workbench
• Adminer

Men gärna använda vad du helst tycker om. Så länge du kan se data i databasen är du redo att gå.

Låt oss förstå hur WordPress definierar efter metadata. Enligt Codex:

WordPress har möjlighet att tillåta författare att tilldela anpassade fält till ett inlägg. Denna godtyckliga extra information kallas metadata.

Metadata hanteras med nyckel / värdepar. Nyckeln är namnet på metadataelementet. Värdet är den information som kommer att visas i metadata listan på varje enskild post som informationen är associerad med.

I enklare termer tillåter WordPress oss att skriva anpassad information till databasen, associera den med vilken post som helst, och sedan hämta den efter behov. Vidare lagras informationen med hjälp av unika nyckel / värdepar.

Skriva egna metadata

Om det här låter främmande för dig, oroa dig inte ens om det. Tanken är att för varje värde som du lagrar är det relaterat till en unik nyckel (ungefär som en dörrknapp har en unik nyckel för att låsa upp den). 

Nyckeln är hur vi kan hämta värdet från inlägget. Men det här ställer upp en fråga: Vad händer om ett inlägg har flera bitar metadata i samband med det? Det vill säga, om ett visst inlägg kan ha flera bitar metadata lagrade bredvid det, hur hämtar vi unika metadata?

Som vi ser när vi börjar titta på några exempelkod nedan, behöver vi, förutom att använda nyckeln som används vid lagring av data, också skicka inläggets unika ID till funktionen.

Ingenting fungerar bättre än att se det i åtanke. Så antar att du har WordPress på din lokala maskin och att du är okej med redigering functions.php i kärnan i ditt standardtema, låt oss börja.

Som referens

Jag använder följande verktyg:

• WordPress 4.4
• Twentysixteen-temat
• Atom
• Sequel Pro

Det viktigaste är att du kör både WordPress och det ovan nämnda temat.

Slutligen, om du är mer bekväm med en annan IDE och databasfronten, är det helt bra.

Vi har täckt mycket information i introduktionen av den här artikeln, men det kommer att vara till nytta när vi börjar titta inte bara på Post Meta API utan även de andra API-erna. Så håll ihåg det här. Jag kommer också att hänvisa till den här artikeln i framtida artiklar.

Låt oss gräva i API: n.

En mycket viktig anteckning

Det sätt på vilket vi kommer att införliva koden är inte Det professionella sättet att ändra på ditt tema, implementera denna funktionalitet eller koppla ihop med ett API. Vi gör detta för en nybörjare första steg i WordPress utveckling. 

I en uppföljningsserie kommer vi att ta det arbete vi har gjort i serien och extrahera det till ett mer underhållbart plugin som också inkluderar ett större fokus på underhåll, säkerhet och mer.

För närvarande fokuserar vi på API: s grunder.

Förbereda teman

Kom ihåg att jag använder en grundläggande installation av WordPress tillsammans med det twentysixteen-temat för demoer som vi kommer att se under hela denna handledning och resten av handledningarna i serien.

För det andra kommer vi att göra förändringar i functions.php. Detta är vanligtvis inte det bästa stället att göra denna förändring. Se till att du har läst anteckningen ovan innan du fortsätter.

Med det sagt, låt oss anta att du har din server igång, din IDE upp och redo, och functions.php i din redaktör Även om din skärmdump kan se lite annorlunda ut, borde den likna detta:

Utmaningen med att arbeta med functions.php är att den redan är full av kod som hjälper till att driva befintligt tema. Trots att vi äntligen kommer att flytta vår kod till ett plugin i en framtida serie, låt oss åtminstone ta det första steget i att göra vår fil så att vi kan innehålla vår kod.

Med ditt IDE val:

1. Skapa en ny fil i rotkatalogen av temaet twentysixteen.
2. Namnge filen tutsplus-metadata.php.

När du gjort det borde du ha något liknande på ditt filsystem:

Slutligen måste vi se till att vi inkluderar det här functions.php. För att göra det, lägg till följande kodlinje precis under den öppna PHP-taggen. 

Ladda om din webbläsare. Om allt går bra borde du se temat exakt som det var innan du lägger till filen till functions.php. 
Nu ska vi komma till jobbet.
Komma igång
Kom ihåg vår tidigare diskussion om att vi behöver tre saker att lägga till metadata i databasen:
 
ett post-ID
 
en unik nyckel som vi kan identifiera metadata
 
ett värde som vi kommer att lagra som vi senare vill hämta
 
För den här handledningen är allt vi oroar oss för att lägga till metadata som kommer att visas på standardvärdet Hej världen! post som kommer som standard i varje installation av WordPress.
Låt oss säga att vi vill lägga till några metadata som innehåller vårt namn. Så meta nyckeln vi ska använda är mitt namn och det värde vi ska använda är vad ditt namn är. I mitt fall är det "Tom McFarlin".
Det första vi vill göra är att definiera en funktion som krokar in innehållet. Detta gör att vi kan skriva ut vår text när funktionen körs. Om du inte känner till krokar, läs den här serien.
Din ursprungliga kod ska se så här ut:
När du kör denna kod måste strängen "[Vi är här.]" Visas ovanför postinnehållet innan något annat, och det borde bara hända på Hej världen! posta. Detta beror på att vi kontrollerar att ID-numret är 1 före vi eko tråden.
Observera att den slutliga versionen av koden som delas i slutet av detta inlägg kommer att vara komplett med kommentarer. Fram till dess förklarar jag vad koden gör när vi lägger till varje nytt stycke i vår kod.
Lägga till metadata
Låt oss nu lägga till några faktiska metadata. För att göra så lägg till den här koden i den villkorliga delen så att vi är säkra på att vi gör det för Hej världen. Eftersom vi redan söker efter ID 1 på villkorligt sätt kan vi bara ta bort koden vi lade till i föregående avsnitt och uppdatera det.
Inom ramen för det villkorade ska vi ringa till add_post_meta API-funktionen som ser ut så här:
Det skulle vara trevligt om vi kunde göra något med den här informationen. Innan vi gör det finns det dock mer information vi behöver täcka. Namnlösa: Om uppdatering av metadata (och hur det skiljer sig från att lägga till metadata) tillsammans med några nyanser du kanske inte förväntar dig när du hanterar API.
Uppdatering av metadata
Det finns en subtil skillnad mellan att lägga till metadata och uppdatera metadata. Du vet hur en nyckel unikt identifierar ett värde som är associerat med det? Tja, det är delvis korrekt.
När du ringer add_post_meta, Du skapar en post varje gång du ringer det. Så i vår kod ovan, om du uppdaterar sidan tre gånger så kommer du att se något så här:
Nyfiken, eller hur? Minns vad Codex säger:
Observera att om den angivna nyckeln redan finns bland anpassade fält i det angivna inlägget, läggs ett annat anpassat fält med samma nyckel till, om inte det unika argumentet är satt till true, i vilket fall inga ändringar görs.
Åh, det finns en valfri parameter som funktionen accepterar. Det är en booleska som heter $ unik, och det låter oss passera Sann om vi bara vill se till att det värde som läggs till är unikt.
Du kanske vill ta bort dina befintliga poster vid denna tidpunkt. Om inte, det är bra - använd bara ett annat värde för mitt namn nyckel-.
Det innebär att vi kan uppdatera vår kod för att se så här ut:
Nu skapar du bara en enda post. Dessutom, om du skulle försöka ändra värdet på den nyckeln i koden, då det skulle inte skrivas över i databasen. När du har skrivit inläggets metadata är färdig lagras den som den var första gången.
Men det behöver inte vara så, och det är där update_post_meta kommer i spel. Faktiskt, update_post_meta kan användas mer än add_post_meta, beroende på användningsfallet.
Innan du tittar på koden, kolla vad Codex har att säga:
 
Funktionen update_post_meta () uppdaterar värdet av en befintlig metatangent (anpassat fält) för det angivna inlägget.
 
Detta kan användas istället för add_post_meta () funktionen. Det första som denna funktion kommer att göra är att se till att $ meta_key redan finns på $ post_id. Om det inte görs, heter add_post_meta ($ post_id, $ meta_key, $ meta_value) istället och resultatet returneras.
 
Fångade du det? Det kan "användas i stället för add_post_meta", vilket är användbart eftersom det betyder:
 
Om postmetadata redan existerar för en given nyckel,
 
Om du använder update_post_meta,
 
Du kommer att skriva över det föregående värdet.
 
Vid denna tidpunkt kan du ta bort den information du har i din databas, eller skapa ett nytt par nycklar och värden. Det betyder att vi kan uppdatera vår kod för att se så här ut:
Detta medför dock vissa inneboende faror med det. 
Namnlösa: Om du skriver över ett värde som du aldrig tänkt skriva över, är det värdet borta, och det kan inte återvinnas (om du inte gör mer avancerat arbete som ligger utanför ramen för denna serie).
Det finns ett valfritt slutargument för update_post_meta, dock, och det är det $ prev_value argument. Det vill säga du kan ange vilket värde du vill skriva över.
Ta till exempel fallet där du har flera poster med samma nyckel skapad med add_post_meta och du vill bara uppdatera en av dessa poster. För att uppdatera den data skulle du övergå till det värde som motsvarar den ena posten.
Vad är skillnaden?
Skillnaden mellan add_post_meta och update_post_meta kan anses vara subtil, men det beror på användningsfallet. 
Jag ska försöka bryta ner dem så enkelt som möjligt här, eftersom det kan tyckas komplicerat med tanke på de exempel vi har sett ovan är det enklare när du lägger allt ut.
 
 add_post_meta är användbar när du vill introducera en post i databasen. Om värdet redan existerar kan det nya värdet eller inte skrivas. Om du passerar Sann för $ unik parametern för funktionen, så skapas endast den första posten, och ingenting kommer att skriva över det bortsett från update_post_meta.
 
 update_post_meta kan användas istället för add_post_meta och kommer alltid att skriva över det tidigare värdet som existerade. Om du arbetar med flera poster skapade av add_post_meta, då kan du behöva ange ett tidigare värde som du vill skriva över.
 
Och det är allt. Självklart måste vi fortfarande ta itu med att hämta dokumenten från databasen och visa dem på skärmen.
Hämtar metadata
När det gäller att hämta postmetadata finns det två viktigaste saker du behöver komma ihåg:
 
Metadata kan hämtas som en sträng.
 
Metadata kan hämtas som en matris.
 
Ibland beror det på hur du lagrade originalinformationen; andra gånger bygger det på hur du vill arbeta med det.
Innan vi tittar på olika sätt kan vi hämta information, låt oss först titta på det grundläggande API-samtalet för att göra det. Specifikt talar jag om get_post_meta. Om du har följt så länge, bör förstå API vara relativt enkelt.
Funktionen accepterar tre parametrar:
 
Postens ID
 
metadata nyckeln
 
ett valfritt booleskt värde för om du vill hämta värdet som en sträng eller som en matris (där en matris är standardvärdet om inget anges)
 
Från Codex:
Hämta postmeta-fältet för ett inlägg. Kommer vara en matris om $ single är falskt. Kommer att vara värdet av metafältet om $ single är sant.
Verkar lätt nog. Så givet var den sista delen av vår källkod sitter just nu, skulle jag säga att vi kan hämta information genom att ringa till exempel get_post_meta (get_the_ID (), 'my_name');.
Koden, som den står ovan, kommer att returnera en array. 
Flera värden
När du hör frasen "flera värden" kan det vara till hjälp att tänka på en array eller någon typ av datainsamling på det programmeringsspråk du använder.
I våra exempel, tänk på när vi lagrade samma nyckel flera gånger med add_post_meta. Som en uppdatering så här var databasen såg ut:
Om jag skulle hämta informationen med nyckeln, vad skulle jag få tillbaka? Eftersom jag inte angav att jag ville ha en sträng, skulle jag få tillbaka en rad av alla poster. Detta skulle tillåta mig att iterera genom var och en av dem.
Om å andra sidan jag skulle specificera sant för att vilja få tillbaka en sträng så skulle jag bara få den första raden som skapades med hjälp av add_post_meta.
För det ändamålet, om du vill få tillbaka flera värden för en viss nyckel, så ser din kod ut så här:
Observera att jag använder var_dump för att göra det lättare att se vilken information som återkommer från WordPress i webbläsaren; Jag är dock mer av ett fan av att använda en debugger, vilket är något vi kan diskutera i ett framtida inlägg. 
Enkla värden
Låt oss nu säga att du vill få enskilda värden lagrade för ett inlägg. I det här fallet behöver du fortfarande post-ID och metadata-tangenten; Du måste dock också tillhandahålla Sann som den tredje parametern till get_post_meta.
Som nämnts ovan, om du hanterar en situation där flera rader har skapats med add_post_meta, då kommer du att få tillbaka den första raden som skapades; dock om du använder den här funktionen vid sidan av update_post_meta då får du tillbaka ett strängvärde av de data som lagrats.
Eftersom vi har täckt den tidigare men inte täckt den senare, så ser koden ut:
Och då får du tillbaka vilket värde du sparade som metavärdet när du ringer till funktionen. Det är ganska enkelt i jämförelse med att man måste arbeta med en uppsättning poster och arrayer som kan innehålla eller inte innehåller liknande information.
Radering av metadata
Den sista biten av att arbeta med post-metadata har allt att göra med att kunna radera det. Det är enkelt, men det finns bara några nyanser som vi behöver förstå för att vi ska kunna göra det effektivt.
Men först, här är definitionen från Codex:
Den här funktionen tar bort alla anpassade fält med den angivna nyckeln, eller tangent och värde, från det angivna inlägget. 
Kort, söt och till den punkten. Funktionen accepterar tre argument:
 
Postens ID
 
metatangenten
 
metavärdet
 
Meta-värdet är valfritt, men det går bra om du har arbetat med add_post_meta och vill ta bort en av de specifika poster som skapats av flera samtal till den funktionen (som vi har sett någon annanstans i hela denna handledning).
Även ringa till delete_post_meta är lika enkelt som att skicka ett post-ID, metatangenten och det valfria metavärdet, returnerar funktionen ett booleskt värde som anger om dataen togs bort eller ej.
Exempelkod för att ta bort några av de postmetadata som vi har tittat på så långt kan se ut så här:
Din implementering kan dock variera. Om du arbetar med flera bitar metadata och om du vill verifiera att det var en lyckad borttagning, kan du eventuellt lägga in koden i en villkorad.
Ett slutligt exempel på kod
Nedan hittar du en lång, dokumenterad kodbit som ska representera majoriteten av vad vi har pratat om i denna handledning. Observera att funktionerna hakar i innehållet.
Detta är bara för demonstrationsändamål så att du enkelt kan utlösa avfyrningen av dessa funktioner när du laddar en viss sida.
Vanligtvis hittar du metadatafunktioner som är associerade med andra krokar som spara inlägget och liknande operationer, men det här är ett ämne för mer avancerat arbete. Kanske täcker vi det i en annan serie senare i år.
Slutsats
Var och en av API-funktionerna finns i WordPress Codex, så om du skulle vilja hoppa framåt och läsa lite mer innan nästa artikel i serien, så är du välkommen att göra det.
Som tidigare nämnts är detta en introduktion till WordPress Post Meta API. Genom den information som tillhandahålls i Codex, i denna handledning och i källkoden som tillhandahålls, bör du kunna börja skriva ytterligare innehåll till databasen relaterad till var och en av dina inlägg.
Kom ihåg att det här är menat för demonstration eftersom vi har mer information att täcka. Specifikt måste vi granska data sanering och data validering. Även om vi har ytterligare ämnen att täcka först (till exempel användarmetadata, kommentarmetadata och så vidare) fortsätter vi vidare till mer avancerade ämnen snart.
I slutändan försöker vi lägga grunden för framtida WordPress-utvecklare att bygga från när de går framåt och arbetar med lösningar för andra, för deras byråer eller till och med för sina projekt.
Med det sagt ser jag fram emot att fortsätta denna serie. Kom ihåg om du bara har börjat, kan du kolla in min serie om hur du kommer igång med WordPress, som fokuserar på ämnen specifikt för WordPress nybörjare.
Under tiden, om du letar efter andra verktyg för att hjälpa dig att bygga upp din växande uppsättning verktyg för WordPress eller för att koden ska studera och bli mer välbevandrad i WordPress, glöm inte att se vad vi har tillgängliga i Envato Marknadsföra.
Kom ihåg att du kan fånga alla mina kurser och handledning på min profilsida, och du kan följa mig på min blogg och / eller Twitter på @tommcfarlin där jag pratar om olika mjukvaruutveckling och hur vi kan använda dem i WordPress.
Tveka inte att lämna några frågor eller kommentarer i foderet nedan, och jag vill sikta på att svara på var och en av dem.
Medel
 
Anpassade fält
 
add_post_meta
 
update_post_meta
 
get_post_meta
 
delete_post_meta
 
Post Meta Function Exempel
 
eko
 
var_dump
 



		
			
	   
	




Koda