Använda WordPress för webbapplikationsutveckling Funktioner Anpassade sökningar med WP_Query

Vi har tittat på hur WordPress kan användas som grund för applikationsutveckling, men en av de saker som vi ännu inte har att täcka till att modernaste ramar erbjuder är hur man frågar databasen för att hämta resultat för en viss vy.

Specifikt har vi inte pratat om hur man får information ur databasen och sätter in den i våra sidor.

Om du är bekant med andra ramar, är du troligen bekant med ett objektrelationssystem (ORM).

För dem som inte är bekant med en ORM är det i själva verket ett program som sitter mellan applikationen och databasen och låter oss hämta rader och kolumner som objekt, behandla dem som sådana och sedan serialisera sina ändringar tillbaka till databasen.

Det är riktigt coola saker. Men WordPress gör det inte erbjuda den flexibiliteten.

Istället finns det en uppsättning API som den erbjuder som gör att vi kan göra ändringar i databasen. Det finns ett antal API: er som vi kan använda, varav vi kommer att undersöka över den här sista uppsättningen artiklar.

Först ska vi ta en titt på WP_Query. Då tar vi en titt på WP_User_Query, följt av $ wpdb objekt som är tillgängligt som en global i WordPress.

Men mer på det senare. Nu vidare till WP_Query.

Fråga WordPress-databasen

Innan vi faktiskt börjar prata om att fråga WordPress-databasen tycker jag att det är viktigt att beskriva exakt vad det betyder, varför det är viktigt och vad det innebär.

Om inget annat är detta menat att nivåuppställda förväntningar för läsare oavsett din erfarenhetsnivå.

1. Vad betyder detta?

Att fråga WordPress-databasen representerar exakt vad du kan förvänta dig: hämta information från databasen som WordPress körs på.

Det är inget hemskt komplicerat. Men där är flera olika sätt att göra det, och det är viktigt att veta hur man gör det och vad man ska undvika.

Generellt sett finns det tre API: er som är tillgängliga och rekommenderade för oss att använda, och ett fåtal som är tillgängliga, men är inte rekommenderas för användning.

I denna serie artiklar kommer vi att täcka allt detta.

2. Varför är detta viktigt?

Om inget annat är detta viktigt så att vi förstår de rätta sätten att hämta och lagra information till databasen på säkraste och säkraste sätt.

Kom ihåg: i programmering, bara för att något fungerar betyder inte att det är det bästa sättet att göra det.

För det ändamålet kommer vi att titta på de rekommenderade sätten som WordPress tillhandahåller för att hämta och spara data direkt från och till databasen.

När allt kommer omkring vill vi se till att vi inte bara bygger robusta applikationer utan även säkra och effektiva applikationer.

3. Vad innebär detta??

Som med de flesta saker innebär det att lära ett API. Det är åtminstone det som gäller två av frågetyperna.

För den slutliga artikeln kräver det att du vet, eller har en vilja att lära, SQL (som WordPress gör tillåter dig att skriva råa frågor mot databasen). Men mer på det senare.

För närvarande fokuserar vi helt enkelt på API: erna, tillgängliga parametrar och hur / när de ska användas i vårt arbete.

Introducerar WP_Query

Även om du kan läsa allt om WP_Query i WordPress Codex tror jag att det är värt att destillera några av de finaste punkterna här i den här artikeln, speciellt om du är ny på WordPress, eller ser allvarligt på att skriva applikationer med WordPress.

Codex definierar WP_Query som följande:

WP_Query är en klass ... som handlar om invecklingen av en inlägg (eller sidor) förfrågan på en WordPress-blogg. Wp-blog-header.php ... ger informationen $ wp_query-objekt som definierar den aktuella begäran och sedan bestämmer $ wp_query vilken typ av fråga det handlar om (eventuellt ett kategorilogi, daterat arkiv, matning eller sökning) och hämtar begärda tjänster. Den behåller mycket information på begäran, som kan dras senare.

Otroligt teknisk, rätt?

Så här tänker du på det från konsumentens perspektiv:

WP_Query hämtar information om inlägg, sidor, andra anpassade posttyper och arkiverade data och gör den begärda informationen om den data tillgänglig.

Ur ett utvecklingsperspektiv, tänk på det så här:

WP_Query är ett sätt att hämta information om posttyper och arkiverade data samt deras associerade metadata och mer. Informationen som hämtas kan sedan läsas, manipuleras, sparas och / eller visas i mallfiler.

Kortfattat, WP_Query tillhandahåller ett vanligt sätt för oss att fråga databasen specifikt kring inlägg, sidor, anpassade posttyper och deras tillhörande metadata så att vi lättare kan arbeta med informationen WordPress-butiker.

Notera: Om du letar efter information om hur du hanterar användare eller skriver anpassade SQL-frågor, vänta tills nästa uppsättning artiklar eftersom vi kommer att täcka den informationen närmare på den tiden.

Så här använder du WP_Query

Okej, så vi har täckt Vad WP_Query är, varför det är fördelaktigt, och hur det ska användas, men det går bara så långt.

Vid den här tiden är det dags att ta en titt på vilka parametrar som kan överföras till WP_Query och några praktiska exempel på hur man använder den.

Först, WP_Query kan ta argument för: Författare, Kategorier, Taggar, Taxonomier, Generiska sökfrågor, Inlägg, Sidor, Anpassade inläggstyper, Status, Pagination, Beställning av poster, Datum, Anpassade fält, Tillstånd, Cachning och Returfält.

Kort sagt, bara om allt relaterat till posttyper, deras kategorier taggar och deras metadata kan hämtas med WP_Query.

Ett ord om loopen

Om du har tittat på någon WordPress-temakod eller arbetat med WordPress i någon kapacitet innan du läser den här artikeln så är det mycket troligt att du har sett kod så här:

Och i WordPress är detta det som kallas The Loop.

Kort sagt, The Loop är där allt händer när det gäller att visa information som hämtas från en fråga.

För det ändamålet, om du skriver en fråga med WP_Query, då brukar du använda samma struktur för ditt eget arbete.

Men vi får se mer om det på ett ögonblick.

Praktiska exempel

Komma igång med WP_Query är lätt. Låt oss till exempel säga att vi vill skapa en mall som visar alla inlägg för en enda författare.

För att göra det kan vi använda författarens ID. Så låt oss säga att vi vill hämta alla inlägg, sidor och innehåll som skrivits av författaren med ID för "1."

  1); $ my_query = nya WP_Query ($ args);

Och då vill vi iterera genom det:

 om $ my_query-> have_posts ()) while ($ my_query-> have_posts ()) // Gör jobbet med författarens 1 inlägg // Vi talar om den här nästa raden senare i artikeln wp_reset_postdata ();

Lätt nog, höger?

Men låt oss göra det lite mer komplicerat. Låt oss säga att vi bara vill hämta inlägg från den författaren som faller under den anpassade posttypen "Fotografi" och som publicerades 2013.

För att göra det skulle vi skicka den här informationen:

  1 'post_type' => 'fotografering' date_query '=> array (' 2013 ')); $ my_query = nytt WP_Query ($ args);

Och sedan iterera genom frågan så här:

 om $ my_query-> have_posts ()) while ($ my_query-> have_posts ()) // Gör jobbet med de returnerade inläggen // Vi talar om den här nästa raden senare i artikeln wp_reset_postdata ();

Men det kan bli lite mer komplext beroende på vilken information vi har till hands vid vilken tidpunkt som helst under programmets livscykel.

Låt oss till exempel säga att vi vill programmera en anpassad posttyp med en viss titel och slug, men endast om man inte redan existerar.

Det finns tre steg för att göra detta:

Överför de nödvändiga argumenten till klassen
Kör genom Loop letar efter eventuella inlägg som kan finnas
Om posten inte existerar, skapa sedan den

