Cele mai frecvente greșeli de dezvoltare a temei WordPress (și cum să le remediați)

Publicat: 2019-05-14

Trimiterea unei teme în directorul de teme WordPress.org este o modalitate excelentă de a vă împărtăși munca și de a contribui la comunitatea WordPress. În prezent, în director există peste 7000 de teme, dintre care cea mai populară depășește 300.000 de instalări active. (Fără a include Twenty____ Themes care sunt ambalate cu WordPress și au un număr de instalări de milioane.)

Înainte de a trimite tema în director, este important să înțelegeți mai întâi procesul de revizuire, deoarece dacă tema dvs. nu îndeplinește aceste cerințe poate fi respinsă pe loc.

Temele care au 3 sau mai multe probleme distincte pot fi închise ca neaprobate. Cu toate acestea, autorii temei pot retrimite tema după ce au corectat problemele.

https://make.wordpress.org/themes/handbook/review/required/

Recenziatorii sunt de partea dvs. și doresc să vă vadă tema difuzată, odată ce aceasta îndeplinește standardele cerute. Dacă tema dvs. are probleme minore care împiedică includerea acesteia în director, recenzentul dvs. va colabora cu dvs. pentru a le remedia.

Din păcate, dacă tema ta are prea multe probleme, va fi închisă ca neaprobată. Dacă decideți să remediați problemele, puteți încărca din nou tema, dar se va alătura în spatele cozii.

Din experiența mea de revizuire a peste 100 de teme, am reușit să identific cele mai frecvente probleme care împiedică aprobarea temelor. Împărtășindu-vă acestea în acest articol, sper că vă pot ajuta să evitați să rămâneți blocat în coadă sau respins.

Încărcarea temei dvs

Când încărcați o temă, aceasta se alătură la coadă pentru a fi revizuită. În medie, va dura două luni pentru ca tema dvs. să ajungă în partea de sus a cozii și să primească prima recenzie. Toți recenzenții sunt voluntari cu timp limitat disponibil pentru a finaliza recenziile. O varietate de factori pot afecta timpul de așteptare. Când mai mulți oameni se oferă voluntar pentru a revizui teme, coada se mișcă rapid. Dimpotrivă, atunci când sunt trimise teme cu o mulțime de probleme, încetinește coada.

Prin trimiterea unei teme care îndeplinește toate cerințele, procesul de revizuire este mult mai ușor și, în cele din urmă, tema dvs. va fi live mai devreme. În acest ghid, vom explora cele mai frecvente probleme care vă vor menține tema în coadă și vor împiedica aprobarea acesteia.

Notă: autorii de teme care au un istoric de trimitere de teme fără probleme pot aplica pentru a deveni „Autori de încredere”.

Probleme de denumire

Când încărcați o temă, prima verificare care este efectuată este să vedeți dacă numele este deja luat. Frecvent vi se va spune că numele pe care l-ați ales este deja luat, chiar dacă nu puteți vedea o temă cu acel nume în director.

Cum ar putea fi asta? Motivul este că testul nu verifică doar directorul, ci se verifică cu întregul ecosistem WordPress. Dacă o temă a fost lansată oriunde (Github, ThemeForest etc.) și are peste 50 de instalări active, numele respectiv nu va fi disponibil pentru utilizare.

Notă: dacă ați lansat tema în altă parte și ați acumulat peste 50 de instalări, puteți utiliza în continuare numele respectiv în director.

Ieșire fără escape

Evaluatorii temelor iau securitatea foarte în serios, există chiar și o resursă dedicată. Un articol întreg ar putea fi scris despre scrierea unor teme sigure, dar în această secțiune vom explora un aspect: evadarea rezultatelor.

Ieșirea fără escape pune în pericol utilizatorii temei dvs. Iată un exemplu de valoare fără escape ($title):

 $title = get_option( 'titlul_meu_personalizat');
ecou '<h2>' . $titlu . „</h2>”;

Problema cu cele de mai sus este că, deși știm ce tip de valoare ar trebui să fie $title, un șir, nu am verificat dacă acesta este cazul.

Dacă un hacker a reușit să schimbe valoarea „my_custom_title” în baza de date, tema ta va scoate acea valoare. Acest lucru prezintă un risc uriaș, deoarece ar putea înlocui rezultatul dorit cu Javascript inline:

 alert('Acesta este periculos');

Soluția este să scape de toate rezultatele pentru a ne asigura că include doar tipul de date pe care le așteptăm.

Exemplul nostru ar putea fi corectat astfel:

 $title = get_option( 'titlul_meu_personalizat');
ecou '<h2>' . esc_html( $titlu ) . „</h2>”;

Dezavantajul utilizării esc_html este că elimină toate etichetele HTML. Dacă $title a inclus caractere aldine sau cursive, de exemplu:

 $title = 'Acest articol este <strong>foarte</strong> util';
echo esc_html( $titlu );

