Cele mai grave 12 greșeli pe care le fac dezvoltatorii WordPress avansați

WordPress este o modalitate foarte populară de a pune în funcțiune rapid un site. Cu toate acestea, în graba lor, mulți dezvoltatori ajung să ia decizii oribile. Unele greșeli, cum ar fi lăsarea WP_DEBUG setat la true , pot fi ușor de făcut. Altele, cum ar fi gruparea întregului JavaScript într-un singur fișier, sunt la fel de comune ca inginerii leneși. Indiferent de greșeală pe care reușiți să o faceți, citiți mai departe pentru a afla cele mai comune 12 greșeli WordPress pe care le fac dezvoltatorii noi și experimentați. Dacă te trezești că comiți una dintre aceste greșeli, nu dispera. Fiecare greșeală este o oportunitate de a învăța.

1. Plasarea codului JavaScript al temei WordPress într-un singur fișier principal

Odată, în timp ce făceam optimizarea vitezei paginii pentru site-urile web ale unui client, am observat că foloseau o temă premium care avea toate bibliotecile pe care le foloseau, inclusiv codul personalizat, într-un singur fișier numit main.js , theme.js sau custom.js . Această practică este proastă din următoarele motive:

1. Fișierul, în timp, poate deveni foarte mare, deoarece tema, fiind dezvoltată în mod activ, va crește în funcții și uneori veți vedea fișiere cu dimensiunea de 1 MB. Fișierul va fi încărcat pe tot site-ul chiar dacă doar 10% din codul din fișier este necesar în unele pagini. Acest lucru va face ca paginile să dureze mai mult pentru descărcare și mai lent pentru a reda, mai ales dacă este vorba de un cod de blocare a randării din secțiunea de cap a paginii.
2. Face gestionarea codului din interiorul fișierului mai dificilă, deoarece nu puteți utiliza funcții precum wp_dequeue_script() pentru a descărca o parte din codul din unele pagini fie pentru a îmbunătăți viteza paginii, fie pentru a preveni un conflict cu alt cod JavaScript care ar putea fi încărcat de unul dintre pluginurile active. Sigur, fișierul poate fi împărțit în mai multe și pus în coadă în WordPress, dar dacă, la un moment dat, administratorul site-ului web realizează o actualizare a fișierului main.js al temei, atunci întregul proces trebuie să înceapă de la capăt.

2. Utilizarea numelor prea comune pentru variabile, funcții, constante sau clase

Când dezvoltați un plugin, este mai bine să utilizați o convenție de denumire care să prevină conflictul de cod în cazul în care există alte pluginuri care folosesc același nume. De aceea, mulți dezvoltatori își prefixează variabilele și numele funcțiilor ceva unic și legat de pluginul în sine. Pe lângă eliminarea conflictului de cod, face și lucrurile mai ușor de găsit atunci când aveți o mulțime de pluginuri activate.

Există, pe de altă parte, dezvoltatori care preferă să folosească spațiile de nume PHP pentru a încapsula elemente și a rezolva cele două probleme pe care le întâmpină autorii de biblioteci și aplicații atunci când creează elemente de cod reutilizabile, cum ar fi clase sau funcții:

1. Ciocniri de nume între codul pe care îl creează și clasele, funcțiile sau constantele PHP interne sau terțe
2. Abilitatea de a alias (sau de a scurta) Extra_Long_Names conceput pentru a rezolva prima problemă sau pentru a îmbunătăți lizibilitatea codului sursă. Acesta este preferatul meu, deoarece dezvolt adesea teme sau plugin-uri care au mult cod. Cu aceasta, pot citi și gestiona codul cu ușurință, fără a fi nevoit să-mi fac multe griji pentru a avea nume lungi unice.

Aș recomanda o bună înțelegere a spațiilor de nume înainte de a le folosi, deoarece acestea pot fi adesea folosite în mod greșit.

