Cele mai frecvente 10 greșeli pe care le fac dezvoltatorii WordPress

Suntem doar oameni, iar una dintre trăsăturile de a fi om este că facem greșeli. Pe de altă parte, ne autocorectăm, ceea ce înseamnă că avem tendința de a învăța din greșelile noastre și, sperăm, că astfel putem evita să facem aceleași de două ori. Multe dintre greșelile pe care le-am făcut în domeniul WordPress provin din încercarea de a economisi timp la implementarea soluțiilor. Cu toate acestea, de obicei, acestea își vor ridica capul pe drum când ar apărea probleme ca urmare a acestei abordări. A face greșeli este inevitabil. Cu toate acestea, a învăța din neglijările altora (și pe ale tale, desigur!) este un drum pe care ar trebui să îl urmezi în mod proactiv.

Greșeala comună nr. 1: menținerea depanării oprită

De ce ar trebui să folosesc depanarea când codul meu funcționează bine? Depanarea este o caracteristică încorporată în WordPress care va face ca toate erorile, avertismentele și notificările PHP (despre funcțiile depreciate etc.) să fie afișate. Când depanarea este dezactivată, pot fi generate avertismente sau notificări importante pe care nu le vedem niciodată, dar care ar putea cauza probleme mai târziu dacă nu le rezolvăm la timp. Vrem ca codul nostru să se joace frumos cu toate celelalte elemente ale site-ului nostru. Deci, atunci când adăugați orice cod personalizat nou la WordPress, ar trebui să vă faceți întotdeauna munca de dezvoltare cu depanarea activată (dar asigurați-vă că îl dezactivați înainte de a implementa site-ul în producție!).

Pentru a activa această caracteristică, va trebui să editați fișierul wp-config.php din directorul rădăcină al instalării WordPress. Iată un fragment dintr-un fișier tipic:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Aceasta nu este o listă exhaustivă de opțiuni de configurare care pot fi utilizate, dar această configurare sugerată ar trebui să fie suficientă pentru majoritatea nevoilor de depanare.

Greșeala comună nr. 2: Adăugarea de scripturi și stiluri folosind wp_head Hook

Ce este greșit cu adăugarea scripturilor în șablonul meu antet? WordPress include deja o multitudine de scripturi populare. Cu toate acestea, mulți dezvoltatori vor adăuga scripturi suplimentare folosind cârligul wp_head . Acest lucru poate duce la același script, dar o versiune diferită, încărcată de mai multe ori.

Încheierea aici vine în ajutor, care este modalitatea prietenoasă cu WordPress de a adăuga scripturi și stiluri pe site-ul nostru. Folosim punerea în coadă pentru a preveni conflictele de plugin și pentru a gestiona orice dependențe pe care le-ar putea avea un script. Acest lucru se realizează prin utilizarea funcțiilor încorporate wp_enqueue_script sau wp_enqueue_style pentru a pune scripturi și, respectiv, stiluri. Principala diferență dintre cele două funcții este că cu wp_enqueue_script avem un parametru suplimentar care ne permite să mutăm scriptul în subsolul paginii.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Dacă scriptul nu este necesar pentru a reda conținutul deasupra foldului, îl putem muta în siguranță la subsol pentru a ne asigura că conținutul de deasupra foldului se încarcă rapid. Este o practică bună să înregistrați mai întâi scriptul înainte de a-l pune în coadă, deoarece acest lucru le permite altora să vă anuleze scriptul prin intermediul mânerului din propriile plugin-uri, fără a modifica codul de bază al pluginului dvs. În plus, dacă mânerul unui script înregistrat este listat în matricea de dependențe ale unui alt script care a fost pus în coadă, acel script va fi încărcat automat înainte de încărcarea acelui script evidențiat pus în coadă.

Greșeala comună nr. 3: evitarea temelor pentru copii și modificarea fișierelor de bază WordPress

Creați întotdeauna o temă secundară dacă intenționați să modificați o temă. Unii dezvoltatori vor face modificări la fișierele temei părinte doar pentru a descoperi după o actualizare a temei că modificările lor au fost suprascrise și pierdute pentru totdeauna.

Pentru a crea o temă copil, plasați un fișier style.css într-un subdirector al folderului temei copil, cu următorul conținut:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

Exemplul de mai sus creează o temă copil bazată pe tema WordPress implicită, Twenty Sixteen . Cea mai importantă linie a acestui cod este cea care conține cuvântul „Șablon” care trebuie să se potrivească cu numele de director al temei părinte din care clonați copilul.

Aceleași principii se aplică fișierelor de bază WordPress: nu luați calea ușoară modificând fișierele de bază. Depuneți acest efort suplimentar utilizând funcții și filtre conectabile WordPress pentru a preveni suprascrierea modificărilor după o actualizare WordPress. Funcțiile conectabile vă permit să suprascrieți unele funcții de bază, dar această metodă este treptat eliminată și înlocuită cu filtre. Filtrele obțin același rezultat final și sunt inserate la sfârșitul funcțiilor WordPress pentru a permite modificarea rezultatelor lor. Un truc este să împachetați întotdeauna funcțiile cu if ( !function_exists() ) când utilizați funcții conectabile, deoarece mai multe plugin-uri care încearcă să suprascrie aceeași funcție conectabilă fără acest wrapper va produce o eroare fatală.

