Använda WordPress för webbapplikationsutveckling Anpassade databasfrågor

Under hela serien har vi tittat på de olika anläggningarna som gör det möjligt att behandla WordPress som en grund för webbapplikationsutveckling.

Hittills har vi täckt mycket av marken:

  • Vi har pratat om hur WordPress är mer en grund snarare än en ram.
  • Vi har diskuterat arten av det Event-Driven Design Pattern.
  • Det har diskuterats E-post, Användarhantering, Spara data, Hämta data
  • … och mer.

I de senaste artiklarna har vi pratat en titt på hur man hanterar frågor mot WordPress-databasen genom att använda WP_Query och WP_User_Query.

I den här artikeln kommer vi att runda ut diskussionen genom att prata om hur vi kan köra direkta SQL-frågor mot databasen.

Direktfrågor mot databasen

Specifikt kommer vi att titta på standardoperationerna för VÄLJ, UPPDATERING, FÖRA IN, RADERA, och mer, vi tar en titt på exempel på var och en. Då ska vi slutföra vår diskussion genom att prata om parametrering så att vi kan skriva säkra frågor.

Med det sagt, låt oss titta på den tillgängliga verksamheten, exempel på var och hur vi kan införliva dem i vårt arbete.

VÄLJ

För er som är nya för att skriva SQL-frågor, är det viktigt att förstå villkoren för var och en av de typer av frågor som vi gör för att bli verkställande. Först talar vi om VÄLJ påstående.

Enkelt uttryckt, VÄLJ uttalanden är ansvariga för hämtning data från databasen så att vi kan läsa informationen.

Ett av de mest grundläggande exemplen som vi kan ge är hur man hämtar en posttitel från wp_posts tabell:

 // Globalisera alltid $ wpdb global $ wpdb; // Välj en enda variabel - Posttiteln för det första inlägget $ title = $ wpdb-> get_var ("VÄLJ posttitel FROM $ wpdb-> inlägg WHERE ID = 1;"); echo $ title;

Beviljas, det förutsätter att du är bekant med databasschemat, men vi har täckt detta i tidigare artiklar.

Naturligtvis, inom ramen för WordPress, kan vi inte bara definiera en fråga och få den att köras, istället måste vi se till att vi överför den till rätt API. Stiga på $ wpdb.

Direkt från Codex:

WordPress tillhandahåller en global variabel, $ wpdb, vilket är en instans av klassen som redan är inställd för att prata med WordPress-databasen.

$ Wpdb-objektet kan användas för att läsa data från vilken tabell som helst i WordPress-databasen (t.ex. anpassade plugin-tabeller), inte bara de standardtabeller som WordPress skapar.

Så det finns ett tillvägagångssätt här som vi ännu inte har stött på i vårt arbete fram till denna punkt: The $ wpdb global variabel är global vilket innebär att när som helst som vi vill komma åt det, måste vi se till att vi prefixar global nyckelord före det.

 global $ wpdb; // Välj en hel rad information från det första inlägget $ info = $ wpdb-> get_row ("VÄLJ * FRÅN $ wpdb-> inlägg WHERE ID = 1;"); print_r ($ info); // Få alla titlar på inlägg (och sidor och anpassade posttyper) som har ett ID mindre än 10 $ titlar = $ wpdb-> get_col ("VÄLJ posttitel FROM $ wpdb-> inlägg där ID < 10;" ); print_r( $titles ); // Retrieve a generic result set of post IDs and post titles from the posts table where posts have an ID less than 10 $results = $wpdb->get_results ("VÄLJ ID, post_title FROM $ wpdb-> inlägg WHERE ID < 10;" ); print_r( $results );

Om det här är nytt för dig, inga bekymmer - vi ska titta på hur du gör det här i den här artikeln.

De som är mer avancerade är mer än kapabla att hantera mer komplexa frågor.

Observera också att alla frågor ställs in mellan dubbla citattecken. Det här är så att vi kan använda $ wpdb variabel inom strängen och behöver inte utföra någon strängkonsatation som kan komplicera hur koden ser ut.

Ta noggrant varsel om vilken typ av frågor som returneras enskilda variabler, och vilken typ av frågor returnerar samlingar, eftersom det här kommer att diktera hur du kan hantera informationen när den hämtas. Kanske du echo den tillbaka till sidan, eller kanske du slutar slingra igenom den.

FÖRA IN

Självklart är det bara att hämta information ett sätt på vilket data hanteras i WordPress-databasen. För att kunna hämta någonting måste du ha data som faktiskt lagras i databas tabellerna.

Även om WordPress API gör det relativt enkelt att göra från ett programperspektiv (särskilt genom att använda några av de API som vi just har granskat i de senaste två artiklarna), kan det finnas tider där du skriver egna frågor för att infoga information är bra jobbat.

Observera att i alla exemplen som vi tittar på tittar vi på några relativt enkla frågor. Detta är gjort så att de som aldrig skrivit SQL i WordPress-sammanhanget (eller i något sammanhang, verkligen) enkelt kan följa med.

Att sätta in data är något som måste göras med omtanke, inte bara för att du skriver bord till en (eller flera) tabeller, men för att du vill se till att du inte kommer att kollidera med data som redan finns.

