Share
Når det gjelder å bygge WordPress-temaer - som med mange andre ting, egentlig - er det riktige måter og feil måter å gjøre det på. For de av oss som ønsker å være profesjonelle WordPress-utviklere, for de av oss som virkelig bryr seg om det arbeidet vi gjør, og for de av oss som vil at vårt arbeid skal vare, må vi være fremtidsrettet om hvordan Vi organiserer filene og koden som går inn i temaet vårt.
Ja, WordPress Codex tilbyr en fantastisk artikkel om temautvikling, og jeg tror at det burde være nødvendig å lese for alle som kommer inn i å bygge temaer - spesielt Premium-temaer - men det er noen strategier som det ikke dekker som jeg har funnet å være svært nyttig, da det gjelder bygging, utgivelse og vedlikehold av temaer over tid.
I de neste to artiklene skal vi se på noen strategier som går litt dypere inn i temautvikling som vil hjelpe oss med å strukturere våre temaer på en slik måte at de ikke bare følger retningslinjene i WordPress Codex, men vil også gjøre det mye lettere å vedlikeholde, oppdatere og forbedre ikke bare når WordPress beveger seg fremover, men som temaet også modnes.
Kvaliteten på organisasjonen av filene og koden som går inn i å bygge WordPress-temaer er noe av et hett tema.
For å være klar er dette en av de tingene som utviklere og designere elsker å snakke om til et punkt der det har formet seg noe som folk elsker å hate. Det vil si at andre ofte vil kommentere om dårlig kvalitetstemaer som er tilgjengelige for WordPress, og vil da bruke det argumentet som en grunn til hvorfor WordPress er en dårlig plattform, ikke bare for blogging, men av andre grunner også.
Det er ikke meningen eller argumentet om hva vi skal diskutere her, og det er heller ikke ment å inspirere den typen diskusjon i kommentarene. I stedet antar denne todelte serien følgende:
Selvfølgelig, vi alle har egne måter å gjøre ting på, slik at anbefalingene som deles gjennom hele denne serien, kanskje ikke fungerer med din nåværende arbeidsflyt. Kanskje du ikke vil endre - og det er greit! - eller kanskje du leter etter en endring.
Uansett hva som skjer, er alt som deles her, basert på erfaring med å bygge og opprettholde premium WordPress-temaer, og har gjort det mye lettere å vedlikeholde dem over tid, både fra et temespesifikt synspunkt, men fra et WordPress-kompatibilitetssynspunkt, så vel.
En av de vanskeligste delene av byggeprogramvare leverer ikke den første versjonen (selv om det er tøft i seg selv), men det opprettholder produktet etter utgivelsen.
Dette innebærer ikke bare at kodebasen fortsetter å være kompatibel med den underliggende infrastrukturen - som vi skal snakke om i neste avsnitt - men at filene er organisert på en slik måte at de utgjøres av utviklingslaget , at de har et nivå av kohesjon, og at de har et rim og grunn til hvorfor de blir navngitt og plassert i den måten de er.
Vi vet fra Codex at det finnes en rekke filer som utgjør kjernen i temaet. Dette inkluderer maler, en funksjonsfil og minst ett stilark.
Hva skjer, men når temaet blir mer komplisert? Si at du ...
Alt ovenfor kan være rent organisert i et WordPress-tema katalog. Vi tar en titt på hver av disse i litt mer detaljert og begrunnelsen bak deres plassering i temakatalogen i håp om at dette gjør temautviklingen renere, og at dette gjør vedlikeholdsfriheten lettere.
Selv om de i mange sammenhenger kan diskuteres uavhengig av hverandre, siden de er ansvarlige for forskjellige ting, er deres organisasjonsstruktur innenfor et tema så lik at det er fornuftig å gruppere dem sammen.
For det første, forutsatt at du ikke bruker noen type CSS-forprosessor, bør det være en katalog for hver av disse filtypene. Det er, du burde ha en css katalog og a js katalog (eller kanskje du ringer dem stiler og javascript).
Uansett, bør hver filtype være i sin egen katalog. Derfra kan du bruke functions.php å registrere og legge til filene etter behov. Hvis det er en fil som brukes over temaet, registreres det ubetinget.
Men hvis det er en stil eller et skript som bare brukes på en bestemt mal, en bestemt innleggstype, eller til og med på en del av instrumentbrettet, kan du - og burde - kreve filen betinget.
Men la oss si det er bruker en forprosessor. På dette tidspunktet vil du bli igjen med din forhåndsbehandlede fil og dine etterbehandlede filer. Avhengig av arten av prosjektet ditt, kan du kanskje ikke ha alt redusert til en enkelt fil.
Jeg ville Lag anbefaling for hvordan å navngi filer; Men variasjonen i temaer, hvordan folk bygger sitt arbeid, og problemet et bestemt tema, prøver å løse saker, og det får oss utover omfanget av denne strategien..
Uansett, hvis du skal bruke en forprosessor, anbefaler jeg at du oppretter en underkatalog i css og js kataloger kalt dev (eller utvikling eller hva du velger å kalle det). I denne katalogen skriver du alle dine ferdigbehandlede filer, så lar du verktøyet ditt (enten det er CodeKit, Grunt eller noe sånt), utgjøre den behandlede filen / filene i roten til css og js kataloger.
På denne måten har du fortsatt behandlet, kombinert og / eller minifisert kode, og du har en katalog som inneholder kilden til disse filene. Når det kommer tid til å sende temaet, har du ikke bare funksjoner.php-ringerfiler i deres respektive kataloger, men du kan også ekskludere dev katalog fra den endelige bygningen slik at sluttbrukeren får en mindre temapakke, og får ingenting mer enn de trenger for å kjøre temaet.
Malte deler kalles ofte delvise (mer på andre språk enn i WordPress) og kalles ofte ved å bruke get_template_part i WordPress. Kort sagt, deres formål er å trekke ut repeterende kode som lett kan innlemmes i flere maler.
Et eksempel på dette ville være å si post-metadataene. Dette inkluderer vanligvis følgende informasjon:
Siden denne informasjonen kan eksistere i flere maler (tenk enkelt innlegg, sider, arkiver osv.), Ville det være fornuftig å trekke den ut i en enkelt fil og bare referere til den ene filen når du trenger det.
Saken er, post metadata er ikke den bare type informasjon som gjenbrukes gjennom et tema. Til dette formål identifiserer du kjerneelementene som blir gjenbruk, abstrakt dem inn i en fil, og opprett deretter en partials katalog.
Derfra navn hver maldel noe som indikerer hva det representerer (for eksempel post-meta.php, gravatar.php, navigation.php, pagination.php, og så videre) og deretter ringe til partiet i malen der det er nødvendig.
For eksempel, i innlegg, side og arkivmaler kan du ringe get_template_part ('partials / post-meta');. Gjør det lettere å lese og gjøre for en enkelt stedet for å gjøre en endring i stedet for i hver mal.
Hvis du skriver et tema som er internasjonalisert, og hvis du slipper det for offentligheten, bør du gjøre det, så er det veldig klart og rent måte å gjøre dette på.
Først, hvis dette er et nytt emne for deg, så anbefaler jeg at du leser artikkelen i Codex. Det vil fortelle deg alt du trenger å vite om hvordan du klargjør strenge for oversettelse, tilgjengelige verktøy og så videre.
Deretter anbefaler jeg at du sørger for at du har et dedikert sted i temaet ditt for språkene dine. Generelt anbefaler jeg at du oppretter en katalog i navnet ditt lang eller språk og deretter slippe .po og .mo filer i nevnte katalog. Dette er også en allment akseptert og forventet praksis i WordPress-fellesskapet som helhet.
Ikke bare overlater dette oversettelsene til sitt eget sted i temastrukturen, men det indikerer også til andre hvor du skal søke etter oversettelser og hvor du skal lete etter filene som tilbyr strengene som må oversettes.
Igjen handler det om kohesjon og å sørge for at ting av lignende verktøy grupperes sammen på en rimelig måte.
Avhengig av bakgrunnen i utviklingen, funksjoner som du bruker for å hjelpe deg med å få jobbet og for å hjelpe til med å skille virksomhetslogikk fra presentasjonslogikk (eller i mange av våre tilfeller, rett fra PHP), kalles hjelpefunksjoner eller bruksfunksjoner.
For formålet med denne serien, refererer vi til dem som hjelperfunksjoner, men vet at de er alle en i det samme.
Men dette reiser to spørsmål:
Accentsconagua
functions.php?functions.php, hvor bor de?Kort sagt, jeg er av tankene at hjelpere og verktøy skal ikke bor i functions.php. Min tommelfingerregel er bare dette: Hvis koden jeg skriver direkte kommuniserer med WordPress som add_theme_support, så hører den inn i functions.php. Men hvis det er kode som jeg skriver som skal kjøre en egendefinert spørring for å hente informasjon og gi det behandlede resultatet tilbake til malen (eller maldelen), tilhører den i en hjelperfunksjon.
Akkurat som WordPress har maltekoder eller malfunksjoner som kan kalles gjennom en mal, for eksempel innholdet(), behandle hjelpefunksjoner på en lignende måte - du kan ringe dem i maler og i delene dine, men de er plassert i egen fil.
Siden disse hjelperfunksjonene ikke lever i functions.php, da burde de bor i sin egen fil, og den filen skal refereres et sted i temaets kodebase, ikke sant? På toppen av det er det også helt mulig at du kan bryte opp dine hjelpere til flere filer, basert på temaets kompleksitet.
For det formål anbefaler jeg å introdusere en inc eller en inkluderer katalog i kjernen av temaet ditt. Derfra plasserer du hjelpeordene dine i den katalogen og er enkle include_once Hjelperfilen øverst i funksjonsfilen din og funksjonene vil være lett og lett tilgjengelig gjennom resten av temaet.
Til slutt er det tider hvor vi vil inkludere tredjepartsbiblioteker i våre temaer. Enkelt sagt, disse er verktøy som er utviklet av andre som er fritt tilgjengelige for bruk og distribusjon, som også gjør det enkelt for oss å piggyback på andres arbeid.
Så hvor skal de bo? Ærlig, dette avhenger av hvilken type bibliotek det er som du arbeider med. Bibliotek kan for eksempel komme i form av CSS, JavaScript eller PHP. Som sådan bør det være et sted for det:
lib katalog i din js katalogen. Dette indikerer at mappen inneholder JavaScript-biblioteker.lib katalog i din css katalogen. Igjen, dette indikerer at du har et CSS-bibliotek.lib katalog i roten til temakatalogen. Dette indikerer at det ikke er JavaScript eller CSS, og at det bidrar til funksjonaliteten til kjernetemaet (som i stor grad består av PHP-funksjonssamtaler, maltekoder og så videre).Selvfølgelig har jeg også sett noen utviklere opprette en lib katalog og deretter opprette js, css, og php underkataloger innenfor lib katalogen. Det er litt av en inversjon av tipsene som er gitt ovenfor.
Det er ikke en dårlig strategi; Men grunnen til at jeg ikke liker denne tilnærmingen er at den sprer JavaScript, CSS og PHP-filer inn i flere kataloger i temaet.
Opprette en organisert katalogstruktur er bare en del av det. WordPress har et mal hierarki som krever en bestemt navngivningskonvensjon. Følger det ikke logisk at våre tilpassede filer skal gjøre det samme?
Videre, hva med navnekonvensjonene av funksjoner? Gjør de ekko data eller komme tilbake data? Dessuten vet vi hvordan vi gjør riktige API-funksjonssamtaler, og at vi ikke bruker utdaterte funksjoner i WordPress?
I neste artikkel snakker vi om alt dette, samt verktøy som vi kan installere som hjelper oss med å unngå de fallgruvene. Vi vil også diskutere hvordan de jobber, og hvorfor de sammen med funksjonenavnerkonvensjoner er viktige når du bygger temaer.
For nå har vi imidlertid dekket strategier for filorganisasjon som bør være nok til å holde deg opptatt til neste artikkel i serien er publisert.
Som vanlig, hvis du har noe å legge til, vennligst gjør det i kommentarene!
