Använda WordPress för webbapplikationsutveckling Tillgängliga funktioner, Del 5 - Hämta data

Nu vet du att syftet med denna serie är att visa hur WordPress kan användas som grund för webbapplikationsutveckling.

Vi började med att titta på många nivåer på många webbapplikationsdesignmönster, hur WordPress skiljer sig, och varför WordPress bör anses vara mer av en grund än en ram.

Under de senaste artiklarna har vi tittat på användarroller, behörigheter, sessionhantering, e-post och dataserialisering. Men om du ska spara data till databasen, är det bara meningsfullt att du kommer att hämta det, rätt?

Lyckligtvis har API: erna som WordPress har tillgängliga gör det väldigt enkelt att hämta information från databasen. Också om du hittade den senaste artikeln lätt att följa, borde du inte ha något problem att följa med den här artikeln eftersom många av principerna är desamma:

Vi hämtar informationen från databasen med det unika ID som vi levererade när vi lagrade informationen
Vi undviker data för att se till att det är säkert att göra till webbläsaren
Vi returnerar sedan det till den uppringande funktionen

Inget hemskt komplicerat, rätt?

Och det är egentligen inte speciellt när det gäller att utnyttja samma API (om än olika funktioner) som vi använde för att spara information till alternativtabellen och metadatabord. I den här artikeln ska vi fortsätta vår diskussion om hur man hämtar information, liksom hur man ser till att vi på rätt sätt rinner information för att säkerställa att data är säkra och rena för att kunna återges i webbläsaren.

Datainsamling

Som jag nämnde i tidigare artiklar är en av de primära skillnaderna mellan en vanlig webbplats och en webbapplikation datalagring.

Och eftersom WordPress använder sin egen databas för att hantera datalagring samt gör API tillgängliga för oss att använda för egna projekt är det uppenbarligen en webbapplikation.

Dessutom diskuterade jag bara i den senaste artikeln, att förstå hur man sparar data med de korrekta API: erna är helt enkelt, och när du har lärt dig hur du använder en, är det nästan lika lätt att använda resten av dem. Utöver det är det kanske nog lättare att lära sig att hämta data.

Det sägs att det finns några nyanser som vi måste överväga när vi går framåt när vi hämtar data. Men först ska vi granska databasen, ta en titt på hur man hämtar information, och sedan tittar vi på hur man korrekt undviker information innan den återförs till webbläsaren.

Förstå databasen

I den föregående artikeln har vi en detaljerad översikt över de tabeller som du kan skriva. Du kan läsa mer om det här i detalj i den första artikeln, men här är en sammanfattning av tabellerna som vi diskuterade:

wp_options
wp_posts
wp_postmeta
wp_comments
wp_commentmeta

Kom ihåg att du kan granska allt detta och mer på databasbeskrivningssidan i WordPress Codex.

Läser från databasen

Så med det som vår uppdatering är det dags att faktiskt titta på hur man hämtar information från databasen.

Lyckligtvis handlar det bara om att skriva information till databasen. De två huvudskillnaderna är:

Vi använder lite olika funktioner.
Det är lite arbete vi behöver göra för att se till att de data vi visar är rent formaterade för webbläsaren.

Innan vi tittar på hur man hanterar data, låt oss först titta på hur man läser alternativ från databasen.

Alternativstabellen

Minns från den senaste artikeln att det sätt på vilket vi går att skriva data till alternativtabellen är att använda add_option eller den get_option funktioner.

Kom ihåg att var och en tar in en unik nyckel som används för att identifiera värdet i databasen och värdet associerat med den nyckeln. I vårt tidigare exempel demonstrerade jag följande:

 $ clean_value = strip_tags (stripslashes ($ _POST ['value'])); add_option ('my-value' $ clean_value);

Det innebär att vi har sanitiserat och sparat information till databasen med my-värde nyckel-.

För att hämta den här informationen från databasen gör vi följande samtal:

 $ my_value = get_option ('my-value');

Det är nästan för enkelt.

Men det finns en fångst till get_option funktion: Vi kan faktiskt ange ett standardvärde att returnera om man inte redan existerar.

Låt oss till exempel säga att vi ska slå upp ett värde för nyckeln your-värde, som inte existerar.

 // $ your_value kommer faktiskt lika med FALSE $ your_value = get_option ('your-value');

I så fall kommer funktionen att återvända FALSK; Om vi anger en andra parameter, kan vi returnera ett standardvärde:

 // $ your_value kommer faktiskt att vara lika med en tom sträng $ your_value = get_option ('your-value', ');