Även om databaser kan ha begränsningar som gör att du kan göra det, tycker jag att det alltid är säkert att vidta förebyggande åtgärder på kodnivån, till exempel, kontrollera om det finns något innan du lägger in det. På så sätt kan du utföra en uppdatering snarare än ett inlägg (som vi tar en titt på i korthet).

Men om du är säker på att du är redo att infoga information, är här några exempel för att komma igång.

 global $ wpdb; // Skriv in ett publicerat inlägg med en rubrik och innehåll med det godtyckliga post-ID: n 9999 $ wpdb-> insert ('wp_posts', array ('id' => 9999, 'post_title' => 'Inlägg ',' post_status '=>' publicera ',' post_content '=>' Exempel på innehåll för ett inlägg som läggs in via direktfråga. '), array ('% d ','% s ​​','% s ​​','% s '));

Precis som med VÄLJ frågor, dessa exempel är menade att vara grundbegränsare bör kunna hämta dem enkelt, avancerade användare borde förstå hur man tar detta till nästa nivå med mycket liten ansträngning.

UPPDATERING

Som nämnts i det sista avsnittet kan det finnas tider där vi vill uppdatera data istället för att infoga nya data. I sådana fall söker vi faktiskt efter UPPDATERING operation då detta tillåter oss att ta en befintlig rad information, uppdatera data och spara den sedan i databasen.

I huvudsak är detta idealiskt i fall där existerande information måste tweaked.

 global $ wpdb; // Uppdatera titeln och postinnehållet i posthyllestyrdhatten har ett ID på 9999 $ wpdb-> update ('wp_posts', array ('post_title' => 'Infogad post (uppdaterad)', 'post_content' => 'Exempel på innehåll för ett inlägg * uppdaterat * via direktfråga.'), Array ('id' => 9999), array ('% d', '% s', '% s'), array ));

Självklart leder det oss till ytterligare en operation - om vi inte vill läsa information, infoga information eller uppdatera information, vad ska vi göra för att göra?

RADERA

De RADERA Operationen gör det möjligt för oss att ta bort data från databasen direkt utan att använda någon av WordPress API. Kraften i att göra detta är att du kan passera de vanliga funktionerna och villkor som kan krävas för att ta bort information.

Nackdelen är emellertid att det kan vara farligt att direkt ta bort information från databasen, för utan korrekt kontroll och defensiv kodning, så när data är borta är den borta för gott.

 global $ wpdb; // Radera posten från databasen där ID-kolumnen har värdet 9999 $ wpdb-> delete ('wp_posts', array ('ID' => 9999), array ('% d'));

När vi har tittat på dessa operationer har vi sett hur vi kan arbeta med databasen direkt genom att gå över eller undvika API: n (beroende på hur du vill titta på det), men det sista vi behöver ta en titta på är exakt hur man ser till att vi skriver de mest säkra frågorna som vi eventuellt kan.

Parametrisering

Fram till den här tiden har vi överfört data till inline-frågorna. Det innebär att varje gång vi har lagt in eller uppdaterat data i databasen har vi gjort det utan att ordentligt undkomma det.

Om vi ​​inte hanterar dessa typer av förhållanden med omsorg, lämnar den dörren öppen för att fler skadliga användare kan utnyttja vår kod och eventuellt injicera skadliga data i databas tabellerna.

Så hur vi förhindrar att detta händer? Kort sagt, vi utnyttjar förbereda funktion som finns på $ wpdb objekt, och vi använder platsinnehavare för att representera vår information. Naturligtvis är det enklaste sättet för oss att förstå detta att se det i aktion, så låt oss ta en titt på några exempel.

 global $ wpdb; $ id = 10000; $ title = "En parametrisk post"; $ content = "Det här inlägget har infogats med en parameterad fråga."; $ parametris_result = $ wpdb-> fråga ($ wpdb-> förbereda ("INSERT INTO $ wpdb-> inlägg (id, post_title, post_content) värden (% d,% s,% s)", array ($ id, $ title , $ innehåll)));

Nu om du har följt noga med resten av informationen i den här artikeln har du redan sett liknande substitutionsfunktioner som % s, % d, och så vidare representerar en sträng respektive ett tal.

De olika, i det här fallet, är att vi inte bara lagrar våra värden i variabler innan vi skickar dem till frågan, men vi skickar också hela frågan till förbereda funktion som kommer att ta frågan och utföra korrekt SQL-escaping på data för att säkerställa att vi har korrekt förberedda, säkra frågor.

WordPress Codex har en djupartikel om datavalidering som bör läsas av alla som arbetar med plugins, teman och applikationer. Faktum är att jag rekommenderar att du läser detta efter den här posten som den kommer att beskriva på den information som vi har diskuterat här.

Strax

Denna artikel är avsedd att fungera som en primer för att styra WordPress-databasfrågor - det är inte på något sätt menat att vara en uttömmande guide; dock genom att bekanta dig med informationen som finns här, läser resten av materialet i Codex och utövar dessa frågor i ditt eget arbete, du kommer vidareutveckla dina kunskaper när det gäller att arbeta med den underliggande databasen.

I nästa artikel kommer vi att paketera upp den här serien genom att se över allt vi har pratat om genom de senaste artiklarna, samt hur vi går vidare med framtida projekt eller applikationer - nu när vi har tittat på allt som WordPress har att erbjuda.