Share
I det första inlägget i den här serien har vi granskat några av de strategier som finns tillgängliga när det gäller att organisera våra WordPress-tematekataloger för att göra dem mer underhållbara.
Specifikt berörde vi hur vi organiserar:
I slutändan var målet att tillhandahålla ett katalogschema där vi kunde organisera våra filer så att vi skulle ha en hög grad av sammanhållning, förståelse och underhåll för det arbete vi gör.
Men det är inte allt det finns att skriva underhållbara WordPress-teman. En annan är att följa de konventioner som framgår av WordPress Coding Standards; dock kommer denna artikel inte att ta en titt på standarderna. Codex gör ett bra jobb och vi har täckt dem i en annan serie.
I stället ska vi ta en lite mer granulär titt på några av de strategier och verktyg vi kan använda för att se till att vi gör våra teman så underhållbara som möjligt. I det här inlägget ska vi titta på strategier, så vi sätter ihop serierna genom att titta på några av de tillgängliga verktygen.
Som tidigare nämnts är det en sak att ha ett logiskt sätt att organisera alla kataloger, filer och bibliotek som utgör ditt tema. Men det är egentligen bara hälften av det som går in i att bygga ett tema.
Det finns trots allt fördefinierade mallar, funktioner, namngivningskonventioner och verktyg som alla bidrar till att antingen ta upp temat eller att testa på temat för att se till att det inte använder några avvecklade API-samtal och att det är kompatibelt med den senaste versionen av WordPress.
För det ändamålet anser jag att det är viktigt att förstå var och en av dessa ämnen både som en som bara börjar med att bygga WordPress-teman och som någon som har gjort det under en tid.
Det är trots allt aldrig bättre att försöka bli bättre på vad du gör. Dessutom är kommentarerna också ett bra ställe att fortsätta diskussionen för att dela med andra idéer.
Men innan vi kommer dit, låt oss faktiskt prata om några praktiska saker som vi kan göra när det gäller WordPress-teman och det ökar underhållet av vad vi gör.
Först om du inte är bekant med mallhierarkin rekommenderar jag starkt att du läser motsvarande Codex-sida innan du fortsätter med den här artikeln.
Kort sagt kan mallar beskrivas som följande:
WordPress Templates passar tillsammans som bitar av ett pussel för att skapa webbsidor på din WordPress-webbplats. Vissa mallar (t.ex. rubriken för sidhuvud och sidfot) används på alla webbsidor, medan andra endast används under specifika förhållanden.
Ett annat sätt att tänka på är det här: När det gäller WordPress kommer allt som visas för användaren från databasen. Detta inkluderar posttitel, postdata, postkategorier, inlägg, kommentarer och så vidare.
Mallar är de fordon genom vilka informationen presenteras för användaren. De är sammansatta av markup och PHP, utformad via CSS, och kan ha några effekter som tillämpas med hjälp av JavaScript.
Men, förutsatt att du inte gör någonting avancerade med saker som anpassade posttyper och / eller anpassade taxonomier (ett ämne för ett annat inlägg, verkligen), då finns det en unik sak om WordPress Template Hierarchy som kan fungera som både en lyx och ett underhållsproblem beroende på hur du tittar på det.
Observera att i den länkade Codex-artikeln kommer WordPress att ha standard index.php, header.php, och footer.php mallar. Sanningen är att du verkligen kan komma undan med att skapa ett helt WordPress-tema genom att använda endast index.php.
Låter snyggt, eller hur? Jag menar, vem behöver skapa så många olika filer när du kan skapa ett fint, litet, lutigt tema som gör allt du behöver göra.
Men tänk på det här ur perspektivet att arbeta med ett lag av dina egna kamrater, av dem som kan bidra till ett öppet förråd eller av de som eventuellt kan hämta upp var du slog av.
Om all kod som krävs för att göra information från databasen finns i en enda fil, är oddsen att komplexiteten hos den filen ökar från dess mycket skapande mycket hög.
På den mest grundläggande nivån tittar vi på en enda fil med ett antal villkor, möjliga några omkopplingsdeklarationer och så vidare. Och allt detta görs för att du måste redogöra för arkivsidorna, de enskilda postsidorna, de enskilda inläggen, den primära noteringen och så vidare.
Se vad jag menar?
Men då skapar du en separat fil bara att mildra den komplexiteten kan vara ett odjur på egen hand. Låt oss säga att du har single.php för att visa ett enda inlägg och du har page.php för att visa en sida och båda mallarna har exakt samma information bortsett från single.php har posta metadata och page.php gör inte.
Detta är ett utmärkt exempel på när du kan extrahera efter metadata till sin egen del, som vi diskuterade i föregående artikel. Eller kanske du kan extrahera koden som är ansvarig för att göra innehållet till dess egen partiell.
Vad som än är fallet är den punkt jag försöker göra att det finns en balans att slå när det gäller att arbeta med WordPress-mallar och WordPress Template Hierarchy.
Jag tycker inte att det är en bra idé att använda ett minimalt antal mallar, men jag tror inte att det är nödvändigt att använda varje stödd mall om det leder till för mycket kod duplicering. där är en balans som ska träffas mellan mallar och partier.
I slutändan tror jag att erfarenheten av hur man använder det som kommer med tiden, men med den här tankegången från början, kan bidra till att organisera och upprätthålla en nivå som språngar framför dig Maj börja inte ha gjort en liten bit av förplaneringen.
När det gäller att arbeta med funktioner och namngivningskonventioner är det oftast två tumregler att följa:
Accentsconagua
lämna tillbaka data och vad som ska eko dataMen om du är någon som bara har börjat i temautveckling, eller är du någon som vill förbättra sina färdigheter med det här, hur ser det här praktiskt ut?
När det gäller att namnge dina unika namn är orsakerna till att du gör det så att du inte oavsiktligt kolliderar med en befintlig funktion som definieras inom WordPress eller ett plugin som kan köras inom din miljö.
Låt oss till exempel säga att du ska skriva din egen funktion som kommer att filtrera innehållet innan du gör det till sidan. Det rätta sättet att göra detta är att självklart använda add_filter fungera; Men skulle du namnge din funktion innehållet?
Nej, självklart inte. Anledningen är att WordPress redan definierar innehållet. Om du byter namn på en funktion med det namnet kommer du att få fel. För det ändamålet är det alltid bäst att prefixa dina funktioner med en unik nyckel, t.ex. ett namn på ditt tema eller något liknande.
Så låt oss säga att vi vill lägga in en signatur till slutet av innehållet och låt oss säga att vi har ett tema vi ringer till Höjdpunkt. För att göra detta rekommenderar jag att du skapar en funktion som heter acme_the_content eftersom det identifierar tematets namn och anger namnet på den funktion som den är ansluten till.
Låt oss säga att du vill avsluta varje inlägg med ditt namn och Twitter-handtag. För att göra detta kan du definiera detta i din functions.php fil:
'; $ signatur. = 'Tom | @tommcfarlin'; $ signatur. = ''; returnera $ content. = $ signatur;
Det är relativt enkelt, eller hur? Kort sagt är det att jag försöker använda följande format när jag skapar mina egna krokfunktioner: THEME_NAME-name_of_hook.
Det gör det väldigt lätt att förstå och följa inte bara när du surfar koden, men när du tittar på de funktioner som utgör temat eller filen som för närvarande är aktiv i din IDE.
Som tidigare nämnts har WordPress en annan konvention som den använder och det har att göra med om information kommer att returneras från den uppringda funktionen eller echoed från den uppringda funktionen.
Lyckligtvis är denna speciella tumregel mycket lätt att komma ihåg:
skaffa sig_ skaffa sig_ Du kanske hittar några anomalier, men det är den allmänna delen av hur WordPress API indikerar hur det kommer att ge data tillbaka till dig när du har ringt upp funktionen.
I överensstämmelse med vårt tidigare exempel, låt oss att du vill echo data när funktionen heter, då skulle du bara ringa innehållet(); Om du däremot vill hämta innehållet från ett inlägg, säg, från en anpassad slinga, skulle du ringa get_the_content () och lagra den i din egen variabel.
Kanske något som detta: $ content_for_later = get_the_content (). Nu har du läst data för innehållet som för tillfället är relaterat till det aktiva inlägget i The Loop och du har lagrat det i en variabel som du kan använda senare.
Men att veta hur WordPress heter sina funktioner för dig är bara hälften av det. När allt kommer omkring planerar du att bygga ett tema eller ett plugin och vill se till att du håller dig konsekvent med "WordPress-sättet" att göra saker, rätt?
Fall i punkt: I exemplet ovan, där vi filtrerade innehållet prefixade vi funktionen så att den namngavs acme_the_content, vilket indikerar att Höjdpunkt temat kommer att returnera innehållet från varhelst det heter inom temat.
Vad skulle hända om vi skulle namnge funktionen acme_get_the_content () ?
Tja, tekniskt sett skulle funktionen fortfarande echo dataen varhelst den kallades; Det skulle emellertid vara inkonsekvent med WordPress API eftersom utvecklaren skulle förvänta sig att data skulle returneras till dem så att de skulle kunna lagra den i en variabel eller skicka den till en annan funktion.
Det finns en skillnad mellan vad användaren förväntar sig att hända och vad som faktiskt händer.
Om vi pratade om någonting i den verkliga världen, så skulle det vara som att ha en brytare på väggen för vilken användaren förväntar att när de vrider omkopplaren kommer ett ljus eller en fläkt att komma i samma rum när det i verkligheten kanske inte händer något eller ett ljus eller en fläkt i ett annat rum kommer på.
För det ändamålet måste vi vara försiktiga med namngivningen av våra funktioner så att vi inte bara skriver funktioner som inte kommer att kollidera med andra funktioner, men det är också tydligt namngivna, vilket indikerar på vilket sätt De kommer att hantera informationen när funktionen heter.
Som nämnts i början av denna artikel finns det också ett antal verktyg och inställningar som vi kan installera och konfigurera i vår utvecklingsmiljö som hjälper oss att fånga eventuella problem innan vi slutar lansera vårt tema.
Det innebär att vi kommer att kunna identifiera funktioner som i slutändan kommer att tas bort från WordPress så att vi inte skriver utdaterad kod. Dessutom finns det sätt att veta om variabler vi försöker få åtkomst till har inte, säg indexer som definieras eller andra liknande funktioner.
I den sista artikeln i serien kommer vi att titta på exakt det. Under tiden kan du granska vad som har täcks här, var god dela med dig av dina frågor och kommentarer i foderet nedan, och sedan ser vi ut att sätta in den här serien nästa vecka.
