Bestemmer hvordan du utvikler ditt WordPress Theme Framework

I første del av denne serien redegjorde jeg for hvordan temarammer fungerer og de ulike typene rammebetingelser det er.

Før du kan begynne å bygge ditt eget rammeverk, må du vurdere hvordan det skal fungere og hva det skal brukes til, slik at du kan bruke den mest hensiktsmessige utviklingsmetoden fra begynnelsen.

I denne opplæringen tar jeg deg gjennom de faktorene du må vurdere, blant annet om rammen din vil være offentlig eller privat, om den vil bli brukt av ikke-kodere eller utviklere, og hvilke tilleggsfunksjoner du vil inkludere.

Det er to deler å bestemme seg for tilnærmingen din: å identifisere hvordan rammen din skal brukes, og basert på det, og identifisere hva du trenger å inkludere i det.

Hvordan blir temarammen din brukt?

Måten temarammen skal brukes vil påvirke hva du inkluderer i det og hvordan du strukturerer det. 

Vurder følgende:

• Er temarammen din bare for deg eller for andre utviklere?
• Er rammen din vil bli brukt av utviklere eller brukere med ingen eller liten kodingserfaring?
• Vil temarammen din være offentlig eller privat?

Bare for deg eller for andre?

Hvis rammen din er bare for personlig bruk, må du bare tenke på dine egne behov når du utvikler det. Det er imidlertid fornuftig å fremtidssikre det og gjøre det så robust som mulig, så du bør:

• bruk WordPress-kodingsstandardene
• vedta DRY (ikke repeter selv) prinsippet
• bruk kode som du kan validere ved hjelp av W3Cs valideringskontroller. Du bør også sørge for at koden din er tilgjengelig
• inkludere kommentarer - selv om noen andre ikke ser på koden din, vil du bli overrasket over hvor lett det er å glemme hva et stykke kode gjør når du kommer til å redigere det mange måneder senere
• bruk versjonskontroll for oppdateringer til rammene dine

W3C-markeringsvalideringsverktøyet

Hvis rammene dine vil bli brukt av andre utviklere, kanskje dine kolleger, må du vedta alle de ovennevnte rutinene, og det kan også hende du må:

• gi dokumentasjon med en oversikt over rammeverkets struktur, funksjoner og kroker
• vurdere hvordan du vil dele og samarbeide på kode - ved hjelp av et samarbeidssystem som GitHub vil gjøre dette mye lettere
• dokumentere versjoner eller lenke dem til milepæler og / eller utgivelser på GitHub.

For utviklere eller brukere?

Noen temarammer er rettet mot ikke-kodende brukere som kan tilpasse rammen mye uten å skrive noen kode, mens andre er rettet mot utviklere, og gir kroker og funksjoner de kan bruke til å tilpasse og forlenge rammen. Andre er egnet for begge, med et omfattende brukergrensesnitt og en API.

Bare fordi rammene dine vil bli brukt av ikke-utviklere, betyr det ikke nødvendigvis at du skal slippe det for offentligheten - du kan ha designkollegaer som du vil gi tilgang til det, eller du kan la kundene bruke det til tilpassinger til deres nettsted.

Hvis rammene dine er for ikke-kodende brukere, må du inkludere:

• en eller flere temaalternativer-skjermer hvor brukerne kan gjøre sine tilpasninger
• Tilgang til temaet tilpasser som du kan velge å bruke i stedet for temavalgsskjermer, som gir brukerne fordelene med å kunne se endringene når de lager dem, eller det kan være lurt å velge å bruke begge
• widget områder som vil tillate brukere å legge til sitt eget innhold på en rekke steder på siden
• menyer slik at brukerne kan navigere på nettstedet (du vil kanskje inkludere mer enn ett område for menyer)
• Barnemner støtter slik at brukerne kan installere for raskt å lage et arbeidssted
• biblioteker for alle funksjoner du vil inkludere som skyveknapper eller lysbokser
• dokumentasjon og støtte slik at brukerne vet hvordan du bruker arbeidet ditt (noe av dette er nyttig, men pass opp for å la det ta over tid)

Hvis målgruppen din er utviklere som skal bruke rammene dine sammen med egne barnemner og / eller plugins, må du kanskje vurdere noen av de ovennevnte, men du må også inkludere funksjoner fra følgende liste:

• handlingskroker som gjør det mulig for utviklere å sette inn sin egen kode i malfiler uten å lage en duplikatmalfil
• filter kroker slik at utviklere kan endre hva som er utført av malfiler
• tilpassede funksjoner som utviklere kan benytte seg av i deres barnemner
• maldeler og inkludere filer for å redusere kod duplisering. Dette er noe du vil dra nytte av selv når du jobber med rammen, og hvilke andre utviklere vil finne nyttige hvis teori trenger å lage malfiler i sine barnemner. Pass på at filene dine er logisk navngitt og strukturert, og legg til kommentarer til filene som de kalles for, slik at folk enkelt kan finne dem.

Offentlig eller privat?

Hvis du planlegger å frigjøre rammen til offentligheten, så vil det være et stort sett med flere hensyn:

• hvis du sender inn rammeverket ditt som et tema via WordPress-temaarkivet, må du følge retningslinjene for tema gjennomgang
• Siden brukerne skal bruke rammene dine for et hvilket som helst antall scenarier og nettstedtyper, må du teste at rammene fungerer som det skal i mange sammenhenger, og kanskje hjelp hjelp fra andre brukere og utviklere for å hjelpe du tester det
• noen form for dokumentasjon er viktig, enten for utviklere eller brukere avhengig av målgruppen din

WordPress-temaarkivet

Du må også vurdere hvordan du markedsfører rammene dine: Selv om det er gratis, vil du at folk skal bruke det, så du må publisere det via et nettsted, sosiale medier, SEO, tredjeparts temabutikker, muntlig, lokale møter, WordCamps og / eller andre metoder.

Hva bør temarammen inkludere?

En stor del av temaets funksjoner vil bli bestemt av behovene til brukerne du nettopp har identifisert. Etter å ha avgjort hvem temarammen er rettet mot, og om mulig spurte dem hva de trenger fra det, skriv opp en liste over funksjonene temaet ditt vil inneholde. 

Denne listen vil inneholde (men trenger ikke være begrenset til) et utvalg av følgende:

• malfiler (inkludert maldeler og inkludere filer)
• funksjoner
• action kroker og filter kroker
• widget områder
• menyer
• alternativer og innstillingsskjermbilder
• tema tilpasser støtte
• dokumentasjon
• barn temaer

For disse, identifiser:

• hva funksjonen er
• hva det vil gjøre
• hvor koden vil vises

I tillegg til funksjoner som er bestemt av behovene til ulike brukergrupper, kan du også inkludere andre funksjoner som:

• Vil rammene dine ha en innebygd layout, vil layoutet bli konfigurerbart eller vil det bli kodet via barnemner?
• Hvor mye av dette vil du inkludere i foreldre temaet ditt? Noen rammer har ekstremt minimal styling, mens andre (som min egen) er bygget ved hjelp av Objektorientert CSS (OOCSS) for å gjøre styling lettere i barnemner.
• Vil rammene dine være responsive, eller vil dette bli kodet via barnemner? Hvis foreldre temaet ditt er responsivt, må du forsikre deg om at dette ikke overskrives av noen layout styling i barnas temaer, noe som er et område hvor OOCSS kommer til nytte.
• Vil du legge til SEO-funksjoner i rammeverket ditt utover det som tilbys av WordPress, eller vil brukerne legge til dette via et frittstående plugin?
• Vil du inkludere ting som skyveknapper, gallerier, bakgrunnsbilder og mer i rammen din eller legge dem til med barnemner hvis de er påkrevd?

Denne listen kan godt vokse over tid etter hvert som dine behov og brukerne dine utvikler seg. Sørg for at rammene dine er enkle å forlenge fra begynnelsen, og du vil kunne legge til nye funksjoner når du trenger det.

Sammendrag

Å utvikle ditt eget tema rammeverk er en stor bedrift. Det er noe som vil spare deg for mange timer med utviklingstid på lang sikt, men som krever mye arbeid for å få det rette. 

Ved å ta deg tid til å identifisere hvem som skal bruke rammene dine og hvilke funksjoner de trenger, vil du gjøre det mer nyttig for deg selv og andre brukere, og du vil gjøre det lettere å utvide og tilpasse rammen i fremtiden.