WordPress gebruiken voor Web Application Development Beschikbare functies, Deel 5 - Gegevens ophalen

Inmiddels weet u dat het doel van deze serie is om aan te tonen hoe WordPress kan worden gebruikt als basis voor de ontwikkeling van webtoepassingen.

We zijn begonnen met het op hoog niveau bekijken van veel ontwerppatronen van webapplicaties, hoe WordPress verschilt en waarom WordPress eerder als een fundament dan als een raamwerk moet worden beschouwd..

In de afgelopen paar artikelen hebben we gekeken naar gebruikersrollen, machtigingen, sessiemanagement, e-mail en serialisatie van gegevens. Maar als je gegevens gaat opslaan in de database, is het alleen logisch dat je het gaat ophalen?

Gelukkig maken de API's die WordPress beschikbaar heeft, het heel gemakkelijk om informatie uit de database op te halen. Als u bovendien het laatste artikel gemakkelijk te volgen vond, zou u geen probleem moeten hebben om dit artikel te volgen, omdat veel van de principes hetzelfde zijn:

  • We halen de informatie uit de database op met behulp van de unieke ID die we hebben geleverd bij het opslaan van de informatie
  • We ontsnappen aan de gegevens om te zorgen dat deze veilig kunnen worden weergegeven in de browser
  • We brengen het vervolgens terug naar de aanroepende functie

Niets erg ingewikkelds, toch?

En dat is het echt niet - vooral omdat het betrekking heeft op het gebruik van dezelfde API's (zij het verschillende functies) die we hebben gebruikt voor het opslaan van informatie in de optietabel en de metatatabellen. In dit artikel gaan we door met onze discussie over het ophalen van informatie en hoe we ervoor kunnen zorgen dat we op de juiste manier aan informatie ontsnappen om ervoor te zorgen dat de gegevens veilig en schoon zijn voor weergave in de browser.


Data Retrieval

Zoals ik in eerdere artikelen al zei, is een van de belangrijkste onderscheidende factoren tussen een normale website en een webtoepassing gegevensopslag.

En aangezien WordPress zijn eigen database gebruikt om gegevensopslag te beheren en API's beschikbaar maakt voor onze eigen projecten, is het natuurlijk een webtoepassing.

Verder, ik heb net in het laatste artikel besproken dat het begrijpen van hoe je gegevens kunt opslaan met de juiste API's heel eenvoudig is, en als je eenmaal hebt geleerd hoe je er een moet gebruiken, is het gebruik van de rest bijna net zo gemakkelijk. Bovendien is het aantoonbaar nog eenvoudiger om te leren hoe u gegevens kunt ophalen.

Dat gezegd hebbende, er zijn een paar nuances die we moeten overwegen bij het verplaatsen van gegevens. Maar eerst zullen we de database bekijken, bekijken hoe informatie kan worden opgehaald en vervolgens bekijken we hoe we op de juiste manier aan informatie kunnen ontsnappen voordat we deze teruggeven aan de browser..

Inzicht in de database

In het vorige artikel hebben we een gedetailleerd overzicht van de tabellen waaraan u kunt schrijven. U kunt hierover meer in detail lezen in het eerste artikel, maar hier is een samenvatting van de tabellen die we hebben besproken:

  • wp_options
  • wp_posts
  • wp_postmeta
  • wp_comments
  • wp_commentmeta

Vergeet niet dat u dit alles en meer kunt bekijken op de pagina met de databasebeschrijving in de WordPress Codex.

Lezen uit de database

Dus daarmee, als onze opfriscursus, is het tijd om daadwerkelijk te kijken hoe informatie uit de database kan worden opgehaald.

Gelukkig is het net zo gemakkelijk als het schrijven van informatie naar de database. De twee belangrijkste verschillen zijn:

  • We gebruiken enigszins verschillende functies.
  • Er is een beetje werk dat we moeten doen om ervoor te zorgen dat de gegevens die we weergeven, netjes zijn opgemaakt voor de browser.

Voordat we kijken naar hoe we de gegevens moeten beheren, moeten we eerst kijken hoe we opties uit de database kunnen lezen.

De optietabel

Herinner uit het laatste artikel dat de manier waarop we over het schrijven van gegevens naar de optietabel gaan, is door de add_option of de get_option functies.

