Cum să abordați dezvoltarea modernă WordPress (Partea 1)

Publicat: 2022-03-11

Nu este un secret că baza de coduri WordPress este o mizerie. Personal, de fiecare dată când trec prin asta, tot ce îmi doresc este să mă ghemuiesc și să plâng. Pe de altă parte, WordPress este cu mult înaintea concurenței sale. Un CMS ușor de utilizat și puternic este o activitate enormă, iar WordPress rămâne popular pentru că oferă acest lucru.

Deci, de ce ne-ar păsa de calitatea codului din nucleul WordPress? Funcționează, nu?

Da, funcționează, iar baza de cod veche de 15 ani este puțin probabil să fie complet refactorizat de către menținătorii săi voluntari. Din păcate, aceasta înseamnă că funcționează și ca un exemplu de codificare „modul WordPress”, scuzând numeroși dezvoltatori pentru că nu respectă cele mai bune practici și tehnicile moderne de dezvoltare. Atât de multe plugin-uri și teme WordPress au cod infam de prost, iar urmărirea orbește practicile moștenite continuă doar tendința.

Dar cui îi pasă de codul prost care încă își face treaba? Ei bine, nimic nu este gratuit și cineva plătește pentru o muncă prost făcută. Cu baza de cod WordPress în sine, menținătorii săi plătesc cu timpul lor, din fericire. Dar cu propriul tău cod, clientul tău este cel care plătește.

Pentru orice sistem chiar și moderat complex, costul dezvoltării inițiale este nesemnificativ în comparație cu costul întreținerii acestuia, iar întreținerea înseamnă și adăugarea de noi funcționalități. Angajarea unui dezvoltator care să repare software-ul prost proiectat și implementat va costa de câteva ori mai mult decât dezvoltarea corectă de la început.

Soluțiile ieftine sunt întotdeauna cele mai scumpe pe termen lung. Sau sunt abandonați după ce rămân fără buget. Economisim banii clienților atunci când respectăm principiile și practicile dovedite de proiectare a software-ului. Aceste metode nu sunt o moft hyped-up, nici o schimbare de dragul schimbării. Înțelepciunea de aici se naște din experiența colectivă a dezvoltatorului, iar urmărirea acesteia dă roade.

Evident, acest lucru nu se aplică sarcinilor cu adevărat simple, cum ar fi adăugarea de câteva linii de CSS sau câteva postări personalizate și rescrieri. Dar adunarea câtorva plugin-uri (sau mai frecvent câteva zeci de plugin-uri) sau crearea unui site bazat pe Visual Composer nu este, oricum, inginerie software.

Acesta nu este un lucru rău, în sine — faptul că unele soluții sunt atât de simple este motivul pentru care WordPress este atât de popular. Dar în această serie voi vorbi despre dezvoltarea WordPress reală : scrierea unui cod PHP, HTML, CSS și JavaScript semnificativ. Voi începe cu fluxul de lucru general și apoi mă voi concentra pe dezvoltarea front-end WordPress în acest articol.

Flux de lucru modern de dezvoltare WordPress

În general, codul de calitate este:

  • Citibil. Este ușor de înțeles ce face codul și de ce.
  • Modular. Blocurile mici de cod cu un scop clar sunt ușor de înțeles, dezvoltat și testat.
  • Reutilizabil. Reutilizarea modulelor deja dezvoltate pentru rezolvarea unor probleme similare accelerează semnificativ dezvoltarea.
  • De întreținut. Modificarea vechilor funcționalități sau introducerea de noi funcții este ușoară.

Principalele rezultate - costuri mai mici de dezvoltare și de proprietate - au multe beneficii derivate pe care nu voi intra aici.

În schimb, mă voi concentra asupra tehnicilor de dezvoltare și a celor mai bune practici care vă pot ajuta să produceți cod de calitate. Să începem cu controlul versiunilor.

Utilizați Controlul versiunilor

Aceasta înseamnă folosirea Git. Din păcate, „codificarea cowboy” în producție prin FTP este aproape încă un lucru. Recent, am lucrat pentru o agenție din Marea Britanie și aveau fișiere cu nume ca acestea pe toată baza de cod:

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

Primul lucru pe care ar trebui să-l faceți atunci când accesați un site WordPress este să îl puneți sub controlul versiunii. Tanking Servers este o retrospectivă amuzantă a greșelilor de dezvoltare WordPress. Ar fi fost foarte ușor să le modifici – și accidente similare care probabil s-au întâmplat tuturor – folosind Git.