În funcție de proiectul pe care îl veți lua la bord, este probabil să fiți nevoit să rămâneți cu stilul de codare existent, cu excepția cazului în care munca dvs. este în mare parte separată de cea existentă. În cazul în care trebuie să extindeți un plugin sau o temă existentă care urmează deja standardele de codare PHP pentru WordPress, atunci cel mai bine este să rămâneți cu ele pentru a avea un stil consistent, astfel încât codul să devină curat și ușor de citit. Rețineți că unele reguli sunt aplicate universal pentru a îmbunătăți performanța, fără a ține cont de stilul de codare. De exemplu, este întotdeauna cel mai bine să folosiți ghilimele simple (în loc de cele duble) dacă nu evaluați nimic din șir. De asemenea, codul trebuie să fie indentat pentru a fi citit, mai ales dacă are cod imbricat (de exemplu, IF -uri în IF -uri, FOREACH uri imbricate și FOR -uri).

3. Nu valorificați funcționalitatea de bază WordPress existente la adevăratul său potențial

Deoarece WordPress vine cu o suită de biblioteci actualizate în mod regulat care pot fi apelate doar în pluginurile și temele noastre, cel mai bine este să folosiți cât mai mult posibil funcționalitatea de bază existentă. Am văzut teme și pluginuri WordPress care aveau fișiere în directorul lor de active care erau deja în fișierele de bază ale WordPress (de exemplu, jQuery sau Color Picker). Pe lângă faptul că pachetul va deveni mai mare și va dura mai mult să se încarce prin rețea, trebuie să vă asigurați și că toate bibliotecile terțe sunt actualizate în mod regulat, ceea ce este doar un alt lucru de care trebuie să aveți grijă.

Profitați de ceea ce WordPress are deja de oferit, deoarece bibliotecile sunt deja actualizate de echipa de bază de dezvoltare WordPress și puteți avea un proiect ușor și mai ușor de întreținut. Făcând în mod regulat actualizări WordPress, aveți acces la mai multe funcții (fie că este un plugin, o temă sau nucleul WordPress în sine, deoarece tabloul de bord este îmbunătățit constant) și faceți site-ul web mai sigur în cazul în care se găsesc vulnerabilități în versiunile de cod vechi.

4. Nu face ca pluginul sau tema să fie ușor de modificat prin acțiuni și filtre

Editarea directă a unui plugin sau a unei teme WordPress este o idee proastă, cu excepția cazului în care, desigur, sunteți direct implicat în dezvoltarea acelui pachet și contribuiți la codul acestuia. Dacă se realizează o actualizare automată a pluginului sau a temei, atunci orice modificare directă a pachetului se va pierde și va trebui să editați fișierele din nou.

De aceea, utilizarea acțiunilor și a filtrelor, precum și crearea unei teme Child (care extinde tema părinte) sunt cele mai eficiente abordări pentru modificarea unei teme, deoarece puteți modifica funcționalitatea existentă fără a edita tema părinte sau pluginul în sine. Mai mult decât atât, dacă oferiți un plugin pentru descărcare gratuită pe WordPress.org și mai târziu doriți să creați o extensie premium care ar depinde de pluginul părinte, atunci ar trebui să dezvoltați pluginul gratuit în așa fel încât să fi ușor de extins și de a adăuga extensii premium.

5. Dezvoltarea cu WP_DEBUG Setat la false

În mod implicit, constanta WP_DEBUG este setată la „false” pentru a evita tipărirea oricăror erori PHP, avertismente și notificări. Într-un mediu live, aceasta este o alegere recomandată, deoarece menține căile și scripturile de server private ascunse de vizualizarea publică, ceea ce este grozav din motive de securitate. Cu toate acestea, în timpul etapei de dezvoltare, cel mai bine este să îl setați la „adevărat”, deoarece ne va anunța despre orice eroare din codul nostru. Chiar dacă erorile nu afectează în mod direct funcționalitatea, de multe ori vă va forța să scrieți un cod mai bun și să dezvoltați obiceiuri de codare mai bune. Mi s-a intamplat. Acest lucru va asigura, de asemenea, că pluginul sau tema pe care o dezvoltați nu generează erori PHP în nicio instalare WordPress.

