I den föregående artikeln diskuterade vi att arbeta med post-metadata i WordPress med hjälp av de tillhandahållna API-erna. Vi täckte också en mängd olika verktyg, säkerhetssidorna och vad som skulle krävas för att skapa miljön för att arbeta med den kod som skulle ges under hela handledningen.
Om du inte har läst den artikeln rekommenderar jag starkt att du granskar det, inte bara för att det täcker hur man arbetar med postmetadata, utan också för att det slår på några viktiga ämnen som är relevanta för resten av artiklarna i denna serie (och det hänvisar till några som kommer senare i år).
Anta att du är fast och redo att lära dig om en annan metadataprogram, sedan låt oss börja med WordPress User Meta API.
Minns från tidigare i denna serie definierar WordPress metadata på följande sätt:
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.
Eftersom vi fortsätter att arbeta med de olika metadataprogrammen, kommer du att upptäcka att denna definition gäller, oavsett vilket API som undersöks.
Det fina är att när du har tagit hand om att ta itu med ett metadataprogram, har du en allmän uppfattning om hur varje av de relaterade API: erna kommer att fungera. Visst kan det finnas nyanser här och där, men den allmänna funktionaliteten blir densamma.
När vi tittat på Metaprogrammet för WordPress Post Meta, granskade vi och använde följande funktioner:
add_post_meta
update_post_meta
get_post_meta
delete_post_meta
Ja, det finns idiosynkraser bland dem, särskilt när det gäller hur add_post_meta
och update_post_meta
arbete och olika sätt get_post_meta
och delete_post_meta
arbete, och API: erna som vi ska undersöka kommer att fungera mycket på samma sätt.
För resten av den här artikeln antar jag att du har en lokal webbserver, tillgång till en databasfront, en IDE, och att du är bekväm med att arbeta med filen tutsplus-metadata.php
.
Om du är nyfiken använder jag följande verktyg:
Observera att användarmetadata lagras i wp_usermeta
databas tabell, så vi kommer att referera det i alla skärmdumpar av databasen. Till skillnad från den ursprungliga postdatadatabellen finns det faktiskt vissa data som redan finns i metadatabordet för användaren.
Detta beror på några av de data som lagras på användarprofilens skärm:
Ändå kommer API: n att tillåta oss att skriva vår egen information till bordet. Så med allt det sagt, låt oss gå vidare och ta en titt på hur man arbetar med funktionerna som tillhandahålls av WordPress.
Observera att genom alla de givna exemplen kommer vi att passera 1
för den första parametern till API-funktionerna, eftersom den första användaren alltid är webbplatsadministratören. Detta är i allmänhet garanterat att vara närvarande i en viss installation.
Du kan hitta en referens till add_user_meta
funktion i Codex. Definitionen av funktionen är så kortfattad som möjligt:
Lägg till metadata i en användares post.
Hur fördelaktigt är det här? Det vill säga om du skulle arbeta på ett plugin eller en webbapplikation som är byggd på WordPress och du vill utvidga vad en person kan associera med sin profil, så är det här ett sätt att göra det.
Det kan vara något så enkelt som att tillhandahålla en användares profil på ett givet socialt nätverk, eller det kan vara något mer avancerat där du kan associera användaren med data i en annan tabell, en mängd information eller något annat.
Oavsett, det här är hur du går om att göra det. Men här är det: Kom ihåg hur du skriver metadata för ett inlägg med hjälp av add_post_meta
funktionen resulterade i att flera rader kan skrivas med samma nyckel?
Samma sak är möjligt med add_user_meta
. API-funktionen accepterar emellertid en valfri fjärde parameter om huruvida det värde som infogas ska vara unikt eller inte.
Så först, ta en titt på koden för att lägga till några användarmetadata, och låt oss göra det genom att inte ange att det borde vara unikt.
Koden för att göra detta kommer att se ut så här:
Observera att vi använder samma strategi som tidigare anställd i serien:
- Vi krokar in i
innehållet
.- Vi kontrollerar för att se om vi är på Hej världen posta.
- Om så är fallet lägger vi till metadata för användaren.
- Vi återvänder
$ innehåll
till WordPress.Med denna kod på plats och med Hej världen posta laddad i din webbläsare, uppdatera sidan några gånger.
När det är gjort kommer den resulterande databastabellen att se ut så här:
Som jag sa, liknar det väldigt hur metadata-API: n utförs.
Unika värden
Använd din databasfront-end genom att radera raderna som skapades eller gärna välja en ny nyckel (kanske något liknande
instagram_username
). Jag ska radera raderna.För det andra kommer jag också att skapa en andra funktion istället för att ändra ovanstående så att jag kan erbjuda fullständig källkod i slutet av handledningen, så läs följande kod noga:
Först ge ett unikt värde för metavärdet (eller det tredje argumentet) i funktionssamtalet. Uppdatera sidan några gånger, och ta en titt på databasen. Det borde se ut så här:
Lägg märke till vad som är intressant? Det finns fortfarande flera värden, men de är alla samma.
Försök nu byta meta-värde argumentet ett par gånger, och ta en titt på databasen och du bör se något så här:
Lägg märke till skillnaden? Exakt-det finns inte en. Det beror på att vi sa att det bara kunde vara en unik nyckel. Så det betyder inte nödvändigtvis att endast en post skapas. Det betyder att flera poster skapas när funktionen heter, men den kommer alltid att använda det första värdet som det lagras som är associerat med nämnda nyckel.
Om du vill kan du fortsätta och radera raderna som vi just skapat eftersom det ger en bra segue till nästa funktion.
Uppdatering av användar Meta
På liknande sätt som Post Meta API fungerar fungerar uppdateringsfunktionen på följande sätt:
Uppdatera användarnätfält baserat på användar-ID. Använd parametern $ prev_value för att skilja mellan metafält med samma nyckel och användarnamn. Om metafältet för användaren inte finns kommer det att läggas till.När du arbetar med den här funktionen hjälper det att tänka på detta i två scenarier:
- när tidigare metadata har lagts till med hjälp av
add_user_meta
funktionen och det finns flera poster med samma information- när ingen metadata har lagts till och vi lägger till en ny post och vill att den ska vara unik
I det första fallet bidrar det till att ge
$ prev_value
för att du säger WordPress vilket värde du vill rikta och uppdatera.När vi har lagt till metadata
Tänk på att vår databas ser ut som tidigare i handledningen:
Och vi vill uppdatera de dokument som har det tidigare värdet av
https://twitter.com/tommcfarlin/
. För att göra det skulle vi uppdatera koden som ser ut så här.Och då skulle uppdateringen till databasen se ut så här:
Observera att dessa uppdateringar Allt värden som är associerade med denna metatangent. Det är förstås bara en funktion av funktionen.
När du lägger till nya metadata
I det andra fallet behöver du inte ange ett tidigare värde eftersom du kommer att lägga till information för första gången.
För att klargöra kan du använda
update_user_meta
funktion när du vill lägga till information i databasen. Det behöver inte existera innan du använder det.Det här är användbart när du vill lägga till en enda, unik post som ännu inte har lagts till i databasen. Att använda funktionen är enkel. Låt oss säga att vi vill spara användarens syskon namn.
I det här fallet skulle vi göra det här:
Och detta resulterar i att följande post läggs in i databasen:
Om du uppdaterar sidan flera gånger och sedan kontrollerar databas tabellen kommer du märka att endast en enda förekomst av värdet är skrivet mot flera värden som kommer när du använder
add_user_meta
.Då skulle vi någonsin vilja ändra det värdet, vi skulle uppdatera metavärdet associerat med den angivna metatangenten och det skulle uppdatera den enskilda posten.
Hämtar användar Meta
När det gäller att hämta användarmetadata har vi
get_user_meta
fungera. Vid denna punkt bör det vara tydligt att de förväntade parametrarna kommer att vara användar-ID och metatangenten.Men vad med meta-värdet?
Kom ihåg när vi hämtar information behöver vi bara användar-ID och metatangent eftersom det är identifieringsinformationen för ett visst värde.
Men vad händer om utvecklaren har flera poster för en enda nyckel? Mer specifikt vad om de har använt
add_user_meta
funktion som vi har gjort ovan och har flera poster?Det här är den valfria fjärde parametern som kommer till spel: ett booleskt värde som vi anger om vi vill hämta ett enda värde eller en mängd värden. Standardvärdet (det som passerat om det inte anges) är
falsk
så vi får alltid tillbaka en array om vi inte anger något annat.Hämtar alla poster
Låt oss anta att vi arbetar från samma uppsättning data från tidigare i handledningen. Det vill säga vi har flera poster för användarens Twitter-konto. Kom ihåg att databasen såg ut så här:
För att få all denna information ur databasen och visas på skärmen använder vi följande kod:
Förutsatt att allt gick bra, så borde du se något så här på toppen av din Hej världen posta:
[0] => sträng (32) "https://twitter.com/tommcfarlin/" [1] => sträng (32) "https://twitter.com/tommcfarlin/" [2] => sträng 32) "https://twitter.com/tommcfarlin/" [3] => sträng (32) "https://twitter.com/tommcfarlin/"Om inte, dubbelkollera samtalet till var_dump som du har gjort, och se till att informationen finns i databasen redo att hämtas.
Hämta en enskild post
Om du vill hämta en enskild post, kan du passera sann som den sista parametern till funktionen. Detta hämtar den första posten som skapades i strängformat.
Och resultatet av denna kod kommer att skriva ut detta längst upp på sidan Hej världen inlägg som vi har arbetat med:
https://twitter.com/tommcfarlin/Observera att om du använder
update_user_meta
och du inte specificeraSann
Som den sista parametern kommer du att få ett index med en index som skickas tillbaka till dig.array (1) [0] => sträng (32) "https://twitter.com/tommcfarlin/"Således, om du letar efter en sträng representation av information, alltid passera
Sann
.Radera användarmeta
Det sista som vi behöver täcka är hur man faktiskt tar bort data som vi har skrivit till databasen. Om du har följt med den här serien hittills, då utvecklar du sannolikt en slags intuition om hur den här funktionen kommer att fungera.
Från den medföljande Codex-sidan:
Ta bort metadata matchande kriterier från en användare. Du kan matcha baserat på nyckeln, eller tangent och värde. Att ta bort baserat på nyckel och värde kommer att hålla bort från att ta bort dubbla metadata med samma nyckel. Det gör det också möjligt att ta bort alla metadata matchande nycklar, om det behövs.Observera att den här funktionen är utformad för att fungera om det finns flera poster som existerar och du vill radera dem alla, eller om du har en enda post som finns och du vill ta bort den.
Radering av flera poster
Först ska vi titta på hur du använder den här funktionen när det finns flera poster med samma information. Låt oss anta att databasen ser något liknande ut i det här exemplet:
Här har vi flera poster. För att radera poster med samma nyckel, använder vi ett enda samtal till
delete_user_meta
funktionen och skicka användar-ID och metatangenten.Och om du uppdaterar informationen i databas tabellen noterar du att alla poster har raderats:
Även om det här är en enkel funktion att använda, är det viktigt att komma ihåg att det kan ta bort flera rader i ett enda samtal, så använd den noggrant.
En enda post
Om du däremot har en enda post att radera, behöver du tre bitar av information:
- användarens ID
- metatangenten
- metavärdet
Med alla tre värden kan du ta bort en enskild post. Det är tydligt att det ger mycket mer precision än den tidigare användningen av denna funktion.
Så, i vårt exempel, låt oss säga att vi har två poster, vilka båda har
twitter_account
metatangent. Varje nyckel har följande värde:
https://twitter.com/tommcfarlin
https://twitter.com/pressware
I vårt exempel är vi bara intresserade av att ta bort det andra värdet. För att göra det använder vi följande kod:
Och då om du uppdaterar din databas bör du se följande (eller något liknande):
Det är trevligt när ett API fungerar exakt som du förväntar dig.
Den fullständiga källkoden
Här är en kopia av all källkod som vi behandlade i den här artikeln. Observera att
add_action
Samtal har kommenterats, eftersom du behöver avkänna dem baserat på vad du vill göra när du experimenterar med koden.Dessutom är du välkommen att lägga till den i filen som vi skapade i föregående handledning. Det var vad jag gjorde när jag arbetade med exemplen; Men du kanske vill vara försiktig när du arbetar på filen så att det är korrekt
add_action
Samtal är inställda utifrån vad du vill göra.Slutsats
Som tidigare nämnts i artikeln kan du granska alla funktionerna i WordPress Codex, som alltid ska vara ett klick bort för en WordPress-utvecklare.
I den sista artikeln i den här serien ska vi titta på hur man hanterar kommentars metadata. Med tanke på vad vi hittills har lärt oss, borde det vara något som är relativt lätt att hämta.
Naturligtvis lämnar vi oss fortfarande med metadata relaterade till taxonomier. På grund av taxonomins, villkoren och API: erna granskar vi dem i uppföljningsserier.
För närvarande fortsätt att experimentera med koden som har tillhandahållits i den här artikeln. Kom ihåg att det endast är avsett för demonstration och inte får köras i en produktionsmiljö.
Under hela denna serie 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 deras arbetsgivare, deras kunder eller för sina egna 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.
Slutligen kan du se alla mina kurser och handledning på min profilsida, och du kan läsa mer artiklar om WordPress och WordPress-utveckling på min blogg. Gärna följa med mig på Twitter också på @ tommcfarlin där jag pratar om olika mjukvaruutvecklingsmetoder 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