DRY WordPress Theme Development

Når du bygger et WordPress-tema, er det verdt å ta litt tid til å identifisere hvor du kan unngå repetisjon av kode. Dette gir deg ganske mange fordeler:

• Du må bare skrive koden en gang, noe som gjør deg mer effektiv.
• Hvis du kommer til å redigere koden i fremtiden, må du bare gjøre det en gang.
• Alle andre som arbeider med temaet ditt, blir ikke forvirret av flere iterasjoner av samme kode.
• Temaet ditt vil ha mindre kode, som kan gi ytelsesfordeler.

Etter min erfaring er det viktigste av disse punktene det andre: Når jeg har redigert temaer uansett grunn, blir oppgaven enklere dersom hvert stykke kode bare er der en gang.

I denne veiledningen vil jeg vise deg noen av måtene du kan adoptere Gjenta ikke selv, eller DRY, prinsippet i temautviklingen, noe som gjør deg mer effektiv og mindre stresset i prosessen. 

Hva er ikke å like?

1. Bruk av rammer og starttemaer

Ved hjelp av et rammeverk, enten en tredjeparts en eller en som du utvikler deg selv, betyr det at mye av koden du trenger, allerede vil være der for deg når du begynner, og at du ikke finner deg selv å skrive den samme koden igjen og igjen (eller til og med i det hele tatt).

Hvor mye kode du trenger i ditt rammeverk, vil være opp til deg - du kan foretrekke å bruke et barebones-rammeverk som du deretter legger til, eller en mer omfattende en der du velger funksjonalitet for prosjektet ditt.

I tillegg til rammer er det et økende antall starterstemaer som er tilgjengelige for å øke hastigheten på kodingen. For tiden er det vanligste temaet, som gir deg de bare beinene du trenger for å raskt lage WordPress-temaer.

Alternativt kan du foretrekke å lage dine egne starttemaer, som inkluderer den grunnleggende koden du bruker gang på gang på prosjekter. Du kan lage en enkel en du legger til eller en rekke forskjellige versjoner for ulike typer prosjekter.

2. Bruke maldeler

Du får mest mulig bang for pengene dine når det gjelder DRY-temaer hvis du bruker maldeler. Den mest åpenbare av disse er topptekstene, bunntekstene og sidebarfilene, men du kan også bruke loop-filer og andre maldeler for å gjøre koden din mer effektiv.

Header, Sidebar og Footer

Forhåpentligvis trenger du ikke meg å fortelle deg dette - du bør ALDRI bruke separate malfiler for overskriften din (header.php), sidebjelke (sidebar.php) og bunntekst (footer.php). Du kaller dem i hver av dine malfiler ved hjelp av disse malene:

• get_header ()
• get_sidebar ()
• get_footer ()

Men du behøvde ikke meg å fortelle deg det, så la oss gå videre til mer avansert bruk av maldeler.

Flere topptekster, sidefelt eller bunntekster

Noen ganger vil du kanskje bruke en annen topptekst, sidebar eller bunntekst for forskjellige områder på nettstedet ditt. Du kan gjøre dette enkelt ved å opprette flere filer.

For eksempel, la oss si at du vil bruke et annet sidefelt på arkivsidene dine. Du vil opprette en fil for dette sidebaret sidebar-archive.php. I din archive.php malfil, vil du da erstatte standarden get_sidebar () tag med get_sidebar ('arkiv').

Dette gir deg fleksibiliteten til å ha en ekstra sidefelt, som du kan bruke i flere malfiler. For eksempel vil du kanskje bruke den i arkivmaler for bestemte posttyper. Så hvis du hadde en posttype som heter knapp, du vil opprette en arkivmal for den som heter arkiv-button.php, og i det ville du bruke get_sidebar ('arkiv') stikkord.

Det er noen ulemper for denne tilnærmingen: Hvis din sidebar.php og sidebar-archive.php filer har mye repeterende kode, temaet ditt følger ikke DRY-prinsippet nært nok. Hvis dette er tilfelle, kan du velge å bruke betingede koder i stedet, som jeg vil dekke senere i denne opplæringen.

Andre maldeler

I tillegg til maldeler for topptekst, bunntekst og sidebar, kan du også opprette andre malte deler. Du ringer deretter disse maldelene ved hjelp av get_template_part () stikkord.

Den vanligste bruken av dette er for løkken. Sløyfen er en del av koden, ofte gjentatt i flere maler, så det er fornuftig å ta det ut av hver av disse malene og sette det i en egen fil.

For å gjøre dette, oppretter du en fil som heter loop.php med koden for sløyfen din og så kaller du den ved hjelp av get_template_part ('loop'). Dette trekker effektivt hele koden fra loopfilen din til malen.

Du kan ta dette videre med flere sløyfer. For eksempel hvis du hadde en litt annerledes sløyfe for arkiver, ville du opprette en fil som heter sløyfe-archive.php og ring det ved hjelp av get_template_part ('loop', 'archive'). Enkel!

3. Bruke betingede etiketter

Noen ganger er det mer effektivt å bruke betingede koder i stedet for separate malfiler. WordPress leveres med et sett med betingede koder du kan bruke til å sjekke hvilken innholdstype som blir vist på et gitt tidspunkt, eller hvilken sidemal brukes. Så du kan bruke dem til å sjekke om en bestemt mal er i bruk og deretter legge til noen kode hvis den er. Dette sparer deg for å opprette en ekstra malfil hvis malfilene dine har mye duplisert kode.