Deși este ceva ce fac cei mai mulți dezvoltatori experimentați, se întâmplă, mai ales în grabă. Indiferent cât de urgentă este munca, dezvoltatorii ar trebui să încerce întotdeauna să mențină standardele de codare WordPress, cu un ochi evident pe cele mai bune practici PHP.

6. Scrierea codului PHP fără a lua în considerare faptul că pagina ar putea fi stocată în cache într-o zi

Aceasta este o greșeală PHP obișnuită și, ca și cea anterioară, este relativ ușor de evitat dacă respectați standardele de codare PHP.

Unii dezvoltatori au obiceiul de a implementa fragmente PHP în teme și pluginuri care sunt valabile numai dacă codul PHP este declanșat tot timpul. De exemplu, o funcție PHP care răspunde la Agentul utilizator HTTP cu anumite acțiuni ar trebui să fie întreprinsă sau nu (de exemplu, introducerea în coadă de scripturi care sunt destinate numai utilizatorilor de telefonie mobilă).

Dacă clientul dvs. instalează un plugin care memorează în cache pagina (de exemplu, W3 Total Cache sau WP Rocket) fără a declanșa condiționalele din tema sau pluginurile dvs., codul dvs. PHP va fi redat inutil. Dacă intenția este de a face paginile receptive, atunci acest lucru ar trebui făcut pe partea front-end prin interogări media și JavaScript. Acesta din urmă, doar dacă este cu adevărat necesar. În mod ideal, doriți să evitați utilizarea JavaScript pentru a face site-ul dvs. receptiv.

7. Nu urmăriți modificările efectuate într-un mod profesional printr-un sistem de control al versiunilor, cum ar fi Git

Fișierele care sunt codificate personalizat, cum ar fi o temă copil sau un plugin personalizat, ar trebui să fie în mod ideal sub controlul versiunii. Git creează o înregistrare a ceea ce a fost schimbat și permite dezvoltatorilor să lucreze împreună la același proiect WordPress sau să revină cu ușurință la o versiune anterioară ori de câte ori ceva nu merge bine cu site-ul. Mai mult, clienții pot folosi Git pentru a ține evidența întregului istoric de lucru care a fost realizat de toți dezvoltatorii care au fost angajați pentru acel proiect anume, mai ales dacă era un site web personalizat WordPress mare, pe termen lung.

Deși poate fi intimidant la început, în special pentru dezvoltatorii juniori, înțelegerea Git va merita timpul și un software Git GUI, cum ar fi SourceTree (unul dintre preferatele mele) ar fi pur și simplu modul în care interacționați cu depozitele dvs. Git, făcând întregul curba de învățare mai plăcută. Odată ce înțelegeți cum funcționează, luați în considerare verificarea celor mai bune practici și sfaturi Git de la Toptal Developers, care explică mai în profunzime câteva moduri de utilizare a Git.

8. Pune în coadă fișierele CSS și JavaScript atunci când acestea nu sunt necesare

Dacă aveți multe solicitări HTTP, site-ul web ar fi mai lent la încărcare, având astfel un scor mai mic în Google PageSpeed, ceea ce ar afecta probabil clasarea căutării. De asemenea, ar putea duce la erori JavaScript din cauza conflictelor dintre pluginuri. De exemplu, ar putea exista două plugin-uri care folosesc o bibliotecă jQuery comună, care poate fi încărcată de două ori și ar putea cauza probleme. Și într-adevăr, acesta este cel mai bun exemplu, deoarece jQuery este foarte frecvent încărcat pe site-urile web live de mai multe ori. Acest lucru se întâmplă probabil din cauza pluginurilor sau temelor scrise prost.

9. Utilizarea fișierelor .php pentru a scoate codul CSS sau JavaScript în loc de fișiere statice .css și .js

