WordPress gebruiken voor ontwikkeling van webapplicaties Functies Aangepaste query's met WP_Query

We hebben gekeken naar hoe WordPress kan worden gebruikt als een basis voor de ontwikkeling van toepassingen, maar een van de dingen die we tot nu toe te behandelen hebben die de meeste moderne frameworks bieden, is hoe de database te doorzoeken om resultaten voor een bepaalde weergave op te halen.

In het bijzonder hebben we niet gesproken over hoe we informatie uit de database kunnen halen en deze in onze pagina's kunnen invoegen.

Als u bekend bent met andere frameworks, dan bent u waarschijnlijk bekend met een object-relationeel mapping-systeem (een ORM).

Voor degenen die niet bekend zijn met een ORM, is het in wezen een stukje software dat zich tussen de toepassing en de database bevindt, en stelt ons in staat rijen en kolommen als objecten op te halen, als zodanig te behandelen en vervolgens hun wijzigingen terug te zetten naar de database.

Het zijn echt coole dingen. WordPress doet dat echter wel niet bied die flexibiliteit aan.

In plaats daarvan zijn er een aantal API's die we kunnen gebruiken om wijzigingen in de database aan te brengen. Er zijn een aantal API's beschikbaar die we kunnen gebruiken, die we allemaal over deze laatste reeks artikelen gaan bekijken.

Eerst gaan we kijken WP_Query. Daarna zullen we een kijkje nemen WP_User_Query, gevolgd door de $ wpdb object dat beschikbaar is als een globaal in WordPress.

Maar daarover later meer. Nu, door naar WP_Query.

De WordPress-database opvragen

Voordat we er echt over beginnen om te praten over het ondervragen van de WordPress-database, denk ik dat het van cruciaal belang is om precies te beschrijven wat dit betekent, waarom het belangrijk is en wat het inhoudt.

Als dit niet anders is, is dit bedoeld om de verwachtingen voor lezers gelijk te stellen, ongeacht uw ervaringsniveau.

1. Wat betekent dit?

Het opvragen van de WordPress-database vertegenwoordigt precies wat u zou verwachten: het ophalen van informatie uit de database waarop WordPress wordt uitgevoerd.

Daar is niets erg ingewikkelds aan. Echter, daar zijn verschillende manieren om het te doen, en het is belangrijk om te weten hoe het moet en wat te vermijden.

Over het algemeen zijn er drie API's beschikbaar en aanbevolen die door ons kunnen worden gebruikt, en enkele API's die beschikbaar zijn, maar dat wel zijn niet aanbevolen voor gebruik.

In deze reeks artikelen gaan we dat allemaal behandelen.

2. Waarom is dit belangrijk?

Als dit niet anders is, is dit belangrijk, zodat we de juiste manieren begrijpen om informatie op te halen en op te slaan in de database op de veiligste en veiligste manieren..

Vergeet niet: bij het programmeren betekent het feit dat iets werkt niet dat dit de beste manier is om het te doen.

Daartoe gaan we de aanbevolen manieren bekijken die WordPress biedt voor het ophalen en opslaan van gegevens rechtstreeks van en naar de database..

We willen er immers voor zorgen dat we niet alleen robuuste applicaties bouwen, maar ook veilige en efficiënte applicaties.

3. Wat houdt dit in?

Zoals bij de meeste dingen, betekent dit het leren van een API. Tenminste, dat is het geval voor twee van de vraagtypes.

Voor het laatste artikel is vereist dat u SQL (als WordPress) kent of leert kennen doet staat u toe om onbewerkte zoekopdrachten tegen de database te schrijven). Maar daarover later meer.

Voor nu concentreren we ons eenvoudig op de API's, de beschikbare parameters en hoe en wanneer ze in ons werk moeten worden gebruikt.

Introductie van WP_Query

Hoewel je alles kunt lezen WP_Query in de WordPress Codex vind ik het de moeite waard om enkele van de fijnere punten hier in dit artikel te distilleren, vooral als u nog niet bekend bent met WordPress, of serieus overweegt om applicaties te schrijven met WordPress.

De Codex definieert WP_Query als het volgende:

WP_Query is een klasse ... die zich bezighoudt met de fijne kneepjes van een bericht (of pagina's) naar een WordPress-blog. De wp-blog-header.php ... geeft de $ wp_query-objectinformatie die het huidige verzoek definieert, en vervolgens bepaalt $ wp_query welk type query het verwerkt (mogelijk een categoriearchief, gedateerd archief, feed of zoekactie) en haalt het de gevraagde berichten. Het bevat veel informatie over het verzoek, dat op een later tijdstip kan worden getrokken.

Ongelofelijk technisch, toch??

Hier leest u hoe u dit vanuit het perspectief van de consument ziet:

WP_Query haalt informatie over berichten, pagina's, andere aangepaste berichttypen en gearchiveerde gegevens op en stelt de gevraagde informatie over die gegevens beschikbaar.

Denk vanuit een ontwikkelingsperspectief als volgt:

WP_Query is een manier om informatie op te halen over berichttypen en gearchiveerde gegevens, evenals de bijbehorende metagegevens, en meer. De informatie die wordt opgehaald, kan vervolgens worden gelezen, gemanipuleerd, opgeslagen en / of weergegeven in sjabloonbestanden.

Kortom, WP_Query biedt een standaardmanier voor ons om de database specifiek te vragen met betrekking tot berichten, pagina's, aangepaste berichttypen en de bijbehorende metadata zodat we gemakkelijker kunnen werken met de informatie in WordPress-winkels.

Notitie: Als u op zoek bent naar informatie over het beheer van gebruikers of het schrijven van aangepaste SQL-query's, wacht dan tot de volgende reeks artikelen, zodat we die informatie op dat moment gedetailleerder kunnen bekijken..

Hoe WP_Query te gebruiken

Oké, dus we hebben het behandeld wat WP_Query is, waarom het voordelig is, en hoe het zou moeten worden gebruikt, maar dat gaat alleen zo ver.

Op dit moment is het tijd om te kijken naar welke parameters kunnen worden doorgegeven WP_Query en enkele praktische voorbeelden van hoe het te gebruiken.

Eerste, WP_Query kan argumenten gebruiken voor: Auteurs, Categorieën, Tags, Taxonomieën, Algemene zoekvragen, Berichten, Pagina's, Aangepaste berichttypen, Status, Paginering, Volgorde van records, Datums, Aangepaste velden, Machtigingen, caching en Return Fields.

Kortom, zowat alles gerelateerd aan berichttypes, hun categorielabels en hun metagegevens kunnen worden opgehaald met WP_Query.

Een woord over de lus

Als u naar een WordPress-themacode hebt gekeken of in welke hoedanigheid dan ook met WordPress hebt gewerkt voordat u dit artikel hebt gelezen, is de kans groot dat u deze code als volgt heeft gezien:

En, in WordPress, dit is wat bekend staat als The Loop.

Kortom, The Loop is waar alles gebeurt als het betrekking heeft op het weergeven van informatie die is opgehaald uit een query.

Daartoe, als u een vraag schrijft met behulp van WP_Query, dan ga je waarschijnlijk dezelfde structuur gebruiken voor je eigen werk.

Maar daar komen we straks meer over te weten.

Praktische voorbeelden

Beginnen met WP_Query is makkelijk. Stel dat we bijvoorbeeld een sjabloon willen instellen die alle berichten voor één auteur weergeeft.

Om dat te doen, kunnen we de ID van de auteur gebruiken. Laten we zeggen dat we alle berichten, pagina's en inhoud van de auteur willen ophalen met de ID van '1'.

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

En dan willen we het erdoorheen herhalen:

 if ($ my_query-> have_posts ()) while ($ my_query-> have_posts ()) // Werk met het bericht van Auteur 1 // We zullen het later hebben over deze volgende regel in het artikel wp_reset_postdata ();

Makkelijk genoeg, toch?

Maar laten we het een beetje ingewikkelder maken. Laten we zeggen dat we alleen de berichten van die auteur willen ophalen die onder het aangepaste berichttype 'Fotografie' vallen en die in 2013 zijn gepubliceerd.

Om dat te doen, zouden we deze informatie doorgeven:

  1 'post_type' => 'fotografie' date_query '=> array (' 2013 ')); $ my_query = new WP_Query ($ args);

En dan doorloop de query als volgt:

 if ($ my_query-> have_posts ()) while ($ my_query-> have_posts ()) // Werk met de geretourneerde berichten // We zullen het later hebben over deze volgende regel in het artikel wp_reset_postdata ();

Maar het kan een beetje ingewikkelder worden, afhankelijk van de informatie die we bij de hand hebben op elk moment tijdens de levenscyclus van de applicatie.

Stel dat we bijvoorbeeld een aangepast berichttype met een specifieke titel en slak willen maken, maar enkel en alleen als die nog niet bestaat.

Er zijn drie stappen om dit te doen:

Geef de benodigde argumenten door aan de klas
Ren door The Loop op zoek naar berichten die mogelijk bestaan
Als het bericht niet bestaat, maak het dan aan

Hier is hoe te om dat te doen:

 // Zoek naar het opgegeven berichttype en de slug die zijn gepubliceerd of in de prullenbak staan $ args = array ('post_type' => $ post_type, 'post_name' => $ slug, 'post_status' => array ('publish', 'trash')); $ post_type_query = nieuwe WP_Query ($ args); // Er bestaat al een bericht met die informatie en verwijder het uit de prullenbak als ($ post_type_query-> have_posts ()) while ($ post_type_query-> have_posts ()) $ post_type_query-> the_post (); // Als het bericht in de prullenbak wordt gevonden, herstel het als ('trash' == strtolower (get_post_status (get_the_ID ()))) $ page = get_page (get_the_ID ()); $ page-> post_status = 'publiceren'; wp_update_post ($ pagina);  // Als er nog geen bericht bestaat met de opgegeven titel, maak deze dan aan als (null == acme_get_permalink_by_slug ($ slug, $ post_type)) $ page_id = wp_insert_post (array ('comment_status' => 'closed') , 'ping_status' => 'gesloten', 'post_author' => 1, // Beheerder maakt de pagina 'post_title' => $ title, 'post_name' => strtolower ($ slug), 'post_status' => 'publiceer ',' post_type '=> strtolower ($ post_type))); // Als een sjabloon is opgegeven in de functieargumenten, laten we dit toepassen als (null! = $ Sjabloon) update_post_meta (get_the_ID (), '_wp_page_template', $ template);  // We zullen praten over deze regel later in het artikel wp_reset_postdata ();

Zoals je ziet, kun je een paar heel krachtige vragen stellen en heel slim werken met WordPress en WP_Query als je weet hoe je de parameters correct moet hanteren.

Nu, in de bovenstaande code, willen we kijken of het bericht al in de prullenbak aanwezig is zijn meer optimale manieren om een query te schrijven om dat te controleren; de bovenstaande code is echter bedoeld om meer van een voorbeeld te laten zien van hoe het te gebruiken WP_Query Dan iets anders.

Naarmate we verder ingaan op dit onderwerp van het schrijven van query's, zien we andere manieren om sneller informatie op te halen (zoals het gebruik van onbewerkte SQL voor SELECT verklaringen en DELETE of BIJWERKEN statements).

Daarom raad ik aan om vertrouwd te raken met alle parameters die worden geaccepteerd. Hoewel er veel opties zijn (wat naar mijn mening een goede zaak is), is er een relatief standaard manier om ze zo door te geven dat velen van hen hetzelfde presteren als anderen.

Dat wil zeggen dat als je er een paar leert, het gemakkelijk is om de rest op te halen.

Als je de vragen echt een beetje beter wilt begrijpen, raad ik aan om eens te kijken hoe de parameters overeenkomen met de gegevens in de onderliggende database..

Wanneer gebruik ik WP_Query

Dit roept uiteraard de vraag op wanneer zou je moeten gebruiken WP_Query.

WordPress heeft immers zijn eigen sjabloonhiërarchie, dus als u met een bestand werkt dat binnen deze hiërarchie past, gebruikt het automatisch een query die gerelateerd is aan dat sjabloontype.

Maar met het schrijven van applicaties, of zelfs met geavanceerde WordPress-thema's, kunt u sjablonen maken die niet in de hiërarchie passen en dus hun eigen set query's nodig hebben.

Dat is een manier waarop je moet gebruiken WP_Query.

Ten tweede, als u op zoek bent naar een aangepaste set informatie terug te trekken - zij het een stuk of meerdere stukken - voor een bepaalde post, pagina, aangepast berichttype, categorie, taxonomie, enzovoort, dan WP_Query is aantoonbaar uw beste optie.

Een woord over het opnieuw instellen van de query

Daar is er een groot gotcha voor gebruik WP_Query dat is de sleutel tot het completeren van uw kennis van de API en dat is wp_reset_postdata ().

Net zoals de Codex beschrijft:

Gebruik deze functie om de globale $ post-variabele van de hoofdquartelus te herstellen na een secundaire querylus met behulp van nieuwe WP_Query. Het herstelt de variabele $ post naar het huidige bericht in de hoofdquery.

Vanwege de manier waarop WordPress informatie onderhoudt met behulp van globaal variabelen, het is van cruciaal belang dat u uw eigen hebt gemaakt, uitgevoerd en verwerkt WP_Query, dan moet je deze specifieke functie aanroepen om informatie te herstellen naar de staat waarin het zich bevond voorafgaand aan toen je je eigen query uitvoerde.

Dit is zo dat WordPress doorgaat met het doorlussen van informatie zoals nodig in de sjabloonhiërarchie, en zodat gegevens niet worden gemangeld of verloren gaan bij het renderen van inhoud later op een pagina of op een andere pagina.

Volgende omhoog, WP_User_Query

Als WP_Query is zo cruciaal voor het maken van efficiënte, veilige query's voor berichttypen en de bijbehorende kenmerken, hoe doen we hetzelfde voor gebruikers?

We hebben immers al vastgesteld dat WordPress, buiten de gebaande paden, fantastische faciliteiten biedt voor accountbeheer, maar we hebben niet echt gesproken over de manieren waarop we gebruikers kunnen beheren door de database te raadplegen.

In het volgende artikel zullen we daar precies naar kijken. En als u bekend bent met WP_Query - wat je zou moeten zijn na het lezen van dit artikel - dan vind je het volgende artikel heel gemakkelijk te volgen.

Code