Cuvântul „foarte” nu ar fi îndrăzneț pe front; în schimb, ar scoate codul <strong>foarte</strong>.

Acest lucru ilustrează de ce este important să folosiți funcțiile de evadare corecte pentru context. Dacă ne-am aștepta la ceva HTML în ieșire, ar fi mai bine să folosim wp_kses_post() sau wp_kses() și să setăm parametrul $allowed_html.

Funcțiile care ies, de asemenea, trebuie să fie eliminate:

 <a href="<?php echo esc_url( get_permalink() ); ?>">

Excepție fac funcțiile de bază ale WordPress care includ „the_” în numele lor, acestea fiind, de obicei, deja eliminate.

 function the_permalink( $post = 0 ) {
    /**
     * Filtrează afișarea permalink-ului pentru postarea curentă.
     *
     * @din 1.5.0
     * @din 4.4.0 S-a adăugat parametrul `$post`.
     *
     * @param șir $permalink Permalink-ul pentru postarea curentă.
     * @param int|WP_Post $post ID post, obiect WP_Post sau 0. Implicit 0.
     */
    echo esc_url( apply_filters( 'the_permalink', get_permalink( $post ), $post ) );
}

Text intraductibil

Pentru a fi acceptate în director, toate temele trebuie să fie 100% „pregătite pentru traducere”. Aceasta înseamnă că fiecare șir de text rezultatul temei dvs. trebuie să fie translabil.

WordPress are deja sistemele și funcționalitățile necesare pentru a gestiona procesul de traducere, trebuie doar să vă asigurați că șirurile dvs. folosesc funcțiile corecte.

Deși simplu de implementat, acest lucru este adesea trecut cu vederea, deoarece este contrar modului în care oamenii scriu HTML.

În mod normal, ați putea face ceva de genul acesta:

 <h1>404 - Nu a fost găsit</h1>

Pentru a-l face traducabil, trebuie să adăugați ceva PHP:

 // Funcțiile __ sunt baza localizării.
<h1><?php echo __( '404', 'text-domain'); ?>

// Funcțiile _e fac ecoul valorii.
<h1></?php _e('404', 'text-domain'); ?>

// Escape și ecou șirul.
<h1></?php esc_html_e( '404', 'text-domain' ); ?>

// localizare și variabile.
<h1><?php _n( 'O postare', '%s postări', $count, 'domeniu-text'); ?>

Șirurile ieșite de funcții trebuie să fie, de asemenea, pregătite pentru traducere:

 // nu este gata de traducere :-(
<?php next_posts_link('Inregistrari mai vechi'); ?>

// gata de traducere :-)
<?php next_posts_link( esc_html__( 'Inregistrari mai vechi', 'text-domain' ) ); ?>

Sfat: multe exemple de cod din codex.wordpress.org nu folosesc funcțiile de traducere, așa că aveți grijă când copiați și lipiți.

Așezarea incorectă a resurselor

Fișierele .css și .js pe care le utilizează tema dvs. trebuie puse în coadă utilizând funcțiile corecte: wp_enqueue_style() pentru CSS și wp_enqueue_script() pentru Javascript.

O eroare comună este de a codifica scripturile și stilurile direct în <head> sau înainte de </body>. Există două probleme la această abordare:

1. Imposibil de îndepărtat

Dacă un plugin trebuie să elimine o resursă pe care ați încărcat-o, nu este posibil. Dacă ați fi folosit funcțiile adecvate de coadă, s-ar putea proceda astfel:

 /**
 * Scoateți din coadă tema javascript.
 *
 * Conectat la acțiunea wp_enqueue_scripts, cu o prioritate întârziată (100),
 * astfel încât să fie după ce scriptul a fost pus în coadă.
 */
funcția wptavern_dequeue_script() {
   wp_dequeue_script('scripturi-teme');
}
add_action( 'wp_enqueue_scripts', 'wptavern_dequeue_script', 100 );

2. Încărcare duplicat

Dacă puneți în coadă o resursă, jQuery de exemplu, și un plugin o pune, de asemenea, în coadă, WordPress este suficient de inteligent pentru a o încărca o singură dată.

 /**
 * Puneți în coadă jQuery
 *
 * jQuery va fi încărcat o singură dată, în ciuda celor două cozi.
 * jQuery este împachetat cu WordPress, așa că nu trebuie să specificăm un src. 
 */
funcția wptavern_enqueue_script() {
   wp_enqueue_script('jquery');
   wp_enqueue_script('jquery');
}
add_action( 'wp_enqueue_scripts', 'wptavern_enqueue_script');

Dacă, în schimb, ai fi codificat jQuery în <head>, atunci WordPress nu ar fi de unde să știe și ar fi încărcat de două ori.

Funcționalitatea Plugin-Teritory

Sfera de aplicare a unei teme ar trebui să se ocupe numai de designul și estetica unui site web, toate celelalte funcționalități ar trebui să fie gestionate de WordPress însuși sau de pluginuri.