Am văzut teme și chiar pluginuri WordPress care aveau fișiere precum style.php care erau folosite doar pentru a genera cod CSS personalizat și pentru a-l imprima. Lucruri precum culorile, dimensiunile fonturilor și spațierea în jurul elementelor au fost setate în setările temei și apoi salvate în baza de date. Apoi este citit style.php (de exemplu, <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) și generează codul CSS pe baza setărilor personalizate care au fost actualizate în tabloul de bord.

Aceasta este într-adevăr o practică proastă în ceea ce privește performanța WordPress. Iată principalele dezavantaje care vin cu el:

1. Deoarece fișierul CSS se încarcă în eticheta head (ceea ce este normal și majoritatea se încarcă astfel), există o problemă de performanță care vine cu aceasta, deoarece browserul trebuie să descarce complet fișierul înainte de a randa pagina. Dacă mediul WordPress este lent din cauza unor plugin-uri, atunci acest lucru va întârzia considerabil timpul de încărcare. Chiar dacă sunt folosite tehnici de stocare în cache sau doar o parte din mediul WordPress este încărcat pentru a prelua valorile din baza de date. Cel mai bine este să utilizați un fișier .css static.
2. În fișierul PHP, codul (reguli CSS amestecate cu variabile PHP și clauze condiționale) va fi mai greu de citit de către dezvoltatori atunci când vor trebui să verifice ceva. Sigur, fișierul poate fi rulat în browser (deși sunt sigur că atunci când este tipărit, nici măcar nu va fi indentat sau frumos) dar dacă aveți o copie locală a proiectului și răsfoiți prin codul temei și aveți nevoie pentru a găsi o sintaxă CSS sau JavaScript (în cazul în care ar fi folosit script.php), atunci ar îngreuna lizibilitatea.

Soluția: Salvați orice CSS personalizat în afara directorului pluginului. Exemplu: /wp-content/uploads/theme-name-custom-css/style-5.css . În acest fel, în cazul în care tema sau pluginul sunt actualizate, atunci fișierul personalizat nu se va pierde.

10. Nu folosiți arhitectura potrivită (organizarea codului) pentru pluginurile și temele WordPress

În funcție de dimensiunea și natura pluginului (de exemplu, un plugin independent sau o extensie de plugin care funcționează numai dacă este activat un plugin principal, cum ar fi WooCommerce), trebuie configurată arhitectura și organizarea codului potrivite.

Dacă trebuie să creați un plugin WordPress cu un singur scop pentru un client și are o interacțiune limitată cu nucleul WordPress, teme și alte plugin-uri, nu este eficient să proiectați clase complexe decât dacă sunteți sigur că pluginul se va extinde considerabil mai târziu. pe.

Dacă pluginul va fi prezentat bogat cu mult cod, atunci ar avea sens utilizarea unei abordări de codare de programare orientată pe obiecte (OOP) (având o mulțime de clase). De exemplu, dacă aveți o mulțime de coduri scurte, le puteți păstra pe toate într-un fișier de clasă separat, cum ar fi class.shortcodes.php sau dacă există fișiere CSS și JavaScript care sunt menite să fie încărcate în tabloul de bord și vizualizarea front-end apoi o clasă precum class.scripts.php poate fi folosită și pune în coadă fișierele front-end într-o metodă precum enqueue_public_scripts() în timp ce se pune în coadă fișierele menite să se încarce în zona de administrare în cadrul enqueue_admin_scripts() .

În loc să amestecați codul HTML cu codul PHP, este mai bine să îl păstrați separat prin implementarea modelului MVC în pluginuri și teme. Un bun exemplu este pluginul WooCommerce. Are șabloane pentru diverse machete care pot fi, de asemenea, suprascrise cu ușurință prin temă sau diferite filtre doar pentru că logica este separată de design. Șablonul care conține aspectul HTML este utilizat în principal pentru tipărirea informațiilor deja procesate. A avea cod HTML în cadrul metodelor PHP este de obicei o practică proastă (există, desigur, excepții pentru bucăți mici de cod HTML), în special pentru un plugin care este întreținut de mai mulți dezvoltatori pe măsură ce crește în dimensiune.