Jeg skal illustrere dette med et eksempel. La oss si at du har et sidebar med et widget-område registrert. På de enkelte sidene for en gitt innleggstype, vil du legge til et annet widgetområde. Det kan hende du vil gjøre dette hvis du vil vise andre innlegg av den posttypen i en widget, for eksempel.

Du kan opprette en egen sidebarfil som heter sidebar-xxx.php, hvor xxx er posttypen din, og deretter ring det i malfilen for innleggstypen din. Eller du kan bare bruke en sidebarfil med en betinget kode for å legge til det ekstra widgetområdet som følger:

I din sidebar.php fil, vil du allerede ha et widget-område registrert, noe som kan se slik ut:

Dette vil vise sidebar-widget-området hvis det har blitt fylt med widgets.

Du kan deretter legge til et andre sidebjelke ved hjelp av is_singular () betinget kode:

hvis (is_singular ('xxx') && is_active_sidebar ('xxx-sidebar-widget-området')) ?>  
Dette kontrollerer om widgetområdet er fylt på samme måte som det første eksemplet, men legger til en ekstra sjekk til det hvis uttalelse: is_singular ('xxx'). Dette kontrollerer om nettstedet for øyeblikket viser en enkelt side for xxx posttype. Hvis det er tilfelle, og widget-området er fylt, vil det bli vist.
 4. Slå gjentakende kode inn i en funksjon
Hvis koden din blir gjentatt igjen og igjen gjennom hele nettstedet, og det gir seg ikke til å bli satt inn i en egen fil, så er en annen løsning å sette den i en funksjon og deretter ringe den funksjonen hvor som helst i malken din vil at koden skal vises.
For eksempel kan det hende du har noen kode for å vise en oppringingsboks:
 // CTA innhold går her 
Å gjenta den samme koden på flere steder i temaet ditt, ville være dårlig praksis, da det ville legge til ekstra kode og gjøre det svært vanskelig for deg å endre koden nøyaktig hvis du skulle i fremtiden. I stedet kan du pakke det inn i en funksjon, og deretter plassere den funksjonen på relevante steder i temaet ditt.
Din funksjon ville se slik ut:
funksjon wptp_cta () ?> 
 // CTA innhold går her 
 
Deretter ville du bare skrive funksjonen i den aktuelle malfilen hvis du skulle trenge oppfordringsboksen din til å vises på steder i temaet ditt, for eksempel sidebjelker eller bunntekster.
wptp_cta ();
Den store fordelen med dette er at hvis du vil endre handlingen til handling i fremtiden, trenger du bare å endre funksjonen en gang, og endringen vil bli reflektert overalt hvor du har kalt den i temaet ditt.
 5. Hooking Code til Action Hooks
Det neste trinnet i DRY temautvikling er å benytte handlingshager i temaet ditt.
Du lager en handlingskrog ved hjelp av do_action () funksjon, og deretter legger du til funksjoner på den kroken ved hjelp av ADD_ACTION ().
Dette gir deg mye mer fleksibilitet i hvordan du bruker din gjentakende kode, og lar deg spesifisere ikke bare hvor i temaet ditt det vil vises, men under hvilke omstendigheter, ved hjelp av en kombinasjon av funksjoner og betingede koder.
Det betyr også at hvis du oppretter barnemner som bruker det opprinnelige temaet som et overordnet tema, kan du legge til funksjoner i barnetemaet til funksjonen fra foreldetemaet.
Jeg kommer tilbake til mitt sidefelt eksempel. I stedet for å kodes widgetområdet i min sidebar.php fil, legger jeg bare til en handling for det, og gir det et unikt navn:
do_action ('wptp_sidebar');
Dette skaper en handlingskrog i temaet mitt, som jeg kan legge til tilpassede funksjoner.
I min functions.php fil, koble jeg koden for standard sidefelt til denne handlingen som følger:
funksjon wptp_sidebar_default () if (is_active_sidebar ('sidebar-widget-området')) ?>  
Jeg har brukt ADD_ACTION () med to parametere: wptp_sidebar, navnet på kroken, og wptp_sidebar_default, navnet på funksjonen.
Så det er standard sidebar lagt til temaet mitt. For å legge til sidefeltet for posttypen, legger jeg til en annen funksjon i min functions.php fil og hek det til samme handlekrok:
funksjon wptp_xxx_sidebar () if (is_singular ('xxx') && is_active_sidebar ('xxx-sidebar-widget-området')) ?>  
Dette bryter min andre sidebar i en funksjon og deretter branner som fungerer på wptp_sidebar action hook også. Et par ting å merke seg:
 
Den betingede taggen går inn i funksjonen og ikke med ADD_ACTION funksjon.
 
Jeg har lagt til en prioritet av 15 til min andre funksjon. Som standardprioritet (som vil bli tildelt min første funksjon) er 10, betyr dette at WordPress vil brenne denne andre funksjonen etter den første, slik at xxx sidebar vil vises under standard en.
 
Sammendrag
Ideene jeg har dekket ovenfor er ikke en uttømmende liste over metoder for å vedta DRY-prinsippet når du utvikler WordPress-temaer, men de gir en introduksjon til noen av de mest effektive metodene du kan bruke.
Hvis du vil sikre at temaene dine er så effektive som mulig, vil jeg anbefale å ta deg tid til å planlegge temaets struktur før du begynner å skrive kode. Identifiser hvor koden vil bli duplisert og hvilken tilnærming ville være best for å hindre gjentakelse av kode og innsats. Arbeid deg gjennom ideene ovenfor, ved hjelp av den som vil spare deg mest tid og kode. Dette vil hjelpe deg med å utvikle temaet videre i fremtiden.



		
			
	   
	




Kode