Ännu fortfarande, inget fruktansvärt komplicerat, rätt?

Vad om temmod?

Innan vi tittar på hur man hämtar information från metatabellerna, är det värt att nämna det precis som vi sätter upp information med set_theme_mod, Vi kan också hämta temainställningar med get_theme_mod.

Direkt från WordPress Codex:

Hämtar en modifieringsinställning för det aktuella temat. Tillsammans med set_theme_mod () den här funktionen kan ibland ge temaförsättare ett enklare alternativ till inställnings API när det är nödvändigt att hantera grundläggande temaspecifika inställningar.

Återigen är detta självklart avsett för att arbeta med teman; Jag ville dock nämna det här för att vara fullständigt och för att avrunda diskussionen som startade i föregående artikel.

Annat än det här är det bara meningen att man kan visa hur alternativ kan lagras baserat på hur du kan arbeta med temat utveckling. Men det är verkligen utanför ramen för serien om applikationsutveckling.

Post Meta och Meta-tabellerna för kommentar

Nu tillbaka till att prata om databas tabeller som är mer tillämpliga på applikationsutveckling och till och med content management.

I den sista artikeln demonstrerade jag API-funktionerna som ansvarar för att skriva information till metadatabord. Specifikt skisserade jag följande funktioner:

add_post_meta
update_post_meta
add_comment_meta
update_comment_meta

På samma sätt som resten av Options API är det enkelt att hämta information från varje av dessa tabeller, förutom att det kommer med en enda "gotcha" -standard, är all information som returneras från dessa funktioner gjord i form av en array.

Det betyder att om du ringer:

 $ my_data = get_post_meta (get_the_ID (), 'my-post-information');

Därefter returneras data till dig i en array; dock om du ska passera SANN till funktionen när du ringer det, skickas data till dig i en sträng:

 $ my_data = get_post_meta (get_the_ID (), 'my-post-information', SANT);

Det är naturligtvis ingen höger sätt att göra detta. I stället beror det på informationen du vill ha tillbaka och / eller hur du vill att den returneras. Eftersom det inte finns något enda sätt att göra detta måste du bedöma din användning baserat på din applikations implementering.

Escaping Data

Nu, precis som vi behövde sanera information innan vi faktiskt skrev den till databasen, är det också viktigt att vi på rätt sätt undviker data efter att ha hämtat den från databasen, men innan den görs till webbläsaren.

Att slippa data är den process genom vilken vi ser till att de data som vi ska göra till användaren är säkra. Det är i grunden sanitering gjord för data; Det är dock klart efter data har hämtats från databasen istället för gjort innan den skrivs till databasen.

När det gäller att acceptera data finns det fyra huvudfunktioner som vi borde vara medvetna om:

esc_html används för att flytta HTML-block.
esc_url är när du behöver städa webbadresser som skrivs ut till textelement, attributnoder eller någon annanstans i markeringen.
esc_js används för att flytta textsträngar som används för att eko JavaScript - främst inline JavaScript.
esc_attr kodar flera tecken som kan mangla utmatningen om den inte hanteras ordentligt.

Det fina med detta är att de i allmänhet arbetar exakt på samma sätt, och sättet att bestämma vilken du behöver använda är relativt lätt:

Om du gör inline JavaScript, använd sedan esc_js,
Om du gör ett attribut för ett element, använd sedan esc_attr.

Lätt nog, höger?

Så, till exempel, låt oss säga att du ville fly en attribut av ett inmatningsfält som kommer från $ _POST samling. För att göra detta skulle du skriva följande kod:

 '; ?>

Det är små saker som detta kan gå långt för att se till att din ansökan är robust i både dataserialisering och datainsamling.

Och nu vidare till omskrivning av webbadressen

Vi har täckt mycket i denna serie, men det finns mer att gå.

Fall i sak: En av de trevligaste egenskaperna hos några av de mer populära webbapplikationsramarna är hur de hanterar webbadresser. Kort sagt, de tillhandahåller rena webbadresser som gör det verkligen lätt att förstå de olika åtgärder som finns tillgängliga för de datamodeller som används i hela applikationen.

Out of the Box erbjuder WordPress inte de renaste eller tydligaste webbadresserna; dock detta kan modifieras genom användning av omskrivnings API. I nästa artikel kommer vi att titta på exakt hur vi kan införa anpassade regler för rena webbadresser som liknar något du skulle se i en webbapplikation snarare än i ett innehållshanteringssystem eller en blogg.

Koda