În încercarea de a adăuga mai multă valoare temelor lor, autorii de teme încearcă adesea să încorporeze funcționalități suplimentare, de exemplu, controale SEO sau tipuri de postări personalizate.

Problema cu gruparea funcționalității într-o temă este că datele nu sunt portabile. Luați controalele SEO ca exemplu, dacă utilizatorul schimbă tema, pierde toată munca pe care a făcut-o pentru a-și optimiza paginile. Spre deosebire de utilizarea unui plugin SEO, datele și funcționalitatea sunt independente de temă și vor fi păstrate la schimbarea temei.

Câteva exemple de funcționalitate plugin-teritoriu:

  • Analytics/Urmărire
  • controale SEO
  • Formulare de contact
  • Shortcodes
  • Blocurile Gutenberg

Sfat: Dacă codul dvs. scrie în baza de date, este foarte probabil să fie teritoriu plugin. Excepția ar fi setările legate de design (poziția barei laterale, culorile etc.).

Fără prefixare

Prefixarea este o modalitate de a vă asigura că codul dvs. nu intră în conflict cu codul de la pluginuri. Spațiul de nume în PHP este o modalitate mai bună de a obține același efect. Cu toate acestea, unii utilizatori încă folosesc versiuni vechi de PHP (5.2) care nu acceptă această caracteristică.

Justin Tadlock a distribuit o listă de lucruri comune care ar trebui să fie prefixate:

  • Nume de funcții PHP.
  • Nume de clase PHP.
  • Variabile globale PHP.
  • Cârlige de acțiune/filtru.
  • Mânere de script.
  • Mânere de stil.
  • Numele dimensiunilor imaginii.

Sursa: https://themereview.co/prefix-all-the-things/

 // exemplu de funcție.
exemplul_prefixul_meu();

// exemplu de clasă.
clasa My_Prefix_Example { … }

// exemplu de acțiune și filtru.
do_action('acțiunea_prefixului_meu');
apply_filters( 'filtrul_prefixul_meu', $valori );

// pune în coadă exemple.
wp_enqueue_script( 'scriptul_prefix_meu', get_template_directory_uri() . '/js/custom-script.js' );
wp_enqueue_style('my_prefix_style', get_template_directory_uri() . '/css/styles.css');

// exemplu de dimensiune a imaginii.
add_image_size('my_prefix_image_size', 220, 180); // 220 pixeli lățime pe 180 pixeli înălțime.

Excepție: atunci când puneți în coadă resurse terță parte, nu adăugați un prefix:

 // pune în coadă un script terță parte (chosen.js).
 wp_enqueue_script( 'ales', get_template_directory_uri() . '/js/chosen.js');

Probleme de licențiere

Tema dvs. și toate fișierele sale trebuie să fie 100% compatibile cu GPL. Acestea includ imagini, biblioteci, scripturi și fonturi.

Toate resursele terțe trebuie să-și listeze informațiile despre sursă și licență.

Această cerință poate fi deosebit de complicată, deoarece nu toate licențele sunt prietenoase cu GPL. Licența Unsplash are o singură restricție:

„Această licență nu include dreptul de a compila fotografii din Unsplash pentru a reproduce un serviciu similar sau concurent.”

Cu toate acestea, această restricție este suficientă pentru a nu-l face compatibil cu GPL și, ca atare, nu veți vedea imagini Unsplash incluse în temele wordpress.org.

O listă de licențe compatibile cu GPL este disponibilă aici – https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Recent, stocksnap.io a fost cea mai comună sursă de imagini din director, deoarece toate imaginile pe care le listează sunt licențiate ca CC0 (compatibile GPL).

Greșeli de captură de ecran

Cerințele indică faptul că captura de ecran ar trebui să fie o reprezentare needitată a temei dvs., care nu arată ca o reclamă. Asta înseamnă că nu există lucrări Photoshop, suprapuneri, chenare sau efecte fanteziste.

De asemenea, imaginile trebuie să respecte aceleași cerințe de licență pe care le-am explorat mai sus.

tema din imagine: Blocksy

Bonus: Utilizați un standard de codare

Un cod care pare ușor de citit și de înțeles pentru dvs., poate fi complet opusul pentru un recenzent care are doar 10-15 minute pentru a vă verifica codul.

Deși nu există nicio cerință cu privire la standardele de codare, următoarele vă fac codul mai ușor de citit, înțeles și întreținut. Eu personal folosesc și recomand „Standardele de codificare WordPress”, deși există și altele.

Utilizarea PHP_CodeSniffer și a setului de reguli WordPress în editorul de cod poate face mult mai ușoară aderarea la un standard – https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

Concluzie

Cerințele temei sunt create ținând cont de utilizatorul final. Evitați să faceți greșelile comune pe care le-am enumerat mai sus și tema dvs. va fi aprobată în cel mai scurt timp. Dacă doriți să experimentați procesul de revizuire din cealaltă parte, puteți chiar să deveniți recenzent.