Ați greșit codul și întregul site sa defectat? git reset aduce totul înapoi așa cum a fost. Actualizarea versiunii noi a spart totul? git reset funcționează ca o mașină a timpului. Un cod rău intenționat a apărut de nicăieri? git status arată orice fișiere noi, fișiere șterse sau modificări ale oricăror fișiere urmărite. Apoi doar git checkout , restaurând originalele.

Atenție la expunerea folderului .git

OK, este clar important să folosești Git. Dar atunci când o faceți, este la fel de important să evitați să vă expuneți depozitul Git la piratare. Problema apare atunci când aveți foldere .git expuse și vă stocați acreditările în ele.

O instalare standard WordPress se află pe deplin într-un folder web public, iar folderul .git este foarte probabil să fie acolo. Evident, nicio autentificare nu ar trebui să fie stocată în depozitul Git, dar se întâmplă că majoritatea depozitelor conțin unele informații sensibile care nu ar trebui să fie scurse în exterior.

Deci accesul public la folderul .git ar trebui blocat. Dacă utilizați Apache, adăugarea fragmentului de mai jos în partea de sus a fișierului .htaccess va bloca accesul la folderul .git și, de asemenea, la fișierele jurnal. Fișierele jurnal conțin adesea informații sensibile, așa că este înțelept să le faceți și ele indisponibile. Pentru diferite setări de server web, vă rugăm să solicitați ajutor expertului dvs. DevOps.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Utilizați medii separate

Nu faceți dezvoltare pe site-uri live - aceasta este o rețetă pentru timpii de nefuncționare și clienții nemulțumiți. OK, dar cum ar trebui să-l configurați?

În mod ideal, ar trebui să existe trei medii de dezvoltare, cu codul mergând întotdeauna într-o singură direcție: local → punere în scenă → producție. Aceasta este o metodă dovedită pentru evitarea coliziunilor. Toate actualizările de bază, plugin-uri și teme sunt mai întâi efectuate local, apoi testate în staging și, în sfârșit, implementate în producție.

De exemplu, configurația specifică serverului ar putea fi stocată într-un fișier separat. Puteți crea un wp-config-local.php pentru fiecare mediu local și de staging. (Nu uitați să îl adăugați în fișierul dvs. .gitignore !) Apoi adăugați următorul fragment la wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Adesea, cea mai bună modalitate de a configura diferite medii este utilizarea variabilelor de mediu. Dacă nu sunteți familiarizat cu acest concept, vă sfătuiesc să utilizați o soluție modernă completă precum Roots.

Utilizați WP-CLI

Interfața de linie de comandă WordPress (WP-CLI) este un instrument extrem de util pentru administrarea instalărilor WordPress. A avea acces la WP-CLI înseamnă a avea capacitatea de a rula practic orice funcție API WordPress. De exemplu, puteți adăuga, elimina și edita utilizatori și parolele acestora cu WP-CLI. Util dacă tocmai ați moștenit un site și proprietarul sa blocat.

Un alt exemplu este că implementarea inițială este ușoară cu WP-CLI. Acestea pot fi realizate cu câteva comenzi:

  • Descărcarea de bază, teme și pluginuri
  • Cautare si inlocuire in baza de date
  • Adăugarea unui utilizator admin

Mai mult, aceste acțiuni pot fi scriptate și automatizate.

Utilizați Opțiuni avansate de implementare

Vorbind despre automatizare, merită să înveți câteva tehnologii și procese de implementare precum:

  • Integrare continuă/implementare/livrare continuă (CI/CD)
  • Docher
  • Testare automată (inclusiv teste de regresie front-end)

Desigur, trecerea de la a nu folosi controlul versiunilor la a face față cu Docker este un salt uriaș de făcut și va fi probabil copleșitor pentru un proiect WordPress tipic pentru o singură persoană. Este posibil ca unele opțiuni să nu fie posibile, în funcție de furnizorul dvs. de găzduire. Dar implementarea avansată este o necesitate pentru echipe și pentru proiecte mai mari.

Folosiți Liting

Pentru proiecte de orice dimensiune, totuși, scame este un avantaj pentru majoritatea dezvoltatorilor. Litting înseamnă verificarea automată a codului pentru erori. Un IDE complet, cum ar fi PHPStorm, face deja acest lucru imediat; cu toate acestea, editorii mai simpli precum VSCode sau Sublime Text au nevoie de un program dedicat numit linter. O modalitate de a configura aceasta este configurarea editorului pentru a rula un linter ori de câte ori salvați un fișier.

