Share
När det gäller webben, stöds nästan alla program som körs i din webbläsare av en datalagring på några typ. Vanligtvis är dessa datalager i form av en typ av databas.
Fram till nyligen byggdes de flesta applikationer ovanpå någon typ av SQL-databas, men med uppkomsten av dokumentbaserade databaser som CouchDB har andra applikationer också börjat använda andra backends.
Inte bara det, med HTML5 och webbläsare som genomför tjänster för lokalt utrymme, vi kan faktiskt börja lagra några data på klientsidan. Självklart är det inte något som du vill göra permanent, men det ger en flexibilitet och kraft som vi inte nyligen har haft.
Hur som helst, i den klassiska venen av webbapplikationer, är WordPress en databasbaserad applikation som använder en MySQL-databas för att lagra informationen.
Men den här serien handlar om att bygga applikationer ovanpå WordPress. För det ändamålet är det viktigt att förstå inte bara hur man sparar information, utan också hur man hämtar information.
När du arbetar med dataserialisering är det självklart också viktigt att ta hänsyn till att användare kan försöka införa skadliga data i databasen. Som sådan är det vårt ansvar att korrekt sanera data när du sätter in data i databasen, liksom att vi på rätt sätt släpper ut data när vi hämtar det från databasen.
I den här artikeln ska vi titta på API: erna som WordPress erbjuder för seriellisering av information och de faciliteter som finns tillgängliga för sanering av data. Då kommer vi att runda ut artikeln genom att ta en titt på hur man säkert hämtar information från databasen.
En av de främsta differentierarna mellan normala webbplatser och webbapplikationer är självklart deras förmåga att hantera data som lagras i några typ av databas Vanligtvis innebär detta också att information lagras per användarbas (men inte alltid).
Hur som helst, out of the box, erbjuder WordPress en mängd olika API-skivor som gör det enkelt att lagra och hämta data. Och kanske det trevligaste med att spara data till WordPress-databasen är att när du förstår hur ett API fungerar, har du vanligtvis en intuition om hur resten av dem arbetar.
Så med det sagt, låt oss börja när vi tittar på hur vi sparar information i WordPress-databasen.
För de som inte är bekanta, består WordPress bara av en handfull bord. I samband med denna diskussion är vi främst intresserade av att veta om följande tabeller:
Accentsconagua
wp_options. Alternativtabellen är ansvarig för att lagra informationstyper som är relaterade till inställningar, konfiguration, allt som är relaterat till inställningar som är tillämpliga på webbplatsen bredvid.wp_posts. Den här tabellen lagrar data relaterade till inlägg. Även om vi inte direkt arbetar med den här tabellen är det viktigt att förstå att det finns så att vi kan arbeta med posta metainformation.wp_postmeta. Som tidigare nämnts är denna tabell ansvarig för att hålla metadata relaterad till enskilda inlägg. Och eftersom inlägg kan representera sidor, inlägg och anpassade posttyper, så här lagrar du information som är relaterad till var och en av dina inläggstyper. Det är extremt flexibelt i den lagrade typen, så du kan verkligen ha mycket makt när det gäller hur du relaterar information till inlägg (oavsett vilken typ de definieras som).wp_comments. Den här tabellen borde vara självklart, men här lagras alla kommentarer för både inlägg, sidor och anpassade posttyper. Tycka om wp_posts, Det här är inte där vi ska skriva data direkt, men det är viktigt att förstå att det här bordet finns och att det finns en metadatatabell som vi kan komma åt när du skriver information till bordet.wp_commentmeta. Som nämnts, som wp_postmeta, Det är här där metadata om kommentarer hålls. Och givet, även om du inte nödvändigtvis arbetar med kommentarer i webbapplikationer över hela linjen, kan du sluta få en bloggkomponent till din ansökan. Och i så fall hjälper det att veta hur du kan läsa data från och skriva data till tabellen.Självklart är det bara en högkvalitativ undersökning av några av databasborden som driver WordPress. Om du vill känna till resten av informationen om det bara är för din egen uppbyggnad, var noga med att granska databasbeskrivningen.
Det borde dock vara tillräckligt bra för att få oss som standard för att läsa och skriva information till databasen.
Vid denna tidpunkt har vi tillräckligt med information om databaslagret för att börja undersöka API: erna som finns tillgängliga i WordPress-programlagret som tillåter oss att ta information som tillhandahålls antingen av oss själva och / eller av användarinmatning.
Nu är det enkelt att skriva information till var och en av de ovanstående tabellerna.
Först ska vi titta på de funktioner som är tillgängliga för läsning, skrivning och uppdatering av information i WordPress-alternativtabellerna.
WordPress tillhandahåller två specifikationer API funktioner för att skriva data till databasen. En kommer i form av att lägga till information, en kommer i form av uppdatering av information.
Om du vill lägga till information i WordPress-alternativtabellen använder du följande API-funktion.
add_option accepterar tre parametrar:
Om vi till exempel vill spara information, till exempel mitt namn, så skulle vi göra något så här:
add_option ('my-name', 'tom mcfarlin'); Om vi å andra sidan ville ta något som kommer från $ _POST samling, så kan vi göra något så här:
om (isset ($ _POST ['värde']) &&! tomt ($ _POST ['värde']) add_option ('my-value'-, $ _POST [' value ']); Uppdatering av alternativ är mycket annorlunda. Det följer samma schema och kan faktiskt användas på plats av add_option för om alternativet inte existerar kommer det att skapa det.
För att förklara punkten kommer jag inte att gå in på mycket mer information om den här funktionen. Väsentligen, update_option kommer:
Inte dåligt, rätt?
För de av er som har gjort jobb med WordPress-teman - speciellt när du använder teman Customizer - så är du troligt bekant med set_theme_mod fungera.
Denna speciella API-funktion är inte exakt relevant för att bygga webbapplikationer med WordPress; Men för att vara komplett, ville jag kunna visa alla API: er som är ansvarig för att skriva data till databasen.
Notera specifikt från Codex:
Skapar eller uppdaterar en modifieringsinställning för det aktuella temat. Tillsammans med get_theme_mod () erbjuder funktionen ibland tematillverkare ett enklare alternativ till inställnings API när det är nödvändigt att hantera grundläggande temaspecifika inställningar.
Detta förklaras tydligt för att arbeta med teman.
Ärligt talat är det inte mycket annorlunda att arbeta med posta meta än att arbeta med alternativ. Faktum är att du även kan överväga API-funktionerna för serialisering av post-metadata och kommandot metadata är nästan identiska med hur alternativen lagras i wp_options databas.
Kortfattat tar API-funktionerna in tre uppgifter:
Så, i fallet med att spara postinformation, skulle elementets ID motsvara post-ID; i fallet med kommentarerna, skulle elementets ID motsvara kommentar-id.
Och precis som det är med att spara data till alternativtabellen är det viktigt att notera att lägga till ett alternativ kommer att introducera alternativet i databasen och uppdatering av alternativet skapar alternativet om det inte existerar och skriv sedan över existerande värde i databasen.
Fall i punkt, spara information i postmetabasen:
add_post_meta (get_the_ID (), "my-post-information", "Detta är mitt favoritinlägg.");
Och säg att uppdatering av information i kommentormetabellen skulle se ut som:
update_post_meta (get_the_ID (), 'my-post-information', 'Detta är mitt favoritinlägg.');
Alternativt kan du behöva använda den globala $ post variabel om metoden inte kallas inom The Loop. Till exempel:
global $ post; add_post_meta ($ post-> ID, 'my-post-information', 'Detta är mitt favoritinlägg.');
Och för att skriva data till kommentarmetaborden följer du exakt samma format, förutom att du använder add_comment_meta och update_comment_meta.
Men nu när vi har täckt hur man sparar information i alternativtabellen, postmetabellen och metatabellen med kommentarer, hur ser vi faktiskt ut att ingen farlig information sparas i databasen?
Lätt: Datavärmning.
När det kommer till sparande data till databasen, en av de viktigaste sakerna som utvecklare måste gör sanitize all information som kommer från användaren och gå in i databasen.
Nu är det med att sanitera data att det beror på de data som du måste spara. Det finns till exempel mycket få gånger där du faktiskt vill spara markup, SQL eller andra typer av källkod i databasen.
För att förhindra detta, kommer du sannolikt att använda PHP-funktioner som strip_tags och stripslahes för att rensa upp informationen.
Till exempel:
$ clean_value = strip_tags (stripslashes ($ _POST ['value'])); add_option ('my-value' $ clean_value); Naturligtvis att vara absolut klart, det här är bara ett exempel på hur man sanerar informationen. Din implementering kan variera beroende på vilken typ av program du bygger. Poängen att dela med dig av denna information visar en av många idéer om hur man rengör information för att spara den i WordPress-databasen.
Då är det inte de enda sätten att vi kan sanera värderingar. Kom ihåg att följa upp de faciliteter som WordPress ger ut ur rutan:
sanitize_emailsanitize_file_namesanitize_html_classsanitize_keysanitize_metasanitize_mime_typesanitize_optionsanitize_sql_orderbysanitize_text_fieldsanitize_titlesanitize_title_for_querysanitize_title_with_dashessanitize_userGlöm inte bort verktyg som regelbundna uttryck vid denna tidpunkt. De är otroligt kraftfulla och matchar bara vissa strängar och vissa mönster från en samling data som kan extraheras för att spara data.
Beviljas, vi har bara pratat om hur man sparar information till WordPress-databasen.
Vi har ännu inte faktiskt slog på hur man hämtar information, än mindre hur man faktiskt kan validera informationen som kommer ut ur databasen.
Så i nästa artikel kommer vi att titta på hur fliksidan av den här artikeln - vi ska särskilt titta på hur man får information från databasen, undvik eventuella tecken som är potentiellt problematiska med att göra dem till webbläsaren och hur man hanterar det.
