Share
În primul post din această serie, am analizat câteva dintre strategiile care sunt disponibile în legătură cu organizarea directoarelor tematice WordPress pentru a le face mai bine întreținute.
Mai exact, am atins modul de organizare:
În cele din urmă, obiectivul a fost să oferim o schemă de directoare în care să putem organiza fișierele noastre astfel încât să avem un nivel de coeziune, înțelegere și mentenabilitate pentru munca pe care o facem.
Dar asta nu e tot ce este vorba de a scrie teme de WordPress mentenabile. Altul este de a urma convențiile stabilite de WordPress Coding Standards; cu toate acestea, acest articol nu va lua o privire asupra standardelor. Codul face o treabă bună și le-am acoperit într-o altă serie.
În schimb, vom avea o privire puțin mai granulară asupra unora dintre strategiile și instrumentele pe care le putem folosi pentru a ne asigura că facem ca temele noastre să fie cât mai bine menținute. În acest post special, vom examina strategiile, apoi vom încheia seria examinând unele dintre instrumentele disponibile.
După cum sa menționat anterior, este un lucru de a avea o modalitate logică de a organiza toate directoarele, fișierele și bibliotecile care alcătuiesc tema; cu toate acestea, aceasta este de fapt doar jumătate din ceea ce se înscrie în construirea unei teme.
La urma urmei, există șabloane predefinite, funcții, convenții de denumire și instrumente care contribuie fie la formarea temei, fie la testarea temei pentru a vă asigura că nu utilizează apeluri API depreciate și că este compatibil cu cea mai recentă versiune de WordPress.
În acest scop, cred că este important să înțelegem fiecare dintre aceste subiecte, atât ca cineva care începe doar să construiască teme WordPress, cât și ca cineva care a făcut-o de ceva timp.
La urma urmei, nu este niciodată un moment mai bun pentru a încerca să te faci mai bine la ceea ce faci. În plus, comentariile sunt, de asemenea, un loc minunat pentru a continua discuția pentru a împărtăși idei alternative.
Dar, înainte de a ajunge acolo, să vorbim despre niște lucruri practice pe care le putem face în legătură cu tematica WordPress și care sporește mentenabilitatea a ceea ce facem.
În primul rând, dacă nu sunteți familiarizat cu ierarhia șabloanelor, atunci vă recomandăm să citiți pagina corespunzătoare Codex înainte de a continua cu acest articol.
Pe scurt, șabloanele pot fi descrise ca fiind următoarele:
Șabloanele WordPress se potrivesc împreună ca piesele unui puzzle pentru a genera paginile web de pe site-ul dvs. WordPress. Unele șabloane (de exemplu, fișierele șablonului antetului și subsolului) sunt utilizate pe toate paginile web, în timp ce altele sunt utilizate numai în condiții specifice.
Un alt mod de a gândi despre asta este: Când vine vorba de WordPress, tot ceea ce este afișat pentru utilizator vine din baza de date. Acestea includ titlul postului, postarea datelor, categoriile post, postarea conținutului, comentariile și așa mai departe.
Șabloanele sunt vehiculele prin care informația este prezentată utilizatorului. Acestea sunt compuse din marcare și PHP, redactate prin CSS și pot avea anumite efecte aplicate prin utilizarea JavaScript-ului.
Dar, presupunând că nu faceți nimic avansat cu lucruri precum tipuri personalizate de posturi și / sau taxonomii personalizate (un subiect pentru alt post, într-adevăr), atunci există un lucru unic despre Ierarhia de șabloane WordPress care poate servi atât ca un lux cât și o problemă de întreținere în funcție de modul în care te uiți la ea.
Rețineți că în articolul Codex legat WordPress va avea implicit index.php, header.php, și footer.php template-uri. Adevărul este că, într-adevăr, puteți să vă îndepărtați cu crearea unei teme WordPress întregi prin utilizarea numai index.php.
Sună cam atrăgător, nu? Adică, cine are nevoie să creeze atât de multe fișiere diferite atunci când poți crea o temă frumoasă, mică, slabă, care face tot ce ai nevoie.
Apoi, gândiți-vă la acest lucru din perspectiva colaborării cu o echipă fie cu colegii dvs., fie cu cei care ar putea contribui la un depozit deschis, fie cu cei care ar putea lua eventual unde ați rămas.
Dacă tot codul necesar pentru a furniza informații din baza de date este conținut într-un singur fișier, probabilitatea ca complexitatea acelui fișier să crească chiar de la crearea sa este foarte mare.
La nivelul cel mai de bază, ne uităm la un singur fișier cu un număr de condiționalități, este posibil ca unele declarații de comutare și așa mai departe. Și toate acestea se fac pentru că trebuie să contabilizați paginile de arhivă, paginile individuale de postare, postările unice, listele principale și așa mai departe.
Intelegi ce vreau sa spun?
Dar apoi, crearea de fișiere separate doar pentru a atenua această complexitate poate fi o fiară pe cont propriu. De exemplu, să spunem că aveți single.php pentru afișarea unei singure postări și pe care o aveți page.php pentru afișarea unei pagini, iar ambele șabloane au exact aceleași informații cu exceptia single.php are meta date post și page.php nu.
Acesta este un prim exemplu în care puteți extrage posta meta date în propriul său parțial, așa cum am discutat în articolul precedent. Sau poate puteți extrage codul responsabil pentru redarea conținutului este proprie parțială.
Indiferent de situație, punctul pe care încerc să-l fac este că există un echilibru care trebuie lovit când vine vorba de lucrul cu șabloanele WordPress și cu ierarhia șabloanelor WordPress.
Nu cred că este o idee bună să folosiți un număr minim de șabloane, însă, de asemenea, nu cred că este necesar să folosiți fiecare șablon acceptat dacă conduce la o duplicare prea mare a codului. Acolo este un echilibru care trebuie atins între șabloane și paralele.
În cele din urmă, cred că experiența cu privire la modul de utilizare care vine cu timpul, dar având acest cadru al minții încă de la început poate ajuta la asigurarea unui nivel de organizare și mentenabilitate, care este salt și limite în fața locului în care Mai incepeti sa nu faceti doar un pic de pre-planificare.
Când vine vorba de a lucra cu funcții și convenții de numire, există de obicei două reguli de bază care trebuie urmate:
Accentsconagua
întoarcere datele și ceea ce va face ecou dateDar dacă sunteți cineva care începe să dezvolte tema, sau sunteți cineva care dorește să-și îmbunătățească abilitățile în ceea ce privește acest lucru, ceea ce pare a arăta practic?
Când vine vorba de a numi în mod unic funcțiile, motivele pentru a face acest lucru sunt astfel încât să nu vă ciocniți accidental cu o funcție pre-existentă definită în WordPress sau un plugin care ar putea fi rulat în mediul dvs..
De exemplu, să presupunem că veți scrie o funcție proprie care va filtra conținutul înainte de ao redirecționa către pagină. Modul corect de a face acest lucru este de a folosi în mod evident add_filter funcţie; totuși, ți-ai numi funcția continutul?
Nu, desigur că nu. Motivul este că WordPress deja definește continutul. Dacă redenumiți o funcție cu acest nume, veți primi erori. În acest scop, este întotdeauna mai bine să vă prefixați funcțiile cu o cheie unică, cum ar fi numele temei dvs. sau ceva similar.
Deci, să spunem că vrem să prefixăm o semnătură până la sfârșitul conținutului nostru și să spunem că avem o temă pe care o sunăm Culme. Pentru a face acest lucru, vă recomand să creați o funcție numită acme_the_content deoarece identifică numele temei și indică numele funcției la care este cuplată.
Să spunem că doriți să terminați fiecare post cu numele dvs. și mânerul Twitter. Pentru a face acest lucru, puteți defini acest lucru în dvs. functions.php fişier:
„; semnătura $. = "Tom" @tommcfarlin'; $ signature = '„; returnează $ content = $ signature;
E relativ simplă, nu-i așa? Scurt este faptul că încerc să folosesc formatul următor când îmi creez propriile funcții legate: THEME_NAME-name_of_hook.
Acest lucru face cu adevărat ușor de înțeles și de urmărit nu numai atunci când navighezi codul, ci și când vizualizezi funcțiile care alcătuiesc tema sau fișierul care este activ în prezent în IDE.
Așa cum am menționat mai devreme, WordPress are o altă convenție pe care o folosește și care are de a face cu informația care urmează să fie returnată de la funcția apelată sau echoedă de la funcția apelată.
Din fericire, această regulă specială este foarte ușor de reținut:
obține_ obține_ S-ar putea să găsiți niste anomalii, dar asta este principiul general al modului în care API-ul WordPress indică modul în care va da datele înapoi după ce ați apelat funcția.
Dacă păstrăm în concordanță cu exemplul nostru anterior, să presupunem că doriți să ecou datele atunci când este apelată funcția, atunci pur și simplu apelați continutul(); cu toate acestea, dacă doriți să preluați conținutul dintr-o postare, să zicem, dintr-o bucla personalizată, atunci veți apela get_the_content () și păstrați-o în propria variabilă.
Poate ceva de genul: $ content_for_later = get_the_content (). Acum ați citit datele pentru conținutul care este în prezent legat de postarea activă din Buclă și l-ați stocat într-o variabilă pe care o puteți utiliza mai târziu.
Dar cunoașterea modului în care WordPress își numește funcțiile pentru dvs. este doar jumătate din ea. La urma urmei, plănuiți să construiți o temă sau un plugin și doriți să vă asigurați că păstrați consecvent cu "modul WordPress" de a face lucruri, corect?
Caz în punct: În exemplul dat mai sus, în cazul în care am filtrat conținutul, am prefixat funcția astfel încât a fost denumită acme_the_content, care indică faptul că Culme tema va returna conținutul de unde se numește în cadrul temei.
Ce s-ar întâmpla dacă am numi această funcție acme_get_the_content () ?
Ei bine, din punct de vedere tehnic, funcția ar echivala cu datele oricând ar fi fost numită; cu toate acestea, ar fi incompatibil cu API-ul WordPress, deoarece dezvoltatorul ar fi așteptat ca datele să le fie returnate astfel încât să le poată stoca într-o variabilă sau să le transfere unei alte funcții.
Există o nepotrivire între ceea ce așteaptă utilizatorul și ce se întâmplă de fapt.
Dacă vorbim despre ceva în lumea reală, atunci ar fi ca și cum ai avea un comutator pe perete pentru care utilizatorul se așteaptă că atunci când răstoarnă comutatorul, o lumină sau un ventilator se va aprinde în aceeași cameră când, în realitate, se poate să nu se întâmple nimic sau să apară o lumină sau un ventilator în altă cameră.
În acest scop, trebuie să fim atenți la denumirea funcțiilor noastre, astfel încât să nu scriem numai funcții care nu se vor ciocni cu alte funcții, dar care sunt, de asemenea, denumite în mod clar și care indică Cum ei vor manipula informația atunci când este apelată funcția.
După cum sa menționat la începutul acestui articol, există și o serie de instrumente și setări pe care le putem instala și configura în mediul nostru de dezvoltare, care ne vor ajuta să surprindem orice probleme potențiale înainte de a ajunge la lansarea temei noastre.
Acest lucru înseamnă că vom putea identifica funcțiile care vor fi eliminate în cele din urmă de pe WordPress, astfel încât să nu scriem codul depășit. În plus, există modalități de a ști dacă variabilele pe care încercăm să le accesăm nu au, să spunem, indici definiți sau alte caracteristici similare.
În ultimul articol din serie, vom analiza exact acest lucru. Între timp, examinați ce a fost acoperit aici, nu ezitați să vă împărtășiți întrebările și comentariile în feedul de mai jos și apoi vom căuta să încheiem această serie până săptămâna viitoare.