PHP_CodeSniffer este linter-ul de facto pentru PHP. Pe lângă verificarea erorilor de sintaxă, poate verifica și dacă codul dvs. respectă regulile de stil, cum ar fi PSR-2. Acest lucru simplifică foarte mult respectarea standardelor de codare.

Pentru JavaScript, ESLint este un linter popular. Are un set de reguli extins și acceptă configurații personalizate pentru toate aromele și cadrele JavaScript existente.

Un caz de utilizare puternic aici este încorporarea linting-ului într-o conductă de construcție CI/CD, astfel încât tot codul să fie validat automat înainte de a fi implementat.

Tehnici moderne de dezvoltare front-end WordPress

Cu un flux de lucru corect configurat acum pentru proiectul dvs. WordPress general, să ne aruncăm în cele mai bune practici pentru front-end.

Utilizați instrumente moderne: Sass și ES6+

Lumea de dezvoltare front-end este în continuă schimbare și mereu în mișcare. Odată ne-am gândit că Sass este cel mai bun instrument pentru scrierea CSS - și pentru dezvoltarea WordPress pre-Gutenberg, încă este - dar apoi toată lumea a început să vorbească despre CSS-in-JS și despre componentele stilate.

Nici măcar WordPress nu a putut rezista și a preluat câteva dintre acele noi tehnologii. Gutenberg, noul editor de blocuri, este construit pe React și un API REST.

Cu siguranță ar trebui să fiți la curent cu aceste tehnologii front-end de bază:

  • ES6+. Documentația WordPress îl numește ESNext și chiar încurajează utilizarea acestuia.
  • Sass. Folosit de WooCommerce și cel mai bun mod de a scrie CSS dacă nu sunteți încă în chestia CSS-in-JS.
  • Webpack. Chiar și nucleul WordPress folosește Webpack și Babel acum.

ES6 și Sass sunt JavaScript și, respectiv, CSS modern, iar Webpack este un instrument care permite utilizarea tuturor acestor funcții moderne fără a vă face griji cu privire la compatibilitatea cu versiunea anterioară. Webpack poate fi numit un compilator de aplicații front-end care generează fișiere pentru utilizare într-un browser.

Trecerea de la jQuery la Vue.js sau React

Nucleul WordPress și aproape toate pluginurile WordPress depind de jQuery, așa că nu poți să nu-l mai folosești. De fapt, nu are sens să încetezi să-l folosești pentru sarcini simple, cum ar fi ascunderea câtorva <div> -uri sau efectuarea unei cereri AJAX unice când te-ai obișnuit să faci așa. jQuery va fi încărcat oricum și este simplu și ușor de utilizat.

Aplicațiile complexe sunt locul în care jQuery se luptă: logică greu de urmărit, iad de apel invers, variabile globale și fără șabloane HTML. Acest lucru necesită în mod clar un mod diferit de organizare a aplicației front-end.

Bibliotecile front-end moderne, cum ar fi React, folosesc principiile de programare orientată pe obiecte (OOP) și organizează arhitectura aplicației front-end în componente modulare, reutilizabile. O componentă conține tot codul, marcajul și „starea componentei” (variabile) pentru un anumit element. Un element poate fi aproape orice: un buton, un câmp de introducere, un formular de utilizator sau un widget care afișează postări recente din back-end-ul WordPress REST API. Componentele pot conține și alte componente, formând o relație ierarhică.

Având în vedere complexitatea paginilor web din zilele noastre, organizarea unei aplicații în componente este o modalitate dovedită de a construi aplicații web care pot fi întreținute și rapide, de orice complexitate. Componentele sunt „cărămizi” foarte reutilizabile, izolate și, prin urmare, ușor de testat, așa că merită cu adevărat să înveți acest concept.

Există două biblioteci bazate pe componente care sunt în tendințe în acest moment: Vue.js și React. React ar fi o alegere evidentă, deoarece este deja folosit de Gutenberg. Cu toate acestea, pentru cineva nou în JavaScript modern, Vue.js ar putea fi mai bine să înceapă.

React vă aruncă la capăt prin utilizarea funcțiilor ES6, claselor, sintaxa JSX proprietară și canalul de construire Webpack imediat. Curba de învățare este destul de abruptă.

Vue.js, pe de altă parte, este mult mai prietenos pentru începători și poate fi folosit doar introducând o etichetă <script> . Vue.js folosește JavaScript simplu (ES5), HTML și CSS. Introducerea în noile concepte este mult mai graduală.

După ce ați lucrat la câteva proiecte Vue.js, veți fi mai bine pregătit să vă aprofundați în React. Nu că este întotdeauna necesar, dar dezvoltarea Gutenberg, de exemplu, o cere.

