Sfaturi finale pentru cele mai bune practici în dezvoltarea WordPress

Bine ați venit în ultima parte a acestei serii. Dacă tocmai ați ajuns, vă rugăm să verificați cele două articole anterioare. Am abordat până în prezent următoarele subiecte:

Sfaturi pentru cele mai bune practici în dezvoltarea WordPress

  • Codurile WordPress Coding
  • Evitarea coliziunilor globale ale spațiilor de nume (prefixul și utilizarea clasei)
  • Codarea comentariilor
  • Securitate

Mai multe sfaturi pentru cele mai bune practici în dezvoltarea WordPress

  • Mod corect pentru a adăuga script-uri și stiluri (înregistrați, enqueue și localizați)
  • Ajax sună
  • Filtre și acțiuni

În acest ultim articol, voi vorbi despre trei lucruri importante care, deși nu afectează funcționarea pluginului, sunt esențiale dacă doriți să furnizați un plugin de calitate.

1. Debugging

Primul lucru pe care ar trebui să-l faceți în timp ce codați un plugin este să activați modul de depanareașa cum recomandă WordPress. Astfel veți vedea toate erorile, avertismentele și problemele.

Pentru a activa modul de depanare un loc simplu în wp-config.php

define ('WP_DEBUG', adevărat);

Odată ce reîncărcați site-ul, veți vedea toate avertismentele și problemele împreună cu alte mesaje, cum ar fi anunțurile de funcții WordPress depreciate. Dacă doriți să furnizați un produs de calitate, asigurați-vă că utilizarea pluginului cu modul de depanare permite sau dezactivează rezultatul în același lucru (fără erori, avertismente sau notificări).

Dacă doriți să salvați erorile într-un fișier și să nu le afișați în codul HTML, puteți adăuga împreună WP_DEBUG următoarele linii.

// toate erorile vor fi salvate într-un fișier jurnal debug.log din directorul / wp-content / define ('WP_DEBUG_LOG', true); // nu afișați erori în HTML define ('WP_DEBUG_DISPLAY', false);

O altă setare de depanare pe care o folosesc o mulțime care salvează toate interogările bazei de date într-o matrice este următoarea:

define ('SAVEQUERIES', true);

De obicei, folosesc toate acestea (în mod special ultima) cu pluginul Debug Bar și consola Debug Bar. Dacă nu le cunoașteți, du-te și luați o copie și începeți depanarea plugin-urilor și a temelor. Veți vedea cât de ușor este să o faceți. 

De asemenea, puteți verifica listele de pluginuri pe care le folosesc pentru dezvoltare în Wp Favs.

2. Documentație

Documentarea fiecărui aspect al pluginului sau al temei vă va ușura mult mai ușor utilizatorii și viața. Ei vor putea face pluginul sau tema să lucreze urmând un ghid sau un videoclip sau o combinație a celor două și veți economisi mult timp cu bilete de suport și e-mailuri nesfârșite.

Vă recomand să împărțiți întreaga documentație în categorii sau secțiuni care sunt cele mai importante:

  • Instalare
  • configurație
  • Utilizare rapidă
  • Probleme comune
  • cerinţe

Apoi, în funcție de temă sau plugin, puteți adăuga restul de secțiuni sau categorii. Dacă verificați pagina de documentare a WordPress Social Invitații veți vedea ce vreau să spun. 

Dacă ați adăugat filtre și cârlige așa cum am menționat în articolul precedent, este o idee bună să creați o pagină de referință Filtru / Acțiuni explicând ce fac.

Ajută la file

Tab-urile de ajutor sunt un alt mod de a oferi ajutor direct utilizatorilor dvs. în plugin, în loc să le redirecționați către site-ul dvs. web. Ele sunt utilizate în mod normal pentru a oferi informații despre ecranul utilizat în acel moment.

De exemplu, pe unul dintre pluginurile mele denumite Social PopUP, folosesc o filă de ajutor pentru a explica codurile scurte disponibile. 

Dacă utilizați o clasă în pluginul dvs. și doriți să adăugați fila de ajutor într-un tip de post particularizat, puteți face ceva de genul:

/ ** * Inițializați pluginul încărcând scripturile și stilurile de admin și adăugând o pagină și un meniu de setări *. * * @ din 1.0.0 * / funcția __construct () [...] // Ajutor Tab add_action ('load-post.php', array ($ this, 'my_admin_add_help_tab'));  / ** * Adăugați fila de ajutor la tipul postului de tip spucpt * @since 1.0 * @return void * / funcția my_admin_add_help_tab () $ screen = get_current_screen (); dacă ('spucpt'! = $ screen-> id) return;  // Adăugați my_help_tab dacă tipul de postare este spucpt $ screen-> add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('Shortcodes'), 'content' => ,));  

Este foarte important să verificați dacă ID-ul curent al ecranului se potrivește cu tipul dvs. de post personalizat sau că fila de ajutor va apărea peste tot.

Dacă ați adăugat în schimb o pagină de opțiuni, ați putea folosi codul folosit ca exemplu în Codex.

