WordPress Metadata Association: Relaterande enheter

Vid det här laget har vi täckt hur man skapar enheterna i pluginet (vilket, som vi har sagt, bara är ett fint ord för en annan konkret idé). Vi har nämligen en användare och en anpassad inläggstyp, eller en bok. Och det är här vi börjar ta de två separata enheterna och kombinera och arbeta med vad vi kallar WordPress-metadataförening.

Men innan du gör det är det viktigt att förstå de två typer av metadata som vi kommer att arbeta med och de två sätten (eller tre sätt, beroende på hur du ser på det) hur vi kan associera metadata.

Som med resten av inläggen i serien, är detta inte menat att vara en djupdykning i att förstå var och en av tabellerna eller en djupdykning i var och en av API-funktionerna. Istället kommer vi att undersöka vad som finns tillgängligt, använda dem och lämna mer detaljerade detaljer för framtida inlägg (eller kanske diskussioner i kommentarerna).

WordPress Metadata Association

Metadata är inte exklusivt för WordPress. Du vet förmodligen detta. Och det definieras ofta som :

Information om information eller data om data.

Och det är ett bra sätt att uttrycka det. WordPress erbjuder några olika databastabeller som vi kan använda för att ge information om vissa andra typer av enheter inom WordPress. Vi kommer att använda ett par av dessa senare i det här inlägget, men det räcker med att säga att WordPress erbjuder :

• kommentar metadata,
• posta metadata,
• term metadata,
• och användarmetadata

Och allt detta är tillgängligt direkt.

En av WordPress-metadatatabellerna.

API:erna för var och en av dessa är konsekventa, vilket också är trevligt. Men återigen, vi kommer bara att bekymra oss om ett par av dessa under resten av det här inlägget.

1 Metadatatabellerna

För vårt exempel kommer vi att använda en, eller båda, av följande två tabeller:

1. wp_postmeta
2. wp_usermeta

Visst, i din installation kan de ha ett annat prefix, men suffixet är detsamma, och du förstår idén.

För det andra kommer vi att använda de relaterade API-funktionerna för att associera våra metadata. Vi kommer att titta på dessa i kod när vi associerar data mellan vår användare och den anpassade posttypen (eller vår författare och våra böcker om du vill använda den mer exakta terminologin).

Okej då. Hela den här första delen av inlägget lägger bara lite grund för vilka delar av den underliggande WordPress-infrastrukturen vi kommer att använda. Med allt detta sagt, låt oss titta på hur vi programmässigt kan förvandla den här saken till något lite mer användbart.

2 Associera metadata

Idén bakom WordPress metadataassociation låter mer komplicerad än den är. Tänk på det så här:

• Med tanke på två tabeller, hur kan vi dela information mellan två enheter som låter den ena veta om den andra?

Till exempel, givet en användare, hur kan vi låta användarens metadata veta om postmetadata. Eller, för att vända på det, hur kan vi låta inläggsmetadata veta något om relaterad användarmetadata?

På hög nivå är detta verkligen vad vi gör: vi låter den ena enheten veta att den andra existerar och vi relaterar den till den andra. Eller så kan det gå åt andra hållet. Beroende på din implementering kan den ena vara mer fördelaktig än den andra.

1 enkelriktad

När vi pratar om att skapa envägs-WordPress-associationer talar vi vanligtvis om tanken att endast en enhet är medveten om den andra. Det betyder att användaren kanske bara känner till inlägget.

Så vi kan ställa in efter att ett inlägg har skapats, till exempel att användaren i fråga är medveten om inlägget som just skapades :

<?php

// Using post title as the value, but it's just an example.
add_user_meta( $user_id, $post_id, $post_title );

Eller kanske betyder det att inlägget är medvetet om användaren:

<?php

// User user email address a value but just an example.
add_post_meta( $post_id, $user_id, $email_address );

Men hur man än ser på det så går föreningen bara åt ett håll.

Och även om förhållandet går åt ett håll, behöver det inte vara så. Det vill säga att båda enheterna kan vara medvetna om varandra.

2 Tvåvägs

Eftersom metadata-API:erna är så lätta och konsekventa att arbeta med är det inte svårt att arbeta med dem. Var och en av dessa kräver vanligtvis minst två av följande:

1. ett slags ID som metadata är relaterad till,
2. en meta-nyckel som kan användas för att slå upp informationen,
3. ett värde som lagrar information som är kopplad till ID:t och inlägget.

Angående vilket ID och vilken nyckel du väljer beror ofta på din implementering, som vi har sett.

Hittills har vi tittat på hur man skapar en enkelriktad association. En tvåvägsförening är inte annorlunda. Det är bara snarare än att göra en enhet medveten om den andra, vi gör båda enheterna medvetna om den andra:

<?php

/**
 * Using this association will give you the ability to query for information 
 * both on posts and users and then work with the data accordingly.
 */
add_user_meta( $user_id, $post_id, $post_title );
add_post_meta( $post_id, $user_id, $email_address );

Men det här är inte ett beslut som bör fattas bara för sakens skull. Istället är det värt att fundera igenom lite av anledningen till att du kanske vill välja det ena eller det andra.

Att tänka igenom problemet

När det gäller att lösa sådana här problem, finns det ingen definitiv lösning i termer av "du borde definitivt göra det [på det här sättet]" vilket sätt det än kan vara. Istället måste du ställa dig själv frågor som "vad gör för enklaste sättet att hantera denna data?"

Till exempel, om du främst är intresserad av användarhantering, kanske allt du behöver är att ha användarmetadata medveten om vilken enhet den är relaterad till. På så sätt, när användaren raderas, ser du också till att slå upp entiteterna som är relaterade till den via användarmetadatatabellen och radera dem också.

På samma sätt skulle kanske samma funktionalitet gå åt båda hållen. Det vill säga, precis som du vill försäkra dig om att när en användare raderas, att hans eller hennes inlägg också raderas, kan du också vilja att användaren tas bort (eller modifieras) när ett av hans/hennes inlägg tas bort. Och om så är fallet, så tillåter tvåvägsföreningen det.

Eftersom du har ID för ett givet inlägg och ID för en given användare samt meta-nycklarna du har angett, är nästan alla typer av frågor som du kan avbilda antingen via WordPress metadata API eller WP_Query eller till och med via WP_User_Query möjliga .

Slutet

I slutändan hoppas jag att den här serien har gett lite insikt om hur man inte bara skapar WordPress-metadataassociationer utan också hur man tänker abstrakt om begrepp inom WordPress när det gäller att skapa implementeringar på högre nivåer i dina plugins och dina webbapplikationer.

För den som är intresserad överväger jag att släppa den här serien som en liten resurs i PDF-format tillsammans med ett fungerande plugin att studera. Om det här är något du är intresserad av att göra, vänligen registrera dig för e-postlistan här, så kommer jag att meddela dig när det är klart; annars, använd informationen i serien för att gå vidare och skapa något värt

Vill ha mer?

Serie inlägg

1. WordPress Metadata Association: Hur man gör det
2. Skapa WordPress-användare programmerat
3. WordPress-inläggstyper: en abstraktion för enheter
4. WordPress Metadata Association: Relaterande enheter