Share
I det første innlegget i denne serien har vi gjennomgått noen av strategiene som er tilgjengelige når det gjelder å organisere våre WordPress-temakataloger for å gjøre dem mer vedlikeholdsbare.
Spesielt berørte vi hvordan vi organiserer:
Til slutt var målet å gi et katalogskjema der vi kunne organisere våre filer slik at vi ville ha et nivå av kohesjon, forståelse og vedlikehold i arbeidet vi gjør.
Men det er ikke alt der er å skrive vedlikeholdbare WordPress-temaer. En annen er å følge konvensjonene som er angitt av WordPress Coding Standards; Men denne artikkelen kommer ikke til å ta en titt på standardene. Codex gjør en fin jobb med det, og vi har dekket dem i en annen serie.
I stedet skal vi ta et litt mer granulært blikk på noen av strategiene og verktøyene som vi kan bruke for å sikre at vi gjør våre temaer så vedlikeholdsfrie som mulig. I dette bestemte innlegget skal vi se på strategier, så vi pakker opp serien ved å se på noen av de tilgjengelige verktøyene.
Som tidligere nevnt er det en ting å ha en logisk måte å organisere alle kataloger, filer og biblioteker som utgjør temaet ditt. Men det er egentlig bare halvparten av det som går inn i å bygge et tema.
Tross alt er det forhåndsdefinerte maler, funksjoner, navngivningskonvensjoner og verktøy som alle bidrar til enten å lage temaet eller å teste på temaet for å sikre at det ikke bruker noen utdaterte API-anrop, og at den er kompatibel med den nyeste versjonen av WordPress.
For det formål synes jeg det er viktig å forstå hvert av disse emnene både som en som nettopp har begynt å bygge WordPress-temaer, og som noen som har gjort det for en stund.
Tross alt er det aldri en bedre tid å prøve å bli bedre på hva du gjør. Dessuten er kommentarene også et flott sted å fortsette diskusjonen for å dele alternative ideer.
Men før vi kommer dit, la oss faktisk snakke om noen praktiske ting vi kan gjøre som det gjelder WordPress-temaer, og det øker vedlikeholdet av det vi gjør.
For det første, hvis du ikke er kjent med mallhierarkiet, anbefaler jeg at du leser den tilsvarende Codex-siden før du fortsetter med denne artikkelen.
Kort sagt kan maler beskrives som følgende:
WordPress Templates passer sammen som stykkene av et puslespill for å generere nettsidene på ditt WordPress-nettsted. Noen maler (for eksempel header- og bunntekstmalfiler) brukes på alle nettsidene, mens andre kun brukes under bestemte forhold.
En annen måte å tenke på er dette: Når det gjelder WordPress, kommer alt som vises til brukeren fra databasen. Dette inkluderer posttittel, postdata, postkategorier, innleggsinnhold, kommentarer, og så videre.
Maler er kjøretøyene der informasjonen presenteres for brukeren. De er sammensatt av markup og PHP, utformet via CSS, og kan ha noen effekter påført ved bruk av JavaScript.
Men, forutsatt at du ikke gjør noe avansert med ting som egendefinerte innleggstyper og / eller egendefinerte taksonomier (et emne for et annet innlegg egentlig), så er det en unik ting om WordPress Template Hierarchy som kan tjene som både en luksus og Et vedlikeholdsproblem avhengig av hvordan du ser på det.
Merk at i den koblede Codex-artikkelen vil WordPress ha standard index.php, header.php, og footer.php maler. Sannheten er at du virkelig kan komme unna med å lage et helt WordPress-tema ved å bruke bare index.php.
Høres litt attraktivt, ikke sant? Jeg mener, hvem trenger å lage så mange forskjellige filer når du kan lage et fint, lite, magert tema som gjør alt du trenger det gjør.
Men så tenk på dette fra perspektivet til å jobbe med et lag av dine egne jevnaldrende, av de som kan bidra til et åpent lager, eller av dem som til slutt kan plukke opp hvor du sluttet.
Hvis all koden som kreves for å gjengi informasjon fra databasen er inneholdt i en enkelt fil, er det svært høyt at kompleksiteten til den filen øker fra selve etableringen..
På det mest grunnleggende nivå ser vi på en enkelt fil med en rekke conditionals, muligvis noen bytte påstander og så videre. Og alt dette er gjort fordi du må registrere arkivsidene, de enkelte innleggssidene, de enkelte innleggene, den primære oppføringen og så videre.
Ser du hva jeg mener?
Men da lager du en egen fil bare å redusere at kompleksiteten kan være et dyr alene. For eksempel, la oss si at du har single.php for å vise et enkelt innlegg, og du har page.php for å vise en side, og begge maler har nøyaktig samme informasjon unntatt single.php har post metadata og page.php gjør ikke.
Dette er et godt eksempel på når du kan trekke ut metadata i sin egen del, som vi diskuterte i forrige artikkel. Eller kanskje du kan trekke ut koden som er ansvarlig for å gjøre innholdet til det er eie delvis.
Uansett hva som er tilfelle, er poenget jeg prøver å gjøre, at det er en balanse som skal treffes når det gjelder å jobbe med WordPress-maler og WordPress Template Hierarchy.
Jeg tror ikke det er en god ide å bruke et minimalt antall maler, men jeg tror heller ikke at det er nødvendig å bruke hver enkelt støttet mal hvis det fører til for mye kode duplisering. Der er en balanse som skal treffes mellom maler og partier.
Til syvende og sist tror jeg at opplevelsen på hvordan du bruker det som kommer med tiden, men å ha denne tankegangen fra begynnelsen, kan bidra til å gi et nivå av organisering og vedlikehold som er hopp og grenser foran deg der du kan begynn å ikke ha gjort bare litt pre-planlegging.
Når det gjelder å jobbe med funksjoner og navngivningskonvensjoner, er det vanligvis to tommelfingerregler som følger:
Accentsconagua
komme tilbake data og hva som vil ekko dataMen hvis du er noen som nettopp har begynt i temautvikling, eller er du noen som ønsker å forbedre sine ferdigheter i å gjøre dette, hvordan ser dette praktisk talt ut?
Når det gjelder å unike navn på dine funksjoner, er årsakene til at du gjør dette, slik at du ikke ved et uhell kolliderer med en eksisterende funksjon som er definert i WordPress eller et plugin som kan kjøre i ditt miljø.
For eksempel, la oss si at du skal skrive din egen funksjon som vil filtrere innholdet før du gjør det til siden. Den riktige måten å gjøre dette på er å åpenbart bruke add_filter funksjon; Men vil du nevne din funksjon innholdet?
Nei selvfølgelig ikke. Årsaken er at WordPress allerede definerer innholdet. Hvis du omdøper en funksjon med det navnet, kommer du til å få feil. For det formål er det alltid best å prefiks dine funksjoner med en unik nøkkel, for eksempel et navn på temaet ditt eller noe lignende.
Så la oss si at vi ønsker å prepend en signatur til slutten av innholdet, og la oss si at vi har et tema vi ringer Acme. For å gjøre dette, anbefaler jeg å opprette en funksjon som kalles acme_the_content fordi den identifiserer navnet på temaet og angir navnet på funksjonen som den er hekta på.
La oss si at du vil avslutte hvert innlegg med ditt navn og Twitter håndtak. For å gjøre dette kan du definere dette i din functions.php fil:
'; $ signatur. = 'Tom | @tommcfarlin'; $ signatur. = ''; returner $ content. = $ signatur;
Det er relativt grei, ikke sant? Kort sagt er det at jeg prøver å bruke følgende format når jeg lager mine egne tilkoblede funksjoner: THEME_NAME-name_of_hook.
Dette gjør det veldig enkelt å forstå og følge ikke bare når du surfer på koden, men når du ser på funksjonene som utgjør temaet eller filen som er aktiv i IDE-en din.
Som nevnt tidligere har WordPress en annen konvensjon som den bruker og det har å gjøre med hvis informasjon skal returneres fra den kalt funksjonen eller ekko fra den kalt funksjonen.
Heldigvis er denne spesielle tommelfingerregelen veldig lett å huske:
få_ få_ Du kan finne noen uregelmessigheter, men det er det generelle kjennetegnet av hvordan WordPress API angir hvordan det vil gi dataene tilbake til deg når du har ringt til funksjonen.
I samsvar med vårt tidligere eksempel, la det være at du vil ekko dataene når funksjonen kalles, så vil du bare ringe innholdet(); Men hvis du vil hente innholdet fra et innlegg, si, fra en tilpasset sløyfe, vil du ringe get_the_content () og lagre den i din egen variabel.
Kanskje noe sånt: $ content_for_later = get_the_content (). Nå har du lest dataene for innholdet som for øyeblikket er relatert til det aktive innlegget i The Loop, og du har lagret det i en variabel som du kan bruke senere.
Men å vite hvordan WordPress navngir sine funksjoner for deg, er bare halvparten av det. Tross alt planlegger du å bygge et tema eller et plugin og vil sørge for at du holder deg i overensstemmelse med "WordPress-måten" å gjøre ting, riktig?
Tilfelle i punkt: I eksemplet ovenfor, hvor vi filtrerte innholdet, prefikserte vi funksjonen slik at den ble oppkalt acme_the_content, som indikerer at Acme temaet kommer til å returnere innholdet uansett hvor det kalles innenfor temaet.
Hva skulle skje hvis vi skulle navngi funksjonen acme_get_the_content () ?
Vel, teknisk sett, ville funksjonen fortsatt ekko dataene hvor det ble kalt; Det ville imidlertid være uoverensstemmende med WordPress API fordi utvikleren ville forvente at dataene skulle returneres til dem slik at de ville kunne lagre det i en variabel eller sende det til en annen funksjon.
Det er en uoverensstemmelse mellom hva brukeren forventer å skje og hva som faktisk skjer.
Hvis vi snakket om noe i den virkelige verden, ville dette være som å ha en bryter på veggen som brukeren forventer at når de slår bryteren, kommer et lys eller en vifte på samme rom når det i virkeligheten kanskje ikke skjer noe eller et lys eller en vifte i et annet rom kommer på.
For det formål må vi være forsiktige med å navngi funksjonene våre slik at vi ikke bare skriver funksjoner som ikke vil kollidere med andre funksjoner, men det er også tydelig navngitt, og det indikerer hvordan De vil håndtere informasjonen når funksjonen kalles.
Som nevnt i begynnelsen av denne artikkelen finnes det også en rekke verktøy og innstillinger som vi kan installere og konfigurere i vårt utviklingsmiljø som vil hjelpe oss med å fange eventuelle potensielle problemer før vi ender opp med å lansere vårt tema.
Dette betyr at vi vil kunne identifisere funksjoner som til slutt skal fjernes fra WordPress, slik at vi ikke skriver utdatert kode. I tillegg er det måter å vite om variabler vi prøver å få tilgang til, ikke har, si indekser som er definert, eller andre lignende funksjoner.
I den endelige artikkelen i serien skal vi se nærmere på det. I mellomtiden kan du se gjennom hva som er dekket her, vær så snill å dele dine spørsmål og kommentarer i feedet under, og så ser vi til å pakke denne serien opp neste uke.