Greșeala comună nr. 4: codificarea valorilor

Adesea, pare mai rapid să codificați o valoare (cum ar fi o adresă URL) undeva în cod, dar timpul petrecut pe drum de depanare și remediere a problemelor care apar ca urmare a acestui lucru este mult mai mare. Folosind funcția corespunzătoare pentru a genera dinamic rezultatul dorit, simplificăm foarte mult întreținerea și depanarea ulterioară a codului nostru. De exemplu, dacă migrați site-ul dvs. dintr-un mediu de testare în producție cu adrese URL codificate, dintr-o dată veți observa că site-ul dvs. nu funcționează. Acesta este motivul pentru care ar trebui să folosim funcții, cum ar fi cea enumerată mai jos, pentru a genera căi de fișiere și link-uri:

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Un alt exemplu prost de hardcoding este atunci când scrieți interogări personalizate. De exemplu, ca măsură de securitate, schimbăm prefixul implicit pentru datatable WordPress din wp_ în ceva mai unic, cum ar fi wp743_ . Interogările noastre vor eșua dacă vom muta vreodată instalarea WordPress, deoarece prefixele de tabel se pot schimba între medii. Pentru a preveni acest lucru, putem face referire la proprietățile tabelului ale clasei wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Observați cum nu folosesc valoarea wp_users pentru numele tabelului, ci, în schimb, las WordPress să rezolve. Utilizarea acestor proprietăți pentru generarea numelor de tabel ne va ajuta să ne asigurăm că returnăm rezultatele corecte.

Greșeala comună nr. 5: Nu împiedicați site-ul dvs. să fie indexat

De ce nu aș vrea ca motoarele de căutare să-mi indexeze site-ul? Indexarea este bună, nu? Ei bine, atunci când construiești un site web, nu vrei ca motoarele de căutare să indexeze site-ul tău până când nu ai terminat de construit și nu ai stabilit o structură de permalink. În plus, dacă aveți un server de staging unde testați upgrade-urile site-ului, nu doriți ca motoarele de căutare precum Google să indexeze aceste pagini duplicat. Când există mai multe bucăți de conținut care nu se pot distinge, este dificil pentru motoarele de căutare să decidă care versiune este mai relevantă pentru o interogare de căutare. În astfel de cazuri, motoarele de căutare vor penaliza site-urile cu conținut duplicat, iar site-ul dvs. va avea de suferit în clasamentul căutării ca urmare a acestui fapt.

După cum se arată mai jos, Setările de citire WordPress au o casetă de selectare care scrie „Descurajați motoarele de căutare de la indexarea acestui site”, deși aceasta conține un element important de remarcat dedesubt care afirmă că „Devine motoarele de căutare să onoreze această solicitare”.

Rețineți că motoarele de căutare adesea nu onorează această solicitare. Prin urmare, dacă doriți să împiedicați în mod fiabil motoarele de căutare să vă indexeze site-ul, editați fișierul .htaccess și introduceți următoarea linie:

 Header set X-Robots-Tag "noindex, nofollow"

Greșeala comună nr. 6: Nu se verifică dacă un plugin este activ

De ce ar trebui să verific dacă există o funcție de plugin dacă pluginul meu este întotdeauna pornit? Cu siguranță, 99% din timp pluginul tău va fi activ. Cu toate acestea, cum rămâne cu acel 1% din timp când din anumite motive a fost dezactivat? Dacă și când se întâmplă acest lucru, site-ul dvs. web va afișa probabil câteva erori PHP urâte. Pentru a preveni acest lucru, putem verifica dacă pluginul este activ înainte de a-i apela funcțiile. Dacă funcția plugin este apelată prin front-end, trebuie să includem biblioteca plugin.php pentru a apela funcția is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Această tehnică este de obicei destul de fiabilă. Cu toate acestea, ar putea exista cazuri în care autorul a schimbat numele directorului principal al pluginului. O metodă mai robustă ar fi verificarea existenței unei clase în plugin:

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

Este mai puțin probabil ca autorii să schimbe numele clasei unui plugin, așa că, în general, aș recomanda utilizarea acestei metode.

Greșeala comună nr. 7: încărcarea prea multor resurse

De ce ar trebui să fim selectivi în încărcarea resurselor de plugin pentru pagini? Nu există niciun motiv valid pentru a încărca stiluri și scripturi pentru un plugin dacă acel plugin nu este utilizat pe pagina la care a navigat utilizatorul. Încărcând fișierele plugin numai atunci când este necesar, putem reduce timpul de încărcare a paginii, ceea ce va avea ca rezultat o experiență îmbunătățită a utilizatorului final. Luați, de exemplu, un site WooCommerce, unde vrem doar ca pluginul să fie încărcat pe paginile noastre de cumpărături. Într-un astfel de caz, putem elimina în mod selectiv orice fișiere de la încărcare pe toate paginile celorlalte site-uri pentru a reduce balonarea. Putem adăuga următorul cod la fișierul functions.php al temei sau al pluginului:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Scripturile pot fi eliminate cu funcția wp_dequeue_script($handle) prin intermediul handle-ului cu care au fost înregistrate. În mod similar, wp_dequeue_style($handle) va împiedica încărcarea foilor de stil. Cu toate acestea, dacă acest lucru este prea dificil de implementat pentru dvs., puteți instala Plugin Organizer care oferă posibilitatea de a încărca pluginuri selectiv pe baza anumitor criterii, cum ar fi tipul de postare sau numele paginii. Este o idee bună să dezactivați orice plugin de stocare în cache, cum ar fi W3Cache, pe care este posibil să le fi activat pentru a nu mai fi nevoit să reîmprospătați memoria cache în mod constant pentru a reflecta orice modificări pe care le-ați făcut.

Greșeala comună nr. 8: păstrarea barei de administrare

Nu pot lăsa bara de administrare WordPress vizibilă pentru toată lumea? Ei bine, da, ați putea permite utilizatorilor dvs. accesul la paginile de administrare. Cu toate acestea, de multe ori aceste pagini nu se integrează vizual cu tema aleasă și nu oferă o integrare perfectă. Dacă doriți ca site-ul dvs. să arate profesional, ar trebui să dezactivați bara de administrare și să furnizați o pagină de gestionare a contului frontal proprie:

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Codul de mai sus, atunci când este copiat în fișierul functions.php al temei dvs., va afișa numai bara de administrare pentru administratorii site-ului. Puteți adăuga oricare dintre rolurile sau capabilitățile utilizatorului WordPress în funcția current_user_can($capability) pentru a exclude utilizatorii să vadă bara de administrare.

Greșeala comună nr. 9: Nu se utilizează filtrul GetText

Pot folosi CSS sau JavaScript pentru a schimba eticheta unui buton, ce este în neregulă cu asta? Ei bine, da, poți. Cu toate acestea, adăugați cod de prisos și timp suplimentar pentru a reda butonul, atunci când puteți utiliza unul dintre cele mai utile filtre din WordPress, numit gettext . În combinație cu domeniul text al unui textdomain , un identificator unic care asigură că WordPress poate face distincția între toate traducerile încărcate, putem folosi filtrul gettext pentru a modifica textul înainte ca pagina să fie redată. Dacă căutați codul sursă pentru funcția load_plugin_textdomain($domain) , acesta vă va oferi numele de domeniu de care avem nevoie pentru a înlocui textul în cauză. Orice plugin de renume se va asigura că domeniul textdomain pentru un plugin este setat la inițializarea pluginului. Dacă doriți să schimbați text dintr-o temă, căutați linia de cod load_theme_textdomain($domain) . Folosind WooCommerce încă o dată ca exemplu, putem schimba textul care apare pentru titlul „Produse înrudite”. Introduceți următorul cod în fișierul functions.php al temei dvs.:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Acest cârlig de filtru este aplicat textului tradus de către funcțiile de internaționalizare __() și _e() , atâta timp cât domeniul textdomain este setat prin intermediul funcțiilor menționate mai sus.

 _e( 'Related Products', 'woocommerce' );

Căutați în pluginuri aceste funcții de internaționalizare pentru a vedea ce alte șiruri puteți personaliza.

Greșeala comună nr. 10: păstrarea permalink-urilor implicite

În mod implicit, WordPress folosește un șir de interogare cu ID-ul postării pentru a returna conținutul specificat. Cu toate acestea, acest lucru nu este ușor de utilizat și utilizatorii pot elimina părți relevante ale adresei URL atunci când o copiază. Mai important, aceste permalink-uri implicite nu folosesc o structură prietenoasă pentru motoarele de căutare. Activarea a ceea ce numim permalinkuri „drăguțe” ne va asigura că URL-urile noastre conțin cuvinte cheie relevante din titlul postării pentru a îmbunătăți performanța în clasamentul motoarelor de căutare. Poate fi o sarcină destul de descurajantă să îți modifici retroactiv permalinkurile, mai ales dacă site-ul tău rulează o perioadă semnificativă de timp și ai sute de postări deja indexate de motoarele de căutare. Deci, după ce ați instalat WordPress, asigurați-vă că vă schimbați prompt structura permalink-urilor în ceva mai ușor de utilizat pentru motoarele de căutare decât doar un ID de postare. În general, folosesc numele postării pentru majoritatea site-urilor pe care le construiesc, dar puteți personaliza permalink-ul în orice format doriți, folosind etichetele disponibile de structură permalink.

Concluzie

Acest articol nu este în niciun caz o listă exhaustivă a greșelilor făcute de dezvoltatorii WordPress. Dacă există un lucru pe care ar trebui să îl iei din acest articol, totuși, este că nu ar trebui să iei niciodată scurtături (și asta este adevărat în orice platformă de dezvoltare, nu doar în WordPress!). Timpul economisit acum de practicile slabe de programare va reveni să vă bântuie mai târziu. Simțiți-vă liber să ne împărtășiți câteva greșeli pe care le-ați făcut în trecut și, mai important, orice lecții învățate, lăsând un comentariu mai jos.