Olen töötanud väikese projekti, pigem veebirakenduse kui saidi kallal, mis nõuab nii kohandatud teema kui ka tihedalt seotud, kuid väga spetsiifilise funktsionaalsuse väljatöötamist.
See on väga kitsa fookusega projekt (millest ma tõenäoliselt kunagi tulevikus räägin), kuid selle kallal töötades sundis see mind veidi tagasi pöörduma WordPressi arenduse teemaarenduse poole.
Ei, ma ei kujunda – õnneks –, kuid pean töötama teemade kohandamisega funktsionaalsest vaatenurgast. Seda tehes on see aga pannud mind uuesti läbi vaatama nõutud functions.phpja mõned kaalutlused, mida mul pole kunagi varem olnud.
Lisaks on see pannud mind sügavamalt uurima nende kasutamist mu-pluginsja küsima, millal need on vajalikud ja miks ma pole neid varem rohkem kasutanud (või isegi siis, kui neid tõesti vaja oleks).
Nii et ma hakkan selles osas veidi luuletama.
TL;DRKui ma teemaarendust tegin, functions.phpkasutati seda kahe asja jaoks (mis on iseenesest problemaatiline), kuid siiski:
- teemade funktsioonide lubamiseks või keelamiseks,
- teemaspetsiifiliste funktsioonide määratlemiseks.
Teemaarendaja käsiraamatus on kirjas:
See
functions.phpfail on koht, kus saate oma WordPressi teemale unikaalseid funktsioone lisada. Seda saab kasutada WordPressi põhifunktsioonidega ühendamiseks, et muuta teie teema modulaarsemaks, laiendatavamaks ja funktsionaalsemaks.Teemafunktsioonid, Teemaarendaja käsiraamat
Ja ma saan sellest aru, kuid minu vaatenurgast ja WordPressi arenedes arvan, et see functions.phppeaks olema pühendatud teemaspetsiifilistele funktsioonidele asjades, mis haakuvad otse tuumaga, näiteks:
- kohandaja funktsionaalsus,
- menüü funktsionaalsus,
- stsenaariumi ja stiili registreerimine,
- ja nii edasi.
Aga kui mingi konksu ajal peab midagi töötama ja see on pigem domeenispetsiifilise loogika põhimõte, siis see ei kuulu sellesse faili.
See tõstatab aga küsimuse: kus asuvad domeenispetsiifilised funktsioonid?
Sisestage Must-Use Pluginad
Tean, et sellised asjad nagu inckataloogid muutuvad üha tavalisemaks, kuid teemaarendusest rääkides ei muretse ma nende pärast, eriti kui teemaarendus pole minu tähelepanu keskmes ja konkreetne kataloogistruktuur pole minu stiil.
Igatahes, kui rääkida väga spetsialiseeritud lahendustest (kus lahendus on esitluse ja tihedalt keskendunud funktsionaalsuse kombinatsioon), hakkan mõtlema mu-plugins.
Ja põhjus, miks ma standardse WordPressi pistikprogrammi peale ei mõtle, on see, et need on üldiselt loodud töötama mis tahes teemaga ja lisama funktsioone. Mitte nii mu-plugins.
Must-use pluginad (teise nimega mu-pluginad) on pluginad, mis on installitud spetsiaalsesse kataloogi sisukausta sees ja mis lubatakse automaatselt kõigil installisaitidel.
Must-Use Pluginad, WordPress.org
Nii et siin on minu mõttekäik:
- Teemad on ettekandmiseks
- Pluginad on funktsionaalsuse jaoks.
- Pluginad on loodud kasutamiseks olenemata teemast ja kogu saidi laiuses.
- Must-Use Pluginad on pistikprogrammid, mis on vaikimisi lubatud ja kasutusel
- Seetõttu peaks spetsialiseeritud lahenduse domeenispetsiifiline loogika asuma kohustuslikus pistikprogrammis.
Muidugi võib väita, et mõned teemad võivad vajada kohustuslikku funktsionaalsust, kuid kas see ei sobi siiski mõttega, et funktsionaalsus peaks asuma kohustuslikus pistikprogrammis?
Olenemata sellest, lähenemisviis, mida ma olen järginud, on järgmine:
- Funktsionaalsus, mis seob konkreetselt teemafunktsioonid WordPressi tuumaga, läheb
functions.php. - Funktsionaalsus, mis on domeeniloogika, kuid nõuab, et kogu lahendus töötaks, asub
mu-plugin.
Oma karjääri praegusel hetkel ei tee ma palju tööd, mis keskenduks millelegi muule peale taustaprogrammi, kuid harvadel võimalustel, mil mul tuleb oma tööd laiendada, avastan, et püüan ikka veel olla. analüütiline ja läbimõeldud selle üle, kuidas ma projekti üles ehitan.