Onthoud: elke gebruiker neemt een unieke sleutel op die wordt gebruikt om de waarde in de database te identificeren en de waarde die aan die sleutel is gekoppeld. In ons vorige voorbeeld demonstreerde ik het volgende:

 if (isset ($ _POST ['value']) &&! empty ($ _POST ['value']) $ clean_value = strip_tags (stripslashes ($ _POST ['value'])); add_option ('mijnwaarde', $ clean_value);

Dit betekent dat we de informatie hebben ontsmet en opgeslagen in de database met behulp van de mijn-waarde sleutel.

Om deze informatie uit de database op te halen, voeren we de volgende oproep:

 $ my_value = get_option ('mijn-waarde');

Het is bijna te simpel.

Maar er is een vangst aan de get_option functie: We kunnen een standaardwaarde opgeven die moet worden geretourneerd als die nog niet bestaat.

Stel dat we bijvoorbeeld een waarde voor de sleutel gaan opzoeken Uw-waarde, wat niet bestaat.

 // $ your_value zal eigenlijk FALSE $ your_value = get_option ('jouw-waarde') evenaren;

In dit geval zal de functie terugkeren VALSE; Als we echter een tweede parameter opgeven, kunnen we een standaardwaarde retourneren:

 // $ your_value zal in feite gelijk zijn aan een lege string $ your_value = get_option ('jouw-waarde', ");

Zelfs dan nog, niets erg ingewikkelds, toch?

Hoe zit het met Theme Mod?

Voordat we kijken naar hoe we informatie kunnen ophalen uit de metatabellen, is het de moeite waard om te vermelden dat we net zoals we informatie gebruiken gebruiken set_theme_mod, we kunnen ook thema-instellingen ophalen met get_theme_mod.

Rechtstreeks uit de WordPress Codex:

Haalt een aanpassingsinstelling op voor het huidige thema. Samen met set_theme_mod () deze functie biedt soms thema-ontwikkelaars een eenvoudiger alternatief voor de instellingen-API wanneer er behoefte is aan het afhandelen van elementaire thema-specifieke instellingen.

Nogmaals, dit is duidelijk bedoeld voor het werken met thema's; echter, ik wilde het hier vermelden omwille van volledigheid en ter afronding van de discussie die in het vorige artikel is gestart.

Anders dan dat, is dit puur bedoeld om te laten zien hoe opties kunnen worden opgeslagen op basis van hoe je mogelijk met thema-ontwikkeling werkt; het is echter echt buiten het bereik van de serie over applicatie-ontwikkeling.

The Post Meta en de Comment Meta Tables

Nu terug naar de databasetabellen die meer van toepassing zijn op de ontwikkeling van toepassingen en zelfs contentbeheer.

In het laatste artikel demonstreerde ik de API-functies die verantwoordelijk zijn voor het schrijven van informatie naar de metatatabels. Specifiek heb ik de volgende functies geschetst:

  • add_post_meta
  • update_post_meta
  • add_comment_meta
  • update_comment_meta

Op dezelfde manier als de rest van de Options API, is het ophalen van informatie uit elk van deze tabellen heel eenvoudig, behalve dat het wordt geleverd met een enkele 'gotcha'-standaard wordt alle informatie die wordt geretourneerd uit deze functies gedaan in de vorm van een rangschikking.

Dit betekent dat als je moet bellen:

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

Vervolgens worden de gegevens in een array naar u teruggestuurd; maar als je wilt slagen TRUE om de functie te gebruiken bij het aanroepen, dan worden de gegevens teruggestuurd in een string:

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

Natuurlijk is er geen rechts manier om dit te doen. In plaats daarvan is het afhankelijk van de informatie die u wilt retourneren en / of hoe u deze wilt retourneren. Omdat er geen enkele manier is om dit te doen, moet u uw gebruik beoordelen op basis van de implementatie van uw toepassing.

Ontsnappende gegevens

Nu, net zoals we informatie moesten opschonen voordat we het daadwerkelijk naar de database schreven, is het ook belangrijk dat we goed aan de gegevens ontsnappen nadat we deze uit de database hebben gehaald, maar voordat we deze aan de browser hebben gegeven.

Ontsnappen aan gegevens is het proces waarmee we ervoor zorgen dat de gegevens die we voor de gebruiker gaan weergeven, veilig zijn. Het is eigenlijk de reiniging van gegevens; het is echter klaar na de gegevens zijn eerder uit de database gehaald dan vóór het schrijven naar de database.

Als het gaat om het accepteren van gegevens, zijn er vier hoofdfuncties waarvan we ons bewust moeten zijn:

  1. esc_html wordt gebruikt om te ontsnappen aan HTML-blokken.
  2. esc_url is wanneer u URL's moet opschonen die worden weggeschreven naar tekstelementen, attribuutknooppunten of ergens anders in de opmaak.
  3. esc_js wordt gebruikt om te ontsnappen aan tekstreeksen die worden gebruikt om JavaScript te JavaScript-in de eerste plaats inline JavaScript.
  4. esc_attr codeert verschillende tekens die de uitvoer kunnen mangelen als ze niet goed worden verwerkt.

Het leuke hiervan is dat ze over het algemeen exact op dezelfde manier werken, en de manier om te bepalen welke je moet gebruiken is relatief eenvoudig:

  • Als u inline JavaScript rendert, gebruik dan esc_js,
  • Als u een kenmerk voor een element weergeeft, gebruikt u esc_attr.

Makkelijk genoeg, toch?

Laten we dus zeggen dat je wilde ontsnappen aan een attribuut van een invoerveld dat afkomstig is van de $ _POST verzameling. Om dit te doen, zou je de volgende code schrijven:

 '; ?>

Het zijn kleine dingen zoals deze die een lange weg kunnen afleggen naar het zekerstellen dat uw applicatie robuust is in zowel dataserialisatie als het ophalen van gegevens.


En nu, op URL herschrijven

We hebben veel aandacht besteed aan deze serie, maar er is nog meer te halen.

Voorbeeld: een van de leukste kenmerken van enkele van de meer populaire webapplicatiekaders is hoe ze met URL's omgaan. Kort gezegd bieden ze schone URL-schema's die het heel gemakkelijk maken om de verschillende acties te begrijpen die beschikbaar zijn voor de gegevensmodellen die in de hele applicatie worden gebruikt.

Out-of-the-box, WordPress biedt niet de schoonste of duidelijkste URL's; dit echter kan worden aangepast door het gebruik van de Rewrite API. In het volgende artikel gaan we precies bekijken hoe we aangepaste regels kunnen introduceren voor schone URL's die lijken op iets dat u zou zien in een webtoepassing in plaats van in een inhoudbeheersysteem of een blog.