Share
În această serie, analizăm taxonomiile WordPress, definiția acestora, momentul când le folosim și cum să le includem în temele noastre. Pentru a ne asigura că acoperim acest lucru cât mai mult posibil, ne apropiem de aceasta din perspectiva unui începător.
Așa cum am menționat în primul post din serie, această serie nu este destinată numai începătorilor. Poate că sunteți un dezvoltator WordPress intermediar care încearcă să înceapă să se rostogolească în noi API-uri și să implementeze noi caracteristici în munca dvs. și taxonomiile se potrivesc facturii exact pentru asta.
Indiferent de situație, facem tot ce putem pentru a ne asigura că sunteți înarmat cu cât mai multe informații posibil atunci când este vorba de încorporarea taxonomiilor personalizate în proiectele dvs. WordPress.
Înainte de a ne uita la o implementare reală a modului de includere a taxonomiilor, trebuie să vorbim despre unele dintre provocările care vin cu încorporarea taxonomiilor în munca noastră.
Mai exact, ar trebui taxonomiile să fie incluse ca parte a unei teme sau într-un plugin? Această întrebare este într-adevăr mai mult o chestiune de "de ce ar trebui să includem taxonomii în acest fel?" și "când ar trebui să includem taxonomii în acest fel?"
Și pentru a răspunde la aceasta, este important să distingem cele două opțiuni pe care le avem și cum sunt stocate datele.
În primul rând, hai să discutăm despre modul în care taxonomiile sunt stocate intern în WordPress. Taxonomiile constau din două componente: o taxonomie și un termen.
De exemplu, atunci când gândim la Formate Post, taxonomia este Post Format iar termenii sunt Standard, Video, Imagine, Legătură, si asa mai departe. În mod similar, poate fi o altă taxonomie Fotografie și termenii pot fi Film și Digital.
În cazul cel mai de bază, taxonomia implicită pentru WordPress și asocierea pe termen este Categorie și Fără categorie care este prevăzut cu fiecare instalare.
Acum, de aici, este important să înțelegeți modul în care aceste date sunt gestionate în baza de date WordPress. Există trei tabele de baze de date, fiecare dintre acestea jucând un rol în relația dintre taxonomii și termenii lor asociați.
Presupunând că lucrați cu instalarea implicită (adică, este prefixul de tabelă) wp_), atunci veți avea următoarele tabele fiecare cu responsabilitățile corespunzătoare:
Accentsconagua
wp_terms reprezintă termenii care aparțin diferitelor taxonomii. Acest lucru înseamnă că, dacă aveți a Fotografie taxonomia cu doi termeni fiind Film și Digital și aveți o taxonomie numită Tip cu Culoare și Alb-negru fiind termeni, atunci Film, Digital, și Culoare vor locui toate în cadrul wp_terms masa.wp_term_taxonomy este o tabelă de baze de date care este responsabilă pentru stocarea descrierii termenilor stocați în wp_terms masa. Spuneți, de exemplu, că aveți a Culoare termen și termenul este descris ca "Fotografii care sunt dezvoltate în culori vibrante". Apoi, această descriere ar rezida în wp_term_taxonomy masa.wp_term_relationships este, probabil, cel care are cea mai mare curbă de învățare pentru noii dezvoltatori. Acest tabel menține legătura dintre ce taxonomii sunt legate de tipurile de posturi. De exemplu, având în vedere o instalare implicită, acest tabel va stoca relația dintre termenul de categorie și fiecare post la care este asociat.Acum, că avem o înțelegere cu privire la modul în care sunt stocate datele, putem discuta când taxonomiile au sens în contextul temelor și în contextul pluginurilor.
În general, o regulă bună este de a reține că temele WordPress ar trebui să fie pentru prezentarea de date și plugin-uri ar trebui să fie pentru funcționalitate. Astfel, temele oferă formatul pentru modul în care arată datele, iar pluginurile extind funcționalitatea de bază a WordPress.
Există, de asemenea, noțiunea de extensii care sunt ca plugin-uri specifice temelor și plugin-uri specifice, dar acest lucru depășește domeniul de aplicare al acestui articol. Pentru moment, să păstrăm discuția la nivelul temelor și pluginurilor.
Să presupunem că lucrați la o temă și doriți să introduceți în temă o taxonomie personalizată. În conformitate cu exemplele noastre utilizate în întreaga serie, să presupunem că doriți să creați o temă de portofoliu pe care doriți să o introduceți A Fotografie taxonomie. La urma urmei, tema va permite utilizatorilor să-și prezinte munca.
Apoi, să spunem că doriți să lucrați pe aceeași temă într-un an sau ceva, dar doriți să efectuați o majorare majoră. Poate că doriți să generalizați taxonomiile, astfel încât oamenii să nu fie nevoiți să o folosească doar pentru fotografie. În schimb, pot să o folosească pentru scurte poezii sau scrieri, desene și așa mai departe.
Problema este că aveți acum Fotografie taxonomia codificată ca temă, astfel încât oricine o folosește și instalează, primește această taxonomie, indiferent dacă doresc să prezinte fotografie sau nu.
Sigur, este complet posibil să refacem tema de la bază și să abrogem funcția de taxonomie în ceva mai general, dar ce se întâmplă pentru utilizatorii care doresc să facă upgrade? Pierd datele pe care le-au petrecut luni sau ani? Cum vor fi organizate datele lor? Sunt blocați de versiunea curentă a temei cu care lucrează?
Evident, trebuie să luați în considerare ori de câte ori lucrați la o temă ca aceasta. Dar acolo intră în joc importanța segmentării prezentării și a funcționalității.
Este complet posibil să construiți o temă menită să prezinte o lucrare într-un stil de portofoliu, fără a fi nevoie de a codifica în vreun fel orice tip de taxonomie în temă. În schimb, construiți funcționalitatea într-un plugin și apoi instalați plugin-ul alături de tema cu care construiți. Apoi, obțineți avantajele prezentării portofoliului fără a fi blocat utilizatorii în utilizarea temei pentru o perioadă lungă și potențial pierzând datele atunci când faceți upgrade la o temă nouă.
Pentru multe dintre motivele de mai sus, este ușor să vedem de ce implementarea taxonomiilor personalizate în contextul pluginurilor are sens.
Acest lucru nu înseamnă că nu ar trebui să se facă niciodată în teme. La urma urmei, acolo sunteți nișă teme care vizează o audiență foarte specifică și care încearcă să ofere o soluție completă pentru clienții lor. Este bine, dar dacă căutați să introduceți acest tip de funcționalitate cu cea mai largă recuză posibilă, atunci construirea unei funcționalități într-un plugin face multă sens.
Nu numai că aveți avantajul de a oferi utilizatorilor posibilitatea de a-și transfera datele de la o temă la o temă, fără a pierde categoria datelor, dar le oferă și avantajul de a putea menține independența între prezentarea datelor și stocarea a datelor lor.
Și dacă sunteți un dezvoltator de teme, puteți lucra în continuare pentru a crea teme concepute special în jurul pluginului. Poate doriți să oferiți o temă pentru fotografi, una pentru scriitori și una pentru artiști. Cu această strategie, puteți continua să captați un anumit tip de piață, făcând plugin-ul compatibil cu variațiile muncii dvs., eliberându-vă pentru a lucra pe teme diferite și oferindu-vă clienților posibilitatea de a vă deplasa între teme toate în timp ce utilizați încă produsele dvs..
Deoarece am analizat modul în care WordPress gestionează taxonomiile din cadrul bazei de date și am analizat motivele pentru care temele și pluginurile ar trebui să funcționeze împreună pentru a oferi caracteristici specifice, vom examina modul în care putem creați propriul plugin care implementează funcționalitatea taxonomică particulară pe care am folosit-o ca exemple de date în întreaga serie.
Între timp, nu ezitați să lăsați comentarii, întrebări sau feedback general în câmpul de comentarii de mai jos.