Conform manualului WordPress Plugin, deși există o serie de modele de arhitectură posibile, acestea pot fi grupate în trei variante:

• Fișier plugin unic, care conține funcții
• Fișier plugin unic, care conține o clasă, un obiect instanțiat și, opțional, funcții
• Fișierul principal de plugin, apoi unul sau mai multe fișiere de clasă

11. Nu luați în serios securitatea WordPress atunci când scrieți cod

Securitatea nu este adesea luată în serios în dezvoltarea WordPress, deoarece mulți dezvoltatori începători se concentrează mai mult pe rezultatele dorite de client. Totul este în regulă până când site-ul web al clientului este spart sau pluginul tău publicat pe WordPress.org are o vulnerabilitate, lăsând mii de site-uri web afectate. Aceste lucruri se întâmplă uneori și chiar și nucleul WordPress s-a confruntat cu un număr destul de mare de vulnerabilități de securitate încă de la începuturile CMS. Este responsabilitatea noastră să o facem cât mai sigură și, în cazul în care se întâmplă ceva, să acționăm prompt și să ne asigurăm că lansăm un patch solid și bine testat.

Unele dintre cele mai importante sfaturi de securitate sunt:

Vulnerabilități XSS: Pentru a evita acest lucru, trebuie făcute două lucruri: igienizarea datelor de intrare și igienizarea datelor de ieșire. În funcție de date și de contextul în care sunt utilizate, există mai multe metode în WordPress pentru a igieniza codul. Nu ar trebui să aveți încredere în nicio dată de intrare și nici în orice date care urmează să fie tipărite. O funcție comună pentru dezinfectarea datelor de intrare este sanitize_text_field() . Verifică caracterele UTF-8 nevalide, convertește un singur caracter < în entități HTML, elimină toate etichetele, elimină întreruperile de linie, tabele și spațiul alb suplimentar și decupează octeți. În ceea ce privește tipărirea datelor, un bun exemplu pentru afișarea link-urilor este funcția esc_url() , care respinge URL-urile invalide, elimină caracterele nevalide și elimină caracterele periculoase.

Preveniți accesul direct la fișierele dvs.: fișierele pot fi accesate direct, deoarece majoritatea gazdelor permit acest lucru. Totuși, dacă acest lucru se întâmplă și codul nu este scris corespunzător pentru a face față, unele erori pot fi tipărite (de exemplu, funcții lipsă sau variabile care nu sunt declarate) care ar conține informații valoroase pentru potențialii atacatori. Un fragment de cod comun pe care îl vedeți adesea în pluginuri și teme este:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Dacă constanta ABSPATH nu este definită (care ar trebui să fie pentru orice instalare WordPress), atunci scriptul va ieși și nu va imprima nimic.

Utilizați nonce: așa cum se precizează în documentația WordPress, un nonce este un „număr folosit o dată” pentru a ajuta la protejarea adreselor URL și a formularelor de anumite tipuri de utilizare greșită, rău intenționată sau de altă natură.

De exemplu, următoarea adresă URL din tabloul de bord ar fi folosită pentru a arunca în gunoi o postare: http://example.com/wp-admin/post.php?post=123&action=trash — Când accesează această adresă URL, WordPress va valida informațiile cookie de autentificare și dacă aveți permisiunea potrivită (de exemplu, sunteți un administrator cu toate privilegiile), acea postare va fi ștearsă.

Ceea ce ar putea face un atacator este să facă browserul dvs. să acceseze acea adresă URL fără știrea dvs., creând un link pe o pagină terță parte, ca în exemplul următor: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Când faceți această solicitare către WordPress, browserul vă va atașa automat cookie-ul de autentificare, iar WordPress va considera solicitarea ca fiind validă.