Så här gör du det:

 // Leta efter den angivna posttypen och slug som publiceras eller finns i papperskorgen $ args = array ('post_type' => $ post_type, 'post_name' => $ slug, 'post_status' => array ('publicera' 'skräp' ) ); $ post_type_query = nytt WP_Query ($ args); // Ett inlägg med den informationen finns redan, sedan ta bort den från papperskorgen om ($ post_type_query-> have_posts ()) while ($ post_type_query-> have_posts ()) $ post_type_query-> the_post (); // Om posten hittas i papperskorgen, återställ det om ("papperskorgen" == strtolower (get_post_status (get_the_ID ()))) $ page = get_page (get_the_ID ()); $ page-> post_status = 'publicera'; wp_update_post ($ sida);  // Om ett inlägg inte redan existerar med den angivna titeln, skapa den om (null == acme_get_permalink_by_slug ($ slug, $ post_type)) $ page_id = wp_insert_post (array ('comment_status' => 'stängt' , 'ping_status' => 'stängt', 'post_author' => 1, // Administratör skapar sidan 'post_title' => $ title, 'post_name' => strtolower ($ slug), 'post_status' => 'publicera ',' post_type '=> strtolower ($ post_type))); // Om en mall anges i funktionsargumenten, låt oss tillämpa den om (null! = Mall) update_post_meta (get_the_ID (), '_wp_page_template', $ template);  // Vi talar om den här raden senare i artikeln wp_reset_postdata ();

Som du kan berätta, kan du göra några riktigt kraftfulla frågor, och göra lite riktigt smart arbete med WordPress och WP_Query om du vet hur man hanterar parametrarna korrekt.

Nu, i koden ovan, när vi letar efter om posten redan finns i papperskorgen, där är mer optimala sätt att skriva en fråga för att kontrollera det; Koden ovan är dock avsedd att visa mer av ett exempel på hur man gör det med hjälp av WP_Query än vad som helst annat.

När vi kommer vidare in i det här ämnet för att skriva frågor, ser vi andra sätt att snabbare hämta information (som att använda rå SQL för VÄLJ uttalanden och RADERA eller UPPDATERING uttalanden).

För det ändamålet rekommenderar jag starkt att du känner till alla parametrar som den accepterar. Även om det finns många alternativ (vilket är bra enligt min mening) finns det ett relativt standard sätt att överföra dem så att många av dem fungerar på samma sätt som andra.

Det vill säga att när du lär dig några av dem är det lätt att hämta resten.

Utöver det, om du verkligen förstår frågorna lite mer, rekommenderar jag att du tittar på hur parametrarna motsvarar data i den underliggande databasen.

När ska du använda WP_Query

Det här förstås naturligtvis frågan om när ska du använda WP_Query.

När allt kommer omkring har WordPress sin egen mallhierarki, så om du arbetar med en fil som passar inom nämnda hierarki, kommer den automatiskt att använda en fråga relaterad till den malltypen.

Men att skriva applikationer, eller till och med avancerade WordPress-teman, kommer att skapa dig mallar som inte passar in i hierarkin och behöver sålunda sin egen uppsättning frågor.

Det är ett sätt som du behöver använda WP_Query.

För det andra, om du vill dra tillbaka en anpassad uppsättning information - vare sig det är en bit eller flera bitar - för ett visst inlägg, en sida, anpassad posttyp, kategori, taxonomi osv. WP_Query är förmodligen ditt bästa alternativ.

Ett ord om att återställa frågan

Det finns en stor gotcha att använda WP_Query det är nyckeln till att avrunda din förståelse för API: n och det är wp_reset_postdata ().

Precis som Codex beskriver:

Använd den här funktionen för att återställa den globala $ post-variabeln i den huvudsakliga frågeslingan efter en sekundär sökfråga med nytt WP_Query. Det återställer variabeln $ post till det aktuella inlägget i huvudfrågan.

På grund av hur WordPress upprätthåller information med global variabler, är det viktigt att när du har skapat, utfört och bearbetat din egen WP_Query, då måste du ringa den här funktionen för att återställa information till staten som det var innan du körde din egen fråga.

Det här är så att WordPress fortsätter att slingra igenom information efter behov i mallhierarkin, och så att data inte saknas eller förloras när rendering av innehåll senare på en sida eller på en annan sida.

Nästa Upp, WP_User_Query

Om WP_Query är så viktigt att skapa effektiva, säkra frågor för posttyper och deras relaterade attribut, hur gör vi detsamma för användare?

När allt kommer omkring, har vi redan konstaterat att WordPress erbjuder utmärkta faciliteter för kontohantering, men vi har inte faktiskt diskuterat hur vi kan hantera användare genom att fråga databasen.

I nästa artikel tar vi en titt på exakt det. Och om du är bekant med WP_Query - som du borde vara efter att ha läst den här artikeln - så hittar du nästa artikel väldigt lätt att följa.

Koda