Utilizați API-ul REST WordPress

API-ul REST al WordPress este doar o interfață standardizată pentru solicitarea și modificarea de la distanță a datelor din WordPress. Este mai mult o arhitectură software decât un mod complet diferit de codare. Aceleași vechi fragmente jQuery AJAX ar putea fi utilizate cu parametri ușor diferiți.

Cel mai important beneficiu? Deoarece API-ul REST WordPress standardizează comunicarea dintre back-end și front-end, este un pas major către modularitate, reutilizare și lizibilitate în codul dvs. Acele șabloane groaznice cu HTML și PHP amestecate împreună și ceva SQL aruncat în amestec trebuie să dispară. Odată ce șabloanele sunt doar HTML cu substituenți pentru datele transmise ca parametri, nu există nicio diferență majoră între transmiterea acestor date în PHP sau printr-un API REST către o aplicație front-end.

Poate doriți să vă uitați și în WPGraphQL. Poate sau nu să înlocuiască în cele din urmă API-ul REST WordPress, dar câștigă rapid popularitate.

Învață Gutenberg (clienții îl vor solicita în curând)

Scopul final al lui Gutenberg este personalizarea completă a site-ului, printre alte planuri.

Aceasta pune bazele unui nou model pentru WordPress Core, care va avea un impact asupra întregii experiențe de publicare a platformei.

Pagina de proiect WordPress Gutenberg pe GitHub

Gutenberg a primit respingere majoră de la dezvoltatorii WordPress. Unele dintre argumentele împotriva îmbinării acestuia în nucleul WordPress au fost:

  • O parte semnificativă a utilizatorilor finali nu au nevoie de el, așa că ar trebui să fie un plugin opțional și să nu facă parte din nucleu
  • A spart unele site-uri
  • Pur și simplu nu era gata și putea folosi mai multă lustruire și mai puține bug-uri

Cu toate acestea, pentru scriitorii de conținut care folosesc WordPress ca platformă de blogging, Gutenberg oferă în mod clar o experiență mai bună decât vechiul editor.

Dezactivarea lui Gutenberg va fi acceptată atâta timp cât este necesar, da. Dar să te lași acum este o idee înțeleaptă: când un client te abordează și îți cere să faci dezvoltarea Gutenberg, vei fi gata.

Este timpul să ajungeți la viteză: chiar și „modul WordPress” evoluează

Cel mai obișnuit argument împotriva utilizării tuturor instrumentelor și tehnicilor descrise mai sus în dezvoltarea WordPress este următorul: „Modul WordPress” de a face lucrurile încă funcționează și se presupune că acesta este mai bun decât toate aceste lucruri noi strălucitoare.

Dar acum ați văzut că dezvoltatorii de bază WordPress sunt bine conștienți de toate cele mai recente evoluții. Nu numai atât, le folosesc cât mai mult posibil în părți mai noi ale nucleului datorită avantajelor lor evidente. Singurul lucru care ne reține este codul moștenit pe care nimeni nu îl va refactoriza.

De ceva timp, WordPress și WooCommerce au urmat practica dezvoltării „plugin-urilor de funcții” care implementează și utilizează tehnologii noi. Când este momentul potrivit, aceste plugin-uri se îmbină în nucleu, așa cum a făcut Gutenberg. WooCommerce are și propriul proiect React. API-ul REST WordPress a început și ca un plugin separat și acum face parte din nucleul WordPress.

Întrebarea nu este dacă ar trebui să învățăm lucruri noi și să le folosim în munca mea de zi cu zi, ci cum . Răspunsul este „treptat”, un pas la un moment dat. Fie învață ceva nou, fie fă ceva ce știi bine într-un mod nou și diferit.

De exemplu, învață cum să folosești Webpack cu toate scripturile tale vechi. Webpack vă poate transpila noul cod ES6+ în JavaScript „plat” compatibil cu browserele mai vechi. De asemenea, poate reduce scripturile și le poate combina. Acesta este un lucru nou. Terminat? Apoi rescrieți-vă JavaScript utilizând funcțiile ES6. Este un nou mod de a face ceea ce știi bine.

Rezultatul: veți învăța Webpack și ES6. Ca profesioniști, ar trebui să facem un pas înainte și nu să ne dăm înapoi. Continuă să înveți mereu. Și distribuiți atunci când o faceți: Toptal menține o listă cu cele mai bune practici de dezvoltare WordPress și salută contribuțiile comunității la aceasta.

În partea a 2-a a seriei noastre, ne vom scufunda în partea PHP a dezvoltării back-end WordPress moderne.