add_help_tab (array ('id' => 'my_help_tab', 'title' => __ ('

". __ ("Conținutul descriptiv care se va afișa în tab-ul" My Help Tab "intră aici."). '

',)); ?>

În opinia mea, filele de ajutor nu sunt foarte vizibile pentru utilizatori și majoritatea nu știu chiar că există, dar este o practică bună să includeți câteva linii de ajutor în interiorul pluginului.

3. Internaționalizarea

Internaționalizarea, de asemenea, cunoscută sub numele de i18n (există 18 litere între i și n) este cireasa pe tortul unui plugin sau temă. După cum deja știți că WordPress este folosit de oameni din întreaga lume, la momentul livrării unui plugin sau a unei teme, trebuie să fim siguri că pot traduce cu ușurință în limba lor maternă.

Care este diferența dintre internaționalizare și localizare?

În primul rând, ar trebui să învățăm sensul acestor două cuvinte cunoscute și ca i18n și i10n. Internaționalizarea se referă la procesul de creare a unui plugin sau a unei teme translatabile, în timp ce localizarea este în principiu actul de a face acest lucru.

Cum trateaza WordPress Traducerile?

WordPress utilizează faimoasa bibliotecă gettext care a explicat în câteva cuvinte, putem spune că funcționează astfel:

  • Dezvoltatorii împachetează caracterele translatabile în funcții speciale gettext
  • Instrumente speciale analizează fișierele cu cod sursă și extrage șirurile translatabile în fișierele POT (șabloane de obiecte portabile)
  • Traducătorii traduc fișierele POT și rezultatul este un fișier PO (fișier POT, dar cu traducerile în interior)
  • Fișierele PO sunt compilate în fișierele MO binare, care oferă acces mai rapid la șiruri de date la momentul executării.

Cum putem crea șiruri translatabile?

Primul lucru pe care trebuie să-l faceți este să decideți a text-domeniu care va fi folosit pentru a încheia toate plugin-urile sau traducerile tematice. Domeniul de text trebuie să se potrivească cu plugin-ul tău. 

Există mai multe moduri de a crea șiruri translaționabile, în funcție de situația în care creați variabile, repetați ceva etc. Funcțiile cele mai comune sunt __ ()  și _e () . Să vedem câteva exemple de mai jos:

// crearea unei variabile $ hello = __ ('Bună ziua, Im un șir translatabil', 'meu-text-domain'); echo "

“. __ ("Bună ziua, sunt un șir translatabil", "domeniul meu-text"). '

„; // pentru a face un ecou puteți utiliza _e ('Bună ziua, Im un șir translatabil', 'meu-text-domain'); // Când aveți variabile în șirul pe care îl faceți: printf (__ ('Am șters% d posturi', 'my-text-domain'), $ count); // Sau mai multe variabile printf (__ ('Numele dvs. este% 1 $ s, iar numele dvs. de familie este% 2 $ s.', 'My-text-domain'), $ name, $ lastname);

O altă funcție rece pe care o puteți utiliza este _n () care este folosit pentru plural. Această funcție are 4 argumente:

  • singular - forma singulară a șirului
  • plural - forma plurală a șirului
  • număr - numărul de obiecte, care vor determina dacă singularul sau forma plurală trebuie returnate
  • domeniul de domeniu - plugin-text-domain

Revenind la exemplul nostru precedent, pluralul va arata cam ca:

printf (_n ('Am șters o postare', 'Am șters% d postări', $ count, 'my-text-domain'), $ count);

Dacă, în orice caz, aveți nevoie să traduceți șiruri de caractere în JavaScript, puteți trece toate șirurile folosind wp_localize_script () funcție pe care am discutat-o ​​despre al doilea articol din această serie.

wp_enqueue_script ("script-handle", ...); wp_localize_script ('script-handle', 'objectL10n', array ('alert' => __ (' domeniul meu-text "),));

Activarea traducerilor în pluginurile noastre

Am adăugat deja toate șirul translatabil în jurul plugin-ului nostru și acum este momentul să-l activați. Pentru a face acest lucru faci simplu:

funcția myplugin_init () $ plugin_dir = numele de bază (dirname (__FILE__)); load_plugin_textdomain ('meu-text-domain', false, $ plugin_dir);  add_action ("plugins_loaded", "myplugin_init");

Această bucată de cod va încerca să încarce din rădăcina pluginului dvs. un fișier MO numit mi-text-domeniu-Localizare.mo . În funcție de setările de limbă din wp-config.php, partea locale va fi înlocuită cu codul dvs. de limbă. De exemplu, dacă eu wp-config.php este configurat ca:

definiți ("WPLANG", "es_ES");

Fișierul care urmează să fie încărcat este my-text-domain-es_ES.mo. Pentru teme este destul de asemănătoare, trebuie doar să includeți în functions.php următoarele:

load_theme_textdomain ('my_theme_textdomain');

principala diferență este că această funcție va căuta Localizare .mo in loc de my_theme_textdomain- localizare .mo după cum am văzut în exemplul anterior.

Puteți citi mai multe despre l18n în Codul WordPress.

Concluzie

Suntem la sfârșitul acestei serii și sper că v-ați bucurat să citiți cât de mult am scris-o. Așa cum am spus mai devreme, am scris această serie de gândire despre începuturile mele ca dezvoltator. Am încercat să colectez toate informațiile pe care le consider importante pentru a face un bun plugin, rezumând pe scară largă tot ceea ce a fost deja explicat în Cod. Deși probabil am renunțat foarte mult, cred că este suficient să ai o bază solidă.

Mi-ar plăcea să vă văd împărtășiți gândurile, sfaturile și ideile pentru o dezvoltare solidă în comentarii.

Cod