Share
De-a lungul acestei serii am vorbit despre o serie de practici pe care le putem folosi în dezvoltarea temelor WordPress, care vor ajuta nu numai să ofere o fundație solidă, din care să putem construi proiectele noastre existente și viitoare, dar asta ne va ajuta de asemenea să le mențină după ce sunt eliberați.
Până în prezent, am acoperit:
Înainte de scufundări în acest articol, vă recomand să citiți primele două astfel încât să puteți obține un sentiment pentru perspectiva pe care o luăm atunci când privim la dezvoltarea temelor. În plus față de aceste puncte, există, de asemenea, o serie de instrumente care cred că ar trebui instalate pentru a vă asigura că scriem cel mai bun cod posibil.
Desigur, aceasta nu este numai pe lângă sfaturile menționate anterior, ci și aplicarea standardelor de codificare WordPress.
În acest articol final, voi vorbi despre mai multe setări și plugin-uri diferite pe care cred că ar trebui definite și / sau instalate în fiecare WordPress pentru a vă asigura că utilizați API-urile cele mai recente, că nu aveți impact negativ asupra performanței și că nu faceți ca anunțurile, avertismentele sau erorile să fie aruncate prin PHP.
Înainte de a începe să vorbim despre diverse plugin-uri disponibile, există o serie de setări pe care le recomand foarte mult setării pe serverul dvs. web și în mediul dvs. WordPress.
Unele dintre aceste setări vor contribui la funcționalitatea pluginurilor pe care le vom arunca o privire mai târziu în acest articol, altele vor oferi funcționalități care ne vor ajuta să ne avertizeze atunci când facem greșeli în PHP și / sau în WordPress - cod specific.
Deși nu toată lumea lucrează cu Apache, PHP și MySQL, este încă cea mai obișnuită configurație utilizată atunci când lucrați cu WordPress. Unul dintre lucrurile pe care le recomand întotdeauna dezvoltatorilor în acest mediu este să vă asigurați că au configurat PHP pentru a se loga Tot la un fișier log pe mașina lor.
Asta este, atunci când sunt date opțiunile de înregistrare:
Asigurați-vă că verificați Tot. Dacă utilizați un instrument precum MAMP, XAMPP sau WAMP, atunci acest lucru este de obicei foarte ușor de făcut prin interfața cu utilizatorul; cu toate acestea, dacă nu sunteți sigur în ce situație să configurați aceste opțiuni, puteți oricând să le configurați php.ini folosind notele care sunt prezentate în manualul PHP.
Urmărirea erorilor înregistrate care pot să nu fie afișate pe ecran (deși vom face tot ce putem pentru a ne asigura că noi do vedeți-le pe ecran mai târziu în acest articol) este esențială pentru a vă asigura că scrieți cod care captează orice potențiale probleme cu codul.
Acest lucru ar trebui să fie posibil atunci când folosiți alte servere web - la urma urmei, aceasta este de fapt doar o setare de configurare PHP - dar în prezent nu folosesc multe dintre celelalte opțiuni disponibile, așa că am vrut să fiu explicit despre în care configurez setările mele.
WP_DEBUG este o constantă pe care o puteți seta în WordPress wp-config.php fişier. Cele mai multe instalații vor avea această setare false, în mod implicit. Dacă ta este deja setată la Adevărat, atunci înseamnă că cineva a făcut-o deja sau că aveți o copie a WordPress cu setările care sunt nu livrate în mod implicit de la WordPress.org.
Oricum, în fișierul de configurare căutați constanta și dacă este setat la fals, apoi puneți-o la Adevărat. Dacă nu sa găsit, adăugați linia. În cele din urmă, asta este ceea ce ai functions.php fișierul trebuie să conțină (în plus față de celălalt cod care era deja acolo):
Accentsconagua
define ('WP_DEBUG', adevărat);Pe scurt, această constantă particulară vă va asigura că notele PHP sunt scrise pe ecran, precum și mesajele de depanare specifice WordPress. Acest lucru este foarte util ori de câte ori lucrați la o temă și încercați să verificați, să zicem, un indice gol al unui tablou sau să ajungeți la o funcție care nu mai este suportată de versiunea curentă a WordPress.
Există, de asemenea, un plugin fantastic în legătură cu această tehnică pe care o vom acoperi mai târziu în acest articol.
De asemenea, există și alte două constante pe care le puteți defini care vor da chiar și mai multe informații despre ceea ce va face acest lucru. Puteți citi articolul corespunzător Codex pentru mai multe informații, dar, pe scurt, constantele și definițiile acestora sunt după cum urmează:
WP_DEBUG_DISPLAY este un alt insotitor la WP_DEBUG care controleaza daca mesajele de depanare sunt afisate in HTML-ul paginilor sau nu. Valoarea implicită este "adevărată", care arată erorile și avertismentele în momentul în care sunt generate. Dacă setați acest lucru la fals, se vor ascunde toate erorile. Acest lucru ar trebui să fie utilizat împreună cu WP_DEBUG_LOG, astfel încât erorile să poată fi revizuite mai târziu.
Din cutie, WordPress va afișa toate erorile, avertismentele și anunțurile în contextul unei pagini. Dacă doriți să continuați să depanați WordPress, dar doriți să împiedicați redarea informațiilor de pe pagină și scrierea acestora doar într-un fișier jurnal, atunci puteți seta această constantă fals.
Personal, nu sunt un fan al păstrării lucrurilor ascunse, așa cum îmi place să văd probleme de îndată ce apar (citiți: de îndată ce le-am generat), dar toată lumea are diferite fluxuri de lucru. În acest scop, dacă vedeți mesajele de pe pagini care intră în conflict cu stilul dvs. de dezvoltare, definiți această constantă în mod corespunzător împreună cu WP_DEBUG_LOG.
WP_DEBUG_LOG este un companion pentru WP_DEBUG care face ca toate erorile să fie, de asemenea, salvate într-un fișier jurnal debug.log din directorul / wp-content /. Acest lucru este util dacă doriți să examinați toate notificările mai târziu sau să vizualizați notificări generate în afara ecranului (de exemplu, în timpul unei solicitări AJAX sau al unei rute wp-cron).
Aceasta este o constantă utilă pentru a defini dacă sunteți mare în monitorizarea jurnalelor de eroare (pe care majoritatea dezvoltatorilor ar trebui să fi). În plus față de jurnalul generat de PHP, acesta este încă un alt fișier care poate oferi o perspectivă asupra a ceea ce ar putea fi o anumită problemă și unde se întâmplă ori de câte ori lucrați la o temă.
Această constantă este o altă conectivitate care va fi utilă cu unele dintre pluginurile pe care le vom analiza mai târziu în acest articol; cu toate acestea, merită stabilit în functions.php chiar dacă nu aveți instalate pluginuri suplimentare.
În primul rând, cum ar fi WP_DEBUG constant mai sus, puteți adăuga acest lucru functions.php. Ar trebui să arate astfel:
define ('SAVEQUERIES', true);Arată bine, sigur, dar ce face de fapt? SAVEQUERIES instruie WordPress să urmărească două lucruri:
Acesta interfețează direct cu $ wpdb care este clasa de baze de date WordPress. Așa cum am menționat mai devreme, există un alt plugin care funcționează direct cu această constantă, astfel încât să puteți vedea toate interogările din WordPress; cu toate acestea, dacă doriți să renunțați la utilizarea unui plugin pentru a ajuta la redarea informațiilor, definiți pur și simplu această constantă și apoi imprimați rezultatul $ Wpdb-> interogări la formatul dvs. de ieșire de alegere.
În plus față de stabilirea constantelor, există un număr de plugin-uri puternice pe care cred că ar trebui să fie instalate în fiecare instalare a dezvoltatorului WordPress, care poate oferi chiar mai mult ajutor atunci când se utilizează cu setările de mai sus.
Deși mulți dintre voi vor avea pluginuri pentru a adăuga la această listă și alții vor avea opinii despre fiecare dintre aceste pluginuri, acestea sunt cele pe care le-am găsit cele mai utile în eforturile mele de dezvoltare.
Debug Bar introduce o opțiune în bara de administrare a instalării dvs. WordPress care oferă informații despre interogări, memoria cache și alte informații.
Acest plugin este cel mai bine folosit cu WP_DEBUG și SAVEQUERIES activat. Rețineți că acest plugin este, de asemenea, necesar pentru un număr de pluginuri pe care le listați după acesta. Adică, are o serie de extensii care o fac și mai puternică.
Acest plugin introduce încă două file în cadrul barei de depanare care vă permite să vedeți toate acțiunile și filtrele (adică toate cârligele) care sunt executate în cererea de pagină curentă.
Acest lucru este extrem de util dacă construiți o temă complexă sau dacă ați moștenit o bază de coduri de la altcineva și încercați să găsiți De ce se întâmplă anumite lucruri care nu pot fi ușor de găsit din cauza modului în care tema este construită.
Din păcate, acest plugin special nu a fost actualizat în câțiva ani, așa că nu știu cât timp va continua să lucreze cu WordPress (cu excepția cazului în care cineva îl adoptă pentru dezvoltare), dar funcționează împreună cu Debug Bar pentru a vă oferi abilitatea de a executa PHP și MySQL direct din WordPress.
Acest lucru este foarte util atunci când încercați să dați seama de ce, să zicem, o funcție în tema dvs. nu funcționează așa cum ar trebui să fie. Adică puteți scrie o funcție direct în consola, executați-o și vedeți rezultatul fără a trebui să vă reîntoarceți constant în IDE, să schimbați funcția, să reîmprospătați și să verificați rezultatul.
Dacă lucrați cu o temă care folosește o mulțime de stiluri și o mulțime de fișiere JavaScript, mai ales cele care depind de alte foi de stil și de alte fișiere JavaScript, este util să cunoașteți ordinea în care sunt încărcate și cum ar trebui să fie încărcat.
Aici intră în joc acest add-on pentru Debug Bar.
Aceasta ne permite să vizualizăm ordinea în care sunt încărcate și executate scripturile și stilurile astfel încât să putem efectua modificările necesare pentru a ne asigura că toate dependențele sunt încărcate în modul în care ar trebui să fie ca tema noastră să funcționeze corect.
Dacă tema dvs. introduce tipuri personalizate de posturi în tabloul de bord, atunci este probabil să aveți de lucru cu o varietate de proprietăți diferite, reguli de rescriere și multe altele.
Se poate obține complex foarte repede în funcție de cât de mult decideți să optimizați caracteristicile tipului de post personalizat.
Acest plugin adaugă încă un alt panou la Debug Bar, astfel încât să puteți vedea cu ușurință proprietățile pentru fiecare tip de postare. Nu permite modificarea sau editarea în zbor (așa cum se poate face în Debug Bar Console sau poate fi făcută doar prin editarea definiției personalizate a tipului postului), dar oferă un format mult mai curat decât o matrice gigantică în ecranul unui IDE.
Acesta este un plugin simplu care va loga utilizarea fișierelor vechi, funcția, argumentele și așa mai departe într-un fișier. Mai exact, atunci când scrieți o temă, acest plugin va notifica când executați ceva care nu este 100% compatibil cu versiunea curentă a WordPress.
Pentru cei care doresc să se asigure că își protejează viitorul și care rămân la curent cu cele mai recente API-uri, recomand acest plugin.
Una dintre cele mai mari concepții greșite despre WordPress este că rulează o mulțime de plugin-uri pentru ca site-ul dvs. să se încarce încet sau că o mulțime de plugin-uri provoaca bloat. Asta nu este adevărat. Pluginurile slabe scrise fac asta. Cei care urmează cele mai bune practici WordPress și standardele de codificare ar trebui să aibă un impact minim asupra timpului de încărcare.
Cu acest lucru a spus, acest plugin va identifica exact care plug-in-uri au impactul cel mai mult performanță. Sigur, acest lucru poate fi util atunci când încercați să restrângeți motivul pentru care un site funcționează încet, dar este, de asemenea, util să executați împotriva propriului cod pentru a vă asigura că ești nu afectează negativ performanța site-ului.
Pentru oricine a făcut o muncă extensivă cu tipuri personalizate de posturi, rute personalizate sau adrese URL sau care au fost nevoiți să se aventureze în API-ul Rewrite, știți provocările care există.
Acest plugin vă ajută să oferiți o reprezentare vizuală a regulilor de rescriere pentru instalarea dvs. Este util pentru inspectarea regulilor care există în cadrul temei curente, dar este de asemenea util pentru a ajuta la depanare atunci când încercați să definiți o schemă personalizată și aveți un timp dificil de a adăuga expresia obișnuită în acest scop.
Dacă doriți să comercializați plugin-ul la cel mai larg public posibil, atunci veți dori să testați cum arată acesta în limbile care citesc de la stânga la dreapta și de la dreapta la stânga, precum și.
Asta este, dacă doriți să vă asigurați că ați internaționalizat corect tema, atunci acest plugin vă va permite să vedeți cum arată munca dvs. pentru limbile internaționalizate.
Dacă sunteți în căutarea de a vinde tema dvs., să spunem, pe WordPress.com, atunci acesta este un must-have.
Dacă căutați să vă asigurați că tema dvs. este actualizată cu actuala recomandare WordPress Theme Review, atunci Theme Check nu este negociabilă.
Acesta va efectua un audit automatizat al temei dvs. și vă va asigura că tot codul dvs. este în concordanță cu orientările actuale. În caz contrar, vă va arăta o citire clară a problemelor și linkuri către orientarea pe care nu o urmăriți. De asemenea, oferă sugestii cu privire la lucrurile pe care ar trebui să le implementați.
Rețineți că cele mai multe (dacă nu toate) dintre acestea sunt disponibile gratuit din cadrul Depozitului Plugin WordPress, astfel încât acestea să poată fi instalate direct din WordPress.
După cum am afirmat în articolele anterioare, multe dintre lucrurile pe care le-am împărtășit în această serie sunt puțin subiective sau pot să nu funcționeze în mediul actual. Deși practicile și instrumentele pe care le-am împărtășit au fost încercate și dovedite în întreaga mea experiență personală în lucrul cu WordPress timp de mai mulți ani, recunosc, de asemenea, că nu folosim cu toții același set de instrumente.
Ca atare, aceasta înseamnă că o parte din configurație, organizare și setări pot varia pentru dvs. Este în regulă. În cele din urmă, punctul este că noi, ca dezvoltatori de temă, trebuie să facem o treabă mai bună de a scrie teme mentenabile, deoarece ne petrecem atât de mult timp lucrăm la ele după lansarea lor inițială.
Poate că unele dintre lucrurile sugerate în această serie vă vor ajuta să faceți exact acest lucru. Poate că va trebui să modificați câteva sugestii pentru a se potrivi cu instrumentele pe care le utilizați. Indiferent de situație, sper că nu a fost doar o serie utilă cu câteva sfaturi practice care să vă ajute în dezvoltarea tematică în curs, dar și faptul că a stârnit un interes în stabilirea unei baze pentru modul în care organizați și structurați proiectele dvs. înainte.
Ca de obicei, nu ezitați să păstrați discuția cu comentariile, întrebările și orice alte reacții generale în comentariul de mai jos.