Atunci apare un nonce, deoarece atacatorul nu va putea obține valoarea nonce (generată pentru administratorul care este de fapt conectat la WordPress) atât de ușor. Noua adresă URL de solicitare ar arăta astfel: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Fără un nonce valid, un răspuns 403 Interzis ar fi trimis browserului de către WordPress cu binecunoscutul mesaj de eroare: „Sunteți sigur că doriți să faceți asta?”

Deși majoritatea oamenilor nu iau în serios securitatea WordPress, gândindu-se că site-ul lor nu va fi piratat niciodată, având încredere în găzduire (ceea ce poate fi de ajutor, dar doar până la un anumit punct) și în faptul că au achiziționat plugin-uri/teme comerciale (care duc adesea presupunând că sunt foarte sigure), ar trebui să facem întotdeauna teste de penetrare pentru site-urile noastre web pentru a identifica vulnerabilitățile exploatabile înainte ca orice hacker să le poată identifica și exploata.

Rețineți că un număr mare de hack-uri nu sunt făcute nici măcar de o singură persoană cu intenția de a vă sparge site-ul. Adesea, există roboți care scanează site-urile WordPress automat în mod constant și în momentul în care se găsește o vulnerabilitate cunoscută, aceasta este exploatată și serverul este folosit pentru spam, obținerea de informații private din baza de date, plasarea de link-uri ascunse în anumite pagini ale site-ului web care ar duce la tot felul de site-uri web suspecte (de exemplu, pornografie, droguri ilicite). Uneori, hack-urile sunt ascunse atât de bine încât aveți nevoie de o scanare adecvată a site-ului dvs. și de a vedea data la care anumite fișiere au fost actualizate pentru a detecta codul piratat. De aceea, este bine să reinstalați WordPress (da, aceeași versiune dacă aveți ultima), astfel încât orice fișiere piratate să fie suprascrise de fișierele de bază WordPress autentice.

12. Utilizarea funcțiilor WordPress și a fragmentelor de cod fără a le înțelege

Adesea, atunci când dezvoltatorii se blochează și găsesc o soluție în locuri precum StackOverflow, ei sunt pur și simplu mulțumiți de faptul că au reușit să facă ceva să funcționeze fără să se deranjeze să înțeleagă logica din spatele codului respectiv sau dacă acel cod poate fi modificat pentru a se încărca mai repede sau a avea mai puțin. linii de cod.

Am văzut această practică de atâtea ori când fragmente de cod sunt copiate în scripturile PHP, când doar o treime din acel cod este folosită efectiv.

Acest lucru poate avea câteva dezavantaje, inclusiv:

1. Codul nu folosește același stil ca și codul de proiect existent. Da, este confortabil să copiați și să lipiți fragmente care funcționează din cutie și, deși sunt bune pentru un proiect personal mic (s-ar putea transforma într-un proiect mare într-o zi, cine știe), această practică nu este adesea bună atunci când vine vorba la lucrări comerciale în care trebuie păstrată o consistență stilului.
2. Deși codul își face treaba, ar putea conține funcții ineficiente care nu sunt recomandate pentru sarcina care trebuie îndeplinită. Dacă codul nu este optimizat, această practică de „copiere și lipire” poate duce la un site web lent și mai greu de întreținut, mai ales dacă se utilizează mai mult de un fragment în diferite locații din cadrul proiectului.
3. Este posibil ca codul să nu fie licențiat pentru reutilizare, iar includerea codului în proiectul unui client îi poate provoca o mulțime de probleme legale.

Îmbunătățire constantă

Toată lumea face greșeli și fiecare greșeală este o oportunitate de a te îmbunătăți. În calitate de dezvoltatori WordPress, industria noastră se mișcă într-un ritm foarte rapid și nu există niciodată un „mod corect” stabilit de a face lucrurile. Cu toate acestea, cu cât exersați și învățați mai mult, cu atât veți deveni mai bun.

Nu ești de acord cu vreuna dintre greșelile pe care le-am subliniat sau crezi că am omis una? Spune-mi în comentarii și vom discuta.