Share
Când vine vorba de a construi teme WordPress - ca și cu multe alte tipuri de lucruri, într-adevăr - există modalități corecte și modalități greșite de a face acest lucru. Pentru aceia dintre noi care doresc să devină dezvoltatori WordPress profesioniști, pentru aceia dintre noi care ne pasă cu adevărat de munca pe care o facem și pentru aceia dintre noi care doresc ca munca noastră să dureze, atunci trebuie să ne gândim mai departe cum organizăm fișierele și codul care intră în tema noastră.
Da, Codex-ul WordPress oferă un articol fantastic despre dezvoltarea temelor și cred că ar trebui să fie necesară citirea pentru oricine intră în temele de construcție - mai ales teme premium - dar există câteva strategii pe care nu le acoperă pe care le-am găsit foarte utile, deoarece acestea se referă la construirea, eliberarea și menținerea temelor în timp.
În următoarele două articole, vom examina câteva strategii care merg puțin mai adânc în dezvoltarea temelor, care ne vor ajuta să ne structurăm temele în așa fel încât să nu urmeze doar îndrumările WordPress Codex, dar, de asemenea, va face mult mai ușor să mențină, să actualizeze și să se îmbunătățească nu numai ca WordPress avansează, dar tema noastră se maturizează.
Calitatea organizării fișierelor și a codului care intră în construirea de teme WordPress este oarecum un subiect fierbinte.
Pentru a fi clar, acesta este unul dintre acele lucruri pe care dezvoltatorii și designerii le place să le vorbească până la un punct în care s-au transformat într-un lucru pe care oamenii îi place să-l urască. Asta inseamna ca altii vor comenta de multe ori despre teme de proasta calitate disponibile pentru WordPress si apoi vor folosi acest argument ca un motiv pentru care WordPress este o platforma proasta nu numai pentru blogging, ci si pentru alte motive.
Acesta nu este punctul sau argumentul a ceea ce vom discuta aici, nici nu este menit să inspire acest tip de discuție în comentarii. În schimb, seria din două părți presupune următoarele:
Desigur, noi toate au propriile noastre moduri de a face lucruri, astfel încât recomandările care sunt partajate în această serie să nu funcționeze cu fluxul de lucru curent. Poate că nu doriți să vă schimbați - și asta este bine! - sau poate că cauți o schimbare.
Indiferent de caz, tot ceea ce este împărțit aici se bazează pe experiența în construirea și menținerea temelor WordPress premium și le-a făcut mult mai ușor să le menținem în timp atât din punct de vedere al temelor, cât și din punct de vedere al compatibilității cu WordPress.
Una dintre cele mai grele părți ale software-ului de construcție nu este livrarea versiunii inițiale (deși asta este dur și în sine), dar menținerea produsului după eliberare.
Nu numai că acest lucru presupune asigurarea faptului că baza de coduri continuă să fie compatibilă cu infrastructura de bază - despre care vom vorbi în următoarea secțiune - dar că fișierele sunt organizate astfel încât să se poată înțelege de echipa de dezvoltare , că au un nivel de coeziune și că au o rimă și un motiv pentru care sunt numiți și plasați în modul în care sunt.
Știm din Codex că există o serie de fișiere care alcătuiesc nucleul temei. Acestea includ șabloane, un fișier de funcții și cel puțin o foaie de stil.
Ce se întâmplă, însă, când tema devine mai complicată? Spune că tu ...
Toate cele de mai sus pot fi organizate cu ușurință într-un director tematic WordPress. Vom analiza fiecare din aceste detalii într-un mod mai detaliat și raționamentul din spatele plasării lor în directorul tematic, sperând că acest lucru face ca dezvoltarea temelor să fie mai curată și că acest lucru face ca mentenanța să fie mult mai ușoară.
Deși, în multe contexte, acestea pot fi discutate în mod independent unul de celălalt, deoarece sunt responsabile de lucruri diferite, structura lor organizatorică într-o temă este atât de asemănătoare încât are sens să le grupeze împreună.
În primul rând, presupunând că nu utilizați niciun tip de pre-procesor CSS, ar trebui să existe un director pentru fiecare dintre aceste tipuri de fișiere. Asta ar trebui să ai css director și a js (sau poate le veți apela stiluri și JavaScript).
Indiferent de caz, fiecare tip de fișier ar trebui să se afle în propriul director. De acolo, puteți folosi apoi functions.php să înregistreze și să încarce fișierele după cum este necesar. Dacă este vorba despre un fișier utilizat pe întreaga temă, atunci îl veți înregistra necondiționat.
Dar dacă este vorba de un stil sau de un script care este folosit numai într-un anumit șablon, într-un anumit tip de post sau chiar pe o parte din tabloul de bord, atunci puteți - și ar trebui - să enquege fișierul condiționat.
Dar să spunem că tu sunteți folosind un preprocesor. În acest moment, veți rămâne cu fișierul pre-procesat și fișierele post-procesate. În funcție de natura proiectului, puteți sau nu să aveți totul redus la un singur fișier.
eu ar face recomandări pentru cum să denumiți fișierele; cu toate acestea, variația temelor, modul în care oamenii își construiesc munca și problema pe care o temă dată încearcă să rezolve problemele și care ne depășește domeniul de aplicare al acestei strategii.
Oricum, dacă intenționați să folosiți un pre-procesor, vă recomand să creați un subdirector în css și js au apelat directoare dev (sau dezvoltare sau orice vreți să o numiți). În acest director, scrieți toate fișierele pre-procesate, apoi lăsați instrumentul de alegere (fie CodeKit, Grunt sau ceva de genul ăsta) să emită fișierele procesate în rădăcina css și js directoare.
În acest fel, ați mai procesat, combinat și / sau minificat codul și aveți un director care conține sursa acestor fișiere. Când vine vorba de timp pentru a expedia această temă, nu aveți numai funcțiile call.php care vă apelează fișierele în directoarele respective, dar puteți, de asemenea, să excludeți dev director din construirea finală, astfel încât utilizatorul final să primească un pachet tematic mai mic și nu obține nimic mai mult decât are nevoie pentru a rula tema.
Șabloanele sunt adesea denumite partiale (mai mult în alte limbi decât în WordPress) și sunt adesea numite prin utilizarea get_template_part în WordPress. Pe scurt, scopul lor este de a elimina codul repetitiv care poate fi ușor incorporat în mai multe șabloane.
Un exemplu în acest sens ar fi, de exemplu, datele post-meta. Aceasta include, de obicei, următoarele informații:
Deoarece aceste informații pot exista în mai multe șabloane (cred că mesajele individuale, paginile, arhivele și așa mai departe), atunci ar fi logic să le rezumăm într-un singur fișier și să menționăm doar un singur fișier atunci când aveți nevoie de el.
Chestia este că, postul de meta date nu este numai tipul de informații care sunt refolosite pe parcursul unei teme. În acest scop, identificați elementele de bază care sunt refolosite, le abateți într-un fișier, apoi creați un amprente parțiale director.
De acolo, denumiți fiecare parte a unui șablon care indică ce reprezintă (cum ar fi post-meta.php, gravatar.php, navigation.php, pagination.php, și așa mai departe) și apoi apelați parțial în șablon unde este necesar.
De exemplu, în șabloanele postare, pagină și arhivă, puteți apela get_template_part ("partiale / post-meta");. Face pentru o citire mult mai ușor și face pentru o singur loc pentru a face o schimbare, mai degrabă decât în fiecare șablon.
Dacă scrieți o temă internaționalizată, care, dacă îl eliberați publicului, ar trebui să faceți acest lucru, atunci există un mod foarte clar și curat de a face acest lucru.
În primul rând, dacă acesta este un subiect nou pentru dvs., vă recomand să citiți articolul din Codul. Acesta vă va spune tot ce trebuie să știți despre cum să pregătiți șiruri de caractere pentru traducere, instrumente disponibile și așa mai departe.
Apoi, recomand să vă asigurați că aveți un loc dedicat temei pentru limbile dvs. În general, vă recomandăm să creați un director în tema pe care o numiți lang sau limbi și apoi abandonarea .po și .mo fișiere în directorul menționat. Aceasta este, de asemenea, o practică general acceptată și așteptată în cadrul comunității WordPress în ansamblu.
Nu numai că acest lucru relegate traducerile la locul lor în structura tematică, dar indică și altora unde să caute traducerile și unde să caute fișierele care oferă corzile care trebuie traduse.
Din nou, este vorba despre coeziune și asigurarea că lucrurile cu utilitate similară sunt grupate într-un mod rezonabil.
În funcție de fundalul dvs. în dezvoltare, funcțiile pe care le utilizați pentru a vă ajuta să obțineți o muncă și pentru a ajuta la separarea logicii de afaceri de logica de prezentare (sau, în multe dintre cazurile noastre, PHP direct de la HTML), sunt numite funcții auxiliare sau funcții utilitare.
În scopul acestei serii, ne vom referi la ele ca la funcții de ajutor, deși știm că toți sunt unul și același.
Dar aceasta ridică două întrebări:
Accentsconagua
functions.php?functions.php, unde locuiesc ei?Pe scurt, sunt de părere că ajutoarele și utilitățile ar trebui nu trăi în functions.php. Regula mea de bază este pur și simplu aceasta: Dacă codul pe care îl scriu comunică direct cu WordPress, cum ar fi add_theme_support, atunci aparține functions.php. Dar dacă există codul pe care scriu că va fi lansat o interogare personalizată pentru a prelua informațiile și pentru a transfera rezultatul procesat înapoi la șablon (sau partea de șablon), atunci el aparține unei funcții de ajutor.
La fel cum WordPress are etichete șablon sau funcții de șablon care pot fi numite în cadrul unui șablon, cum ar fi continutul(), tratați funcțiile ajutorului într-un mod similar - le puteți suna în șabloanele dvs. și în paralele, dar acestea sunt localizate în fișierul propriu.
Deoarece aceste funcții de ajutor nu trăiesc functions.php, atunci ar trebui să trăiască în propriul fișier și acel fișier ar trebui să fie referit undeva în codul bazei temei, nu? Mai mult decât atât, este de asemenea posibil ca dvs. să vă despărțiți în continuare asistenții în mai multe fișiere în funcție de complexitatea temei dvs..
În acest scop, vă recomand să introduceți un inc sau an include director în tema dvs. De acolo, plasați fișierele de ajutor în acel director și simplu include_once fișierul helper din partea de sus a fișierului funcțiilor dvs. și funcțiile vor fi ușor accesibile pe toată tema.
În cele din urmă, există momente în care vom include bibliotecile terților în temele noastre. Pur și simplu, acestea sunt instrumente care sunt dezvoltate de alții, care sunt în mod liber disponibile pentru utilizare și distribuție, care ne fac, de asemenea, ușor să ne întoarcem la munca altora.
Deci, unde ar trebui să trăiască? Sincer, aceasta depinde de tipul de bibliotecă cu care lucrați. De exemplu, bibliotecile pot veni sub formă de CSS, JavaScript sau PHP. Ca atare, ar trebui să existe un loc pentru aceasta:
lib director în cadrul dvs. js director. Aceasta indică faptul că folderul conține biblioteci JavaScript.lib director în cadrul dvs. css director. Din nou, aceasta indică faptul că aveți o bibliotecă CSS.lib director din directorul temei. Acest lucru indică faptul că nu este JavaScript sau CSS și că contribuie la funcționalitatea temei principale (care este în mare parte alcătuită din apeluri de funcții PHP, etichete șablon ș.amd).Desigur, am vazut, de asemenea, unii dezvoltatori creează o lib director și apoi creați js, css, și php subdirectoare în cadrul lib director. Este un pic o inversiune a sfaturilor oferite mai sus.
Nu este o strategie rea; totuși, motivul pentru care nu îmi place această abordare este că distribuie fișiere JavaScript, CSS și PHP în mai multe directoare din temă.
Crearea unei structuri de directoare organizate este doar o parte a acesteia. WordPress are o ierarhie de șabloane care necesită o anumită convenție de numire. Nu rezultă logic că fișierele personalizate ar trebui să facă același lucru?
În plus, cum rămâne cu convențiile de numire a funcțiilor? Au făcut-o ecou date sau întoarcere date? Pe deasupra, cum știm că facem apeluri corecte ale funcțiilor API și că nu folosim funcții depreciate ale WordPress?
În următorul articol, vom vorbi despre toate acestea, precum și despre instrumentele pe care le putem instala, care ne ajută să evităm aceste capcane. Vom discuta, de asemenea, cum funcționează și de ce, împreună cu convențiile de denumire a funcțiilor, contează atunci când construiește teme.
Deocamdată, însă, am abordat strategiile de organizare a fișierelor, care ar trebui să fie suficiente pentru a vă menține ocupat până când se publică următorul articol din seria.
Ca de obicei, dacă aveți ceva de adăugat, atunci vă rugăm să faceți acest lucru în comentarii!
