Utilizarea WordPress pentru dezvoltarea aplicațiilor web Caracteristici disponibile, Partea 5 - Preluarea datelor

Până acum, știi că scopul acestei serii este să demonstreze modul în care WordPress poate fi folosit ca bază pentru dezvoltarea aplicațiilor web.

Am inceput prin a lua un aspect la nivel inalt la multe modele de design de aplicatii web, modul in care WordPress difera si de ce WordPress ar trebui sa fie considerat a fi mai mult o fundatie decat un cadru.

În ultimele câteva articole, am analizat rolurile utilizatorilor, permisiunile, gestionarea sesiunilor, e-mailurile și serializarea datelor. Dar dacă vrei să salvezi date în baza de date, are sens doar că vei fi recuperat, corect?

Din fericire, API-urile pe care WordPress le pune la dispoziție fac foarte ușor să recupereze informații din baza de date. În plus, dacă ați găsit ultimul articol ușor de urmărit, atunci nu ar trebui să aveți nicio problemă în urma acestui articol, deoarece multe dintre principii sunt aceleași:

Descărcăm informațiile din baza de date folosind ID-ul unic pe care l-am furnizat la salvarea informațiilor
Evităm datele pentru a ne asigura că este în siguranță pentru a le oferi browserului
Apoi îl întoarcem la funcția de apelare

Nimic foarte complicat, corect?

Și într-adevăr nu este - mai ales pentru că se referă la utilizarea acelorași API-uri (deși diferite funcții) pe care le-am utilizat pentru salvarea informațiilor în tabelele de opțiuni și în tabelele meta-date. În acest articol, vom continua discuția noastră cu privire la modul de preluare a informațiilor, precum și cum să ne asigurăm că evităm în mod corespunzător informațiile pentru a ne asigura că datele sunt sigure și curate pentru redarea în browser.

Recuperare de date

După cum am menționat în articolele anterioare, unul dintre principalele diferențiatoare dintre un site web normal și o aplicație web este stocarea datelor.

Și din moment ce WordPress folosește o bază de date proprie pentru a gestiona stocarea datelor, precum și pentru a face ca API-urile să fie disponibile pentru noi pentru propriile noastre proiecte, este evident o aplicație web.

Mai mult, tocmai am discutat în ultimul articol, înțelegând cum să salvați datele utilizând API-urile potrivite este foarte simplu și odată ce ați învățat cum să utilizați unul, folosirea restului este aproape la fel de ușor. În plus, învățarea modului de a recupera datele este cu siguranță mai ușoară.

Acestea fiind spuse, există câteva nuanțe pe care trebuie să le luăm în considerare la avansarea datelor. Dar, mai întâi, vom analiza baza de date, aruncăm o privire asupra modului de preluare a informațiilor și vom examina cum să scăpăm de informații în mod corespunzător înainte de ao returna în browser.

Înțelegerea bazei de date

În articolul precedent, avem o prezentare detaliată a tabelelor la care puteți scrie. Puteți citi mai detaliat despre acest lucru în primul articol, dar aici este un rezumat al tabelelor pe care le-am discutat:

wp_options
wp_posts
wp_postmeta
wp_comments
wp_commentmeta

Rețineți că puteți examina toate acestea și multe altele în pagina de descriere a bazei de date din Codul WordPress.

Citirea din baza de date

Așa că, ca și reîmprospătarea noastră, este timpul să examinăm cum să preluăm informațiile din baza de date.

Din fericire, este la fel de ușor ca scrierea de informații în baza de date. Cele două diferențe principale sunt:

Folosim funcții puțin diferite.
Există un pic de lucru pe care trebuie să-l facem pentru a ne asigura că datele pe care le afișăm este formatat curat pentru browser.

Înainte de a ne uita la modul de gestionare a datelor, să analizăm mai întâi cum să citiți opțiunile din baza de date.

Tabelul Opțiuni

Rețineți din ultimul articol că modul în care mergem despre scrierea datelor în tabelul cu opțiuni este prin utilizarea add_option sau get_option funcții.

Rețineți: fiecare are o cheie unică folosită pentru a identifica valoarea din baza de date și valoarea asociată acelei chei. În exemplul nostru anterior, am demonstrat următoarele:

 ($ _POST ['value']) &&! empty ($ _POST ['value']) $ clean_value = strip_tags $ clean_value);

Aceasta înseamnă că am dezinfectat și salvat informații în baza de date folosind mi-valoare cheie.

Pentru a prelua aceste informații din baza de date, efectuăm următorul apel:

 $ my_value = get_option ("valoarea mea");

E aproape prea simplu.

Dar există o prindere la get_option funcția: De fapt, putem specifica o valoare implicită pentru a reveni dacă nu există deja.

De exemplu, să spunem că vom căuta o valoare pentru cheie dvs. de valoare, care nu există.

 // $ your_value va fi de fapt FALSE $ your_value = get_option ('valoarea ta');

În acest caz, funcția va reveni FALS; cu toate acestea, dacă specificăm un al doilea parametru, atunci putem reveni la o valoare implicită:

 // $ your_value va fi egal cu un șir gol $ your_value = get_option ('valoarea dvs.', ");

Chiar și așa, nimic teribil de complicat, corect?

Ce este despre tema Mod?

Înainte de a ne uita la modul de preluare a informațiilor din tabelele meta, merită menționat faptul că, la fel cum am stabilit informațiile folosind set_theme_mod, putem de asemenea să regăsim setările temelor utilizând get_theme_mod.

Direct de la Codex-ul WordPress:

Preia o modificare de modificare pentru tema curentă. Impreuna cu set_theme_mod () această funcție poate uneori să ofere dezvoltatorilor temelor o alternativă mai simplă la API-ul Setări atunci când este nevoie să se gestioneze setările de bază specifice temelor.

Din nou, acest lucru este în mod evident destinat să lucreze cu teme; totuși, am vrut să o menționez aici pentru a fi complet și pentru a încheia discuția începută în articolul precedent.

În afară de asta, este vorba pur și simplu de a arăta cum pot fi stocate opțiunile bazate pe modul în care lucrați cu dezvoltarea temelor; cu toate acestea, este într-adevăr în afara sferei de aplicare a seriei privind dezvoltarea de aplicații.

Mesajul Post Meta și tabelele Meta Comentariilor

Acum, înapoi să vorbim despre tabelele de baze de date care sunt mai aplicabile dezvoltării aplicațiilor și chiar gestionării conținutului.

În ultimul articol, am demonstrat funcțiile API responsabile pentru scrierea informațiilor în tabelele de date meta. Mai exact, am subliniat următoarele funcții:

add_post_meta
update_post_meta
add_comment_meta
update_comment_meta

În mod similar cu restul API-ului Options, extragerea informațiilor din fiecare dintre aceste mese este foarte ușoară, cu excepția faptului că vine cu un singur "gotcha" - în mod implicit, toate informațiile returnate din aceste funcții se fac astfel sub forma unei mulțime.

Aceasta înseamnă că, dacă doriți să sunați:

 $ my_data = get_post_meta (get_the_ID (), "informații post-post");

Apoi, datele vă vor fi returnate într-o matrice; totuși, dacă vrei să treci ADEVĂRAT la funcția atunci când o apelați, atunci datele vă vor fi returnate într-un șir:

 $ my_data = get_post_meta (get_the_ID (), "informații post-post", TRUE);

Desigur, nu există dreapta modalitate de a face acest lucru. În schimb, depinde de informațiile pe care le doriți returnate și / sau de modul în care doriți să le reveniți. Deoarece nu există nici un singur mod de a face acest lucru, trebuie să vă judeca utilizarea pe baza implementării aplicației.

Datele escape

Acum, așa cum am nevoie pentru a dezinstala informații înainte de a le scrie de fapt la baza de date, este, de asemenea, important să scăpăm în mod corespunzător de date după ce le-am recuperat din baza de date, dar înainte de redarea la browser.

Datele escape sunt procesul prin care ne asigurăm că datele pe care le vom oferi utilizatorilor sunt sigure. Este în principiu dezintoxicarea făcută datelor; totuși, sa terminat după datele au fost preluate din baza de date, mai degrabă decât înainte de a le scrie în baza de date.

Când vine vorba de acceptarea datelor, există patru funcții principale pe care ar trebui să le cunoaștem:

esc_html este folosit pentru a scăpa de blocurile HTML.
esc_url este atunci când aveți nevoie pentru a curăța URL-uri care vor fi scrise la elementele de text, noduri atribut, ori oriunde altundeva în markup.
esc_js este folosit pentru a scăpa de șiruri de text care sunt folosite pentru ecou JavaScript-în primul rând, JavaScript inline.
esc_attr codifică mai multe caractere care pot bloca ieșirea dacă nu este corect tratată.

Lucrul frumos în legătură cu acest lucru este că în general funcționează exact în același mod, iar modul de a determina care dintre ele trebuie să fie relativ ușor:

Dacă redirecționați JavaScript inline, atunci utilizați esc_js,
Dacă dați un atribut pentru un element, atunci utilizați esc_attr.

Destul de ușor, corect?

De exemplu, să spunem că ați vrut să scăpați de un atribut al unui câmp de intrare care vine de la $ _POST Colectie. Pentru a face acest lucru, scrieți următorul cod:

 „; ?>

Este vorba de lucruri mici, cum ar fi acest lucru, care pot merge mult pentru a vă asigura că aplicația dvs. este robustă atât în serializarea datelor cât și în recuperarea datelor.

Și acum, la rescrierea URL-ului

Am acoperit o mulțime de teren în această serie, dar mai sunt multe de făcut.

Cazul în cauză: Una dintre cele mai frumoase caracteristici ale unora dintre cele mai populare cadre de aplicații web este modul în care se ocupă de adresele URL. Pe scurt, ele oferă scheme de adrese URL curate care fac foarte ușor să înțeleagă diferitele acțiuni disponibile pentru modelele de date utilizate în întreaga aplicație.

Out-of-the-box, WordPress nu oferă cele mai recente sau mai clare adrese URL; totuși, acest lucru poate sa să fie modificată prin utilizarea API-ului Rewrite. În următorul articol, vom examina exact modul în care putem introduce reguli personalizate pentru adrese URL curate care seamănă cu ceva ce ați vedea într-o aplicație web, și nu într-un sistem de gestionare a conținutului sau într-un blog.

Cod