Programarea modulelor WordPress

Cârlige de module WordPress

Multe module WordPress își realizează obiectivele prin conectarea la unul sau mai multe ”cârlige” (”hooks”) de module WordPress. Cârligele de module funcționează astfel încât în diferite momente, în timp ce rulează, WordPress verifică toate modulele să vadă dacă au înregistrate funcții pentru a rula la acel moment, și dacă da, funcțiile sunt rulate. Aceste funcții modifică comportamentul implicit al WordPress.

De exemplu, înainte ca WordPress să adauge titlul unei postări în browser, mai întâi verifică să vadă dacă vreun modul are înregistrată o funcție pentru cârligul „filter” numită „the_title„. Dacă este așa, textul titlului este trecut, la rândul său, prin fiecare funcție înregistrată, iar rezultatul final este ceea ce este tipărit. Deci, în cazul în care modulul are nevoie să adauge unele informații la titlul tipărit, se poate înregistra o funcție de filtru „the_title„.

Un alt exemplu este cârligul „de acțiune”, numit „wp_footer„. Chiar înainte de sfârșitul paginii HTML pe care WordPress o generează, se verifică să se vadă dacă vreun modul are funcții înregistrate pentru cârligul de acțiune „wp_footer„, și le rulează pe rând.

Etichete de șabloane

Un alt mod pentru modulul WordPress pentru a adăuga funcționalitate este prin crearea de etichete personalizate de șabloane. Cineva care vrea să folosească modulul poate adăuga aceste „etichete” la tema sa, în bara laterală, în secțiunea de postare a conținutului, sau oriunde este necesar. De exemplu, un modul care adaugă etichete geografice pentru postări ar putea defini o funcție etichetă șablon numită geotag_list_states() pentru bara laterală, care enumeră toate statele cu care postările sunt etichetate, cu linkuri către paginile de arhivă în funcție de stat permise de modul.

Pentru a defini o etichetă șablon personalizată, pur și simplu se scrie o funcție PHP și se documentează pentru utilizatorii modulului pe pagina de start a modulului și/sau în fișierul PHP principal al modulului. E o idee bună atunci când se documentează o funcție să se dea un exemplu despre ceea ce trebuie exact să fie adăugat la fișierul temei pentru a utiliza funcția, inclusiv <?php și ?>.

Salvarea datelor modulului în baza de date

Cele mai multe module WordPress va trebui să obțină unele date de la proprietarul site-ului sau utilizatorii blogului și să le salveze între sesiuni, pentru a fi utilizate în funcțiile sale de filtrare, funcții de acțiune, și funcții șablon. Aceste informații trebuie să fie salvate în baza de date WordPress, pentru a se păstra între sesiuni. Există patru metode de salvare a datelor modulului in baza de date:

1. Folosirea mecanismul „opțiune” WordPress (descris mai jos). Această metodă este adecvată pentru stocarea de cantități relativ mici de date, relativ statice – tipul de date introduse de obicei de proprietarul site-ului la prima configurare a modulului, și rareori schimbate ulterior.
2. Meta Post (Câmpuri personalizate). Ideal pentru date asociate cu postări, pagini, sau atașamente individuale.
3. Taxonomie personalizată. Pentru clasificarea de mesaje sau alte obiecte, cum ar fi utilizatori și comentarii și/sau pentru o listă de date editabile de utilizatori de nume/valori utilizând o taxonomie personalizată, mai ales atunci când doriți să accesați toate mesaje/obiectele asociate cu un termen taxonomic dat.
4. Crearea unui tabel nou, personalizat de baze de date. Această metodă este adecvată pentru datele care nu sunt asociate cu anumite mesaje, pagini, atașamente, sau comentarii – tipul de date care va crește pe măsura trecerii timpului, și care nu au nume individuale.

Mecanismul Opțiuni WordPress

WordPress are un mecanism de salvare, actualizare, și recuperare individuală, piese de date („options”), în baza de date WordPress. Valorile opțiunii pot fi șiruri de caractere, matrice sau obiecte PHP (acestea vor fi „serializate”, sau convertite la un șir, înainte de depozitare, și neserializate când sunt recuperate). Numele opțiuni sunt șiruri de caractere, și trebuie să fie unice, astfel încât acestea să nu intre în conflict fie cu WordPress fie cu alte module.

Este, de asemenea, în general, considerată o idee bună minimizarea numărului de opțiuni pe care le utilizați pentru modul. De exemplu, în loc de a stoca 10 opțiuni cu nume diferite luați în considerare stocarea unei game serializate de 10 elemente ca o singură opțiune cu nume.

Iată principalele funcții pe care un modul le poate utiliza pentru a accesa opțiunile WordPress.

add_option($name, $value, $deprecated, $autoload);

• Creează o nouă opțiune; nu face nimic dacă opțiunea există deja.
• $name
  • Necesar (string). Numele opțiunii trebuie adăugat.
• $value
  • Opțional (mixt), implicit pentru șir gol. Valoarea opțiunii care trebuie stocată.
• $deprecated
  • Opțional (string), nu mai este utilizat de către WordPress, puteți transmite un șir gol sau nul la acest argument, dacă doriți să utilizați următorul parametru $autoload.
• $autoload
  • Opțional, implicit „da” (enum: „da” sau „nu”). Dacă este setat la „da” setarea este preluată automat de către funcția wp_load_alloptions.

get_option($option);

• Extrage o valoare a opțiunii din baza de date.
• $option
  • Necesar (string). Numele opțiunii a cărei valoare doriți să fie returnată.

update_option($option_name, $newvalue);

• Actualizează sau creează o valoare a opțiunii în baza de date (rețineți că add_option nu trebuie să fie apelat în cazul în care nu doriți să utilizați parametrii $deprecated sau $autoload).
• $option_name
  • Necesar (string). Numele opțiunii de actualizat.
• $newvalue
  • Necesar. (string | matrice | obiect) Noua valoare pentru opțiune.

Presupunând că modulul are unele opțiuni stocate în baza de date WordPress, probabil veți dori să aibă un panou de administrare care va permite utilizatorilor modulului să vizualizeze și editeze valorile opțiunii.