Share
När det gäller att bygga WordPress-teman - som med många andra typer av saker, verkligen - finns det rätt sätt och fel sätt att göra det. För de av oss som vill vara professionella WordPress-utvecklare, för de av oss som verkligen bryr sig om det arbete vi gör, och för de av oss som vill ha vårt arbete att hålla, måste vi vara framtänkande om hur Vi organiserar filerna och koden som går in i vårt tema.
Ja, WordPress Codex erbjuder en fantastisk artikel om Theme Development, och jag tror att det borde vara nödvändigt att läsa för alla som kommer in i att bygga teman - speciellt premium-teman - men det finns några strategier som det inte täcker att jag har funnit vara till stor hjälp när det gäller att bygga, släppa och behålla teman över tiden.
I de följande två artiklarna ska vi titta på några strategier som går lite djupare in i temat utveckling som hjälper oss att strukturera våra teman på ett sådant sätt att de inte bara följer riktlinjerna i WordPress Codex, men det kommer också att göra det mycket lättare att behålla, uppdatera och förbättra inte bara när WordPress rör sig framåt, men som vårt tema också mognar.
Kvaliteten på organisationen av filerna och koden som går in i att bygga WordPress-teman är något av ett hett ämne.
För att vara tydlig är detta en av de saker som utvecklare och designers älskar att prata om till en punkt där det har förvandlat till något som folk älskar att hata. Det vill säga att andra ofta kommer att kommentera de dåliga kvalitetstema som finns tillgängliga för WordPress och använder sedan det argumentet som en orsak till varför WordPress är en dålig plattform, inte bara för bloggar, utan av andra skäl också.
Det är inte meningen eller argumentet för vad vi ska diskutera här, och det är inte heller meningen att vi ska inspirera den typen av diskussion i kommentarerna. Istället antar denna tvådelade serie följande:
Självklart, vi alla har egna sätt att göra saker så de rekommendationer som delas i hela denna serie kanske inte fungerar med ditt nuvarande arbetsflöde. Kanske vill du inte förändras - och det är bra! - eller kanske du letar efter en förändring.
Oavsett fallet är allt som delas här baserat på erfarenhet av att bygga och behålla premium WordPress-teman och har gjort det mycket lättare att behålla dem över tiden, både från en temaspecifik ståndpunkt, men från en WordPress-kompatibilitetssynpunkt.
En av de svåraste delarna av byggprogrammet levererar inte den ursprungliga versionen (även om den är tufft i sig), men det bibehåller produkten efter frisättning.
Det innebär inte bara att se till att kodbasen fortsätter att vara kompatibel med den underliggande infrastrukturen - som vi ska prata om i nästa avsnitt - men att filerna är organiserade på ett sådant sätt att de låter sig förstå av utvecklingsgruppen , att de har en grad av sammanhållning, och att de har rim och skäl till varför de heter och placeras på det sätt de är.
Vi vet från Codex att det finns ett antal filer som utgör kärnan i temat. Detta inkluderar mallar, en funktionsfil och minst ett stilark.
Vad händer dock när ditt tema blir mer komplicerat? Säg att du ...
Allt ovanstående kan vara ordentligt organiserat inom en WordPress temakatalog. Vi tar en titt på var och en av dem i lite mer detalj och motiveringen bakom deras placering i temakatalogen i hopp om att det här gör temat utvecklingsrengörare och att det här gör underhållsbehov mycket enklare.
Även om de i många sammanhang kan diskuteras oberoende av varandra eftersom de är ansvariga för olika saker, är deras organisationsstruktur inom ett tema så lik att det är vettigt att gruppera dem tillsammans.
För det första, förutsatt att du inte använder någon typ av CSS-förprocessor, så borde det finnas en katalog för var och en av dessa typer av filer. Det är, du borde ha en css katalog och a js katalog (eller kanske du ringer dem stilar och javaScript).
Oavsett fallet borde varje filtyp ligga i sin egen katalog. Därifrån kan du använda functions.php att registrera och skriva in filerna efter behov. Om det är en fil som används över temat, registrerar du det ovillkorligt.
Men om det är en stil eller ett skript som bara används på en viss mall, en viss posttyp, eller till och med på en del av instrumentbrädan, kan du - och borde - förutse filen villkorligt.
Men låt oss säga det är med en förprocessor. Vid denna tidpunkt kommer du att vara kvar med din förbehandlade fil och dina efterbehandlade filer. Beroende på projektets karaktär kan du eller kanske inte ha allt reducerat till en enda fil.
jag skulle gör rekommendation för hur man namnger filer; emellertid variationen i teman, hur människor bygger sitt arbete och problemet ett visst tema försöker lösa saker och det som får oss bortom omfattningen av den här strategin.
Hur som helst, om du ska använda en förprocessor rekommenderar jag att du skapar en underkatalog i css och js kataloger kallas dev (eller utveckling eller vad du än väljer att kalla det). I den här katalogen skriver du alla dina förbehandlade filer, då låter du ditt valfria verktyg (det är CodeKit, Grunt eller något liknande), exportera de bearbetade filerna till roten till css och js kataloger.
På det här sättet har du fortfarande bearbetat, kombinerat och / eller miniverat kod, och du har en katalog som innehåller källan till dessa filer. När det är dags att skicka temat, har du inte bara funktionerna .php som ringer filer i sina respektive kataloger, men du kan också utesluta dev katalog från den slutliga byggnaden så att slutanvändaren får ett mindre temapaket och får inget mer än att de behöver köra temat.
Malldelar kallas ofta som partiella (mer på andra språk än i WordPress) och kallas ofta med hjälp av get_template_part i WordPress. Kort sagt är deras syfte att abstrahera repeterande kod som enkelt kan införlivas i flera mallar.
Ett exempel på detta skulle vara, posta metadata. Detta inkluderar vanligtvis följande information:
Eftersom denna information kan existera i flera mallar (tänk enstaka inlägg, sidor, arkiv osv.) Skulle det vara vettigt att sammanfatta det i en enda fil och bara referera till den ena filen när du behöver det.
Saken är, posta metadata är inte endast Typ av information som återanvänds genom ett tema. För det ändamålet, identifiera de kärnelement som återanvänds, abstrakt dem in i en fil och skapa sedan en partials katalog.
Därifrån, namnge varje malldel något som indikerar vad det representerar (t.ex. post-meta.php, gravatar.php, navigation.php, pagination.php, och så vidare) och sedan ringa till partiet i mallen där det är nödvändigt.
Till exempel, i post-, sid- och arkivmallar kan du ringa get_template_part ('partials / post-meta');. Gör det enklare att läsa och gör för en enda plats för att göra en förändring snarare än i varje mall.
Om du skriver ett tema som är internationaliserat vilket, om du släpper det till allmänheten, borde du göra det, så är det väldigt tydligt och rent sätt att göra detta.
För det första, om det här är ett nytt ämne för dig, rekommenderar jag att du läser artikeln i Codex. Det kommer att berätta allt du behöver veta om hur man förbereder strängar för översättning, tillgängliga verktyg och så vidare.
Då rekommenderar jag att du har en dedikerad plats i ditt tema för dina språk. Generellt sett rekommenderar jag att du skapar en katalog i namnet ditt lang eller språk och sedan släppa .po och .mo filer i nämnda katalog. Detta är också en allmänt accepterad och förväntad övning inom WordPress-samhället som helhet.
Detta förskjuter inte bara översättningarna till sin egen plats inom temastrukturen, men det indikerar också för andra var man ska leta efter översättningar och var man ska leta efter de filer som erbjuder strängar som behöver översättas.
Återigen handlar det om sammanhållning och ser till att saker av liknande användningsområden grupperas ihop på ett rimligt sätt.
Beroende på din bakgrund i utveckling, funktioner som du använder för att hjälpa dig att få jobb och hjälpa till att separera affärslogiken från presentationslogiken (eller i många av våra fall, rak PHP från HTML), kallas hjälparfunktioner eller verktygsfunktioner.
I syftet med denna serie hänvisar vi till dem som hjälpfunktioner, men vet att de är alla ena i samma.
Men detta väcker två frågor:
Accentsconagua
functions.php?functions.php, vart bor dem?Kort sagt, jag är av minnet att hjälpare och verktyg bör inte bo i functions.php. Min tumregel är helt enkelt detta: Om koden som jag skriver direkt kommunicerar med WordPress som add_theme_support, då hör den till functions.php. Men om det finns kod som jag skriver som ska köra en anpassad fråga för att hämta information och lämna det bearbetade resultatet tillbaka till mallen (eller malldelen), hör det till en hjälparfunktion.
Precis som WordPress har malltaggar eller mallfunktioner som kan kallas i en mall, t.ex. innehållet(), behandla hjälparfunktioner på ett liknande sätt - du kan ringa dem i dina mallar och i dina delar, men de är placerade i sin egen fil.
Eftersom dessa hjälparfunktioner inte lever i functions.php, då borde de leva i sin egen fil och den filen ska hänvisas någonstans i temat kodbas, eller hur? Utöver det är det också helt möjligt att du vidare kan bryta upp dina hjälpare till flera filer baserat på komplexiteten i ditt tema.
För det ändamålet rekommenderar jag att du infogar en inc eller en innefattar katalog i kärnan i ditt tema. Därifrån placera dina hjälparfiler i den katalogen och enkelt include_once hjälpar filen högst upp i din funktionsfil och funktionerna är lätt och lättillgängliga under resten av ditt tema.
Slutligen finns det tillfällen där vi kommer att inkludera bibliotek från tredje part i våra teman. Enkelt uttryckt är dessa verktyg som utvecklas av andra som är fritt tillgängliga för användning och distribution, vilket också gör det enkelt för oss att piggybacka på andras arbete.
Så var borde de bo? Ärligt talat beror detta på vilken typ av bibliotek det är med vilket du arbetar. Bibliotek kan till exempel komma i form av CSS, JavaScript eller PHP. Som sådan borde det finnas plats för det:
lib katalog i din js katalogen. Detta indikerar att mappen innehåller JavaScript-bibliotek.lib katalog i din css katalogen. Återigen indikerar detta att du har ett CSS-bibliotek.lib katalog i temakatalogen. Detta indikerar att det inte är JavaScript eller CSS och att det bidrar till funktionaliteten hos kärntemat (som till stor del består av PHP-funktionssamtal, malltaggar och så vidare).Självklart har jag också sett några utvecklare skapa en lib katalog och skapa sedan js, css, och php underkataloger inom lib katalogen. Det är lite av en inversion av de tips som anges ovan.
Det är inte en dålig strategi; men anledningen till att jag ogillar denna inställning är att den sprider JavaScript, CSS och PHP-filer i flera kataloger i temat.
Att skapa en organiserad katalogstruktur är bara en del av det. WordPress har en mallhierarki som kräver en viss namngivningskonvention. Överensstämmer det inte logiskt med att våra anpassade filer ska göra samma sak?
Dessutom, vad sägs om funktionernas namngivningskonventioner? Gör de eko data eller lämna tillbaka data? Utöver det vet vi hur vi vet att vi gör korrekta API-funktionssamtal och att vi inte använder utvunna funktioner i WordPress?
I nästa artikel kommer vi att prata om allt detta samt verktyg som vi kan installera som hjälper oss att undvika dessa fallgropar. Vi diskuterar också hur de fungerar och varför de tillsammans med funktionsnamnskonventioner spelar roll när man bygger teman.
För närvarande har vi dock täckt strategier för filorganisation som borde räcka för att hålla dig upptagen tills nästa artikel i serien publiceras.
Som vanligt, om du har något att lägga till, vänligen gör det i kommentarerna!
