Skrive dokumentasjon for WordPress Theme Framework

Så, du har nå et WordPress-tema rammeverk. Gratulerer! Det harde arbeidet du har satset på å utvikle det, vil lønne seg i det lange løp og gjøre utviklingsprosessen jevn, mer strømlinjeformet og mer effektiv.

Men du må gjøre en siste ting før du er ferdig, og det er å dokumentere rammen din. I det minste må du sikre at god kommentar blir brukt i hele koden din, men det er også nyttig å skrive annen dokumentasjon, slik at du kan holde styr på filene, funksjonene og filtre som utgjør rammens API.

Alternativene jeg vil dekke er:

  • kommenterer
  • Opprette en readme-fil
  • Bruke automatiserte dokumentasjonsverktøy
  • Opprette en wiki
  • Opprette et nettsted
  • Opprette opplæring eller innspilling av videoer

Vær oppmerksom på at mens jeg skal nevne noen dokumentasjonsverktøy, fungerer denne veiledningen ikke som en anbefaling som jeg ikke har brukt dem til mitt eget rammeverk, så du må selv avgjøre om deres egnethet.

Skrive kvalitetskommentarer

Kommentarer er spesielt viktige når andre utviklere vil jobbe med koden din (for eksempel hvis du er en del av et lag, eller hvis du vil frigjøre rammen din). Men de er også uvurderlige hvis du jobber alene, da det er veldig lett å glemme nøyaktig hva et stykke kode gjør når du kommer til å redigere det et år eller mer nedover linjen.

Tenk deg at du har brukt rammen din til å bygge et kundeside. To år fra nå utvikler området et problem klokken 5:30 på fredag ​​ettermiddag. Gode ​​kommentarer kan gjøre forskjellen mellom å fikse problemene raskt og være hjemme for helgen, versus slogging gjennom hundrevis av kodelinjer og mangler fredagskvelden ut.

Her er noen tips for gode kommentarer:

  • Bruk kommentarer i begynnelsen av filen din for å forklare hva filen gjør. For eksempel inkluderer i malfiler et notat om hvilke data den viser og eventuelle tilpasninger du har gjort til sløyfen eller andre deler av filen; og i plugin-filer legger du til et notat om funksjonaliteten. For eksempel. kommentaren nedenfor forteller brukerne navnet på malfilen, hva det gjør, temaet det er en del av (@pakke), og hvilken versjon av temaet det har vært på plass siden (@siden). Du bør bruke et lignende system for pluginfiler.
/ ** * Malnavn: sidebar-products.php * * Inkluder filen som brukes til sidebjelken på sider ved hjelp av single-product.php-mal. Viser et galleri av produktbilder (unnlat det uthevede bildet som vises i innholdet). * * @package wpptl-tema-rammeverk * ​​@since versjon 1.0 * /
  • Bruk kommentarer til å avgrense delene av koden din, ikke bare i stylesheets, men også i tema malfiler og funksjonsfil.
  • Kommenter noe som ikke er standard.
  • Kommenter noe som tok deg en stund å trene - bruk detaljert kommentarer, så når du kommer tilbake til det, trenger du ikke å tenke det igjen.
  • Kommenter noe om at du vet at noen andre vil jobbe med - for eksempel hvis temafilene dine inneholder skript som du vil spørre en annen utvikler for å perfeksjonere, legger du til kommentarer som forklarer hvor de gjelder på nettstedet.
  • Bruk ordlyd i kommentarene dine som du kan finne ved hjelp av et søk senere - så forkort ikke, og bruk vilkår som andre ville forstå.
  • Når du kommenterer noe kode, legg til en kommentar for deg selv som inneholder årsaken. På den måten, hvis du glemmer å fjerne koden etter at du er ferdig, eller vil legge den til igjen i fremtiden, vet du hva som skjer.
  • Når du er i tvil, legg til en kommentar!

Opprette en readme-fil

EN readme.txt filen er neste nivå opp etter å kommentere. Det er en enkelt fil som du inkluderer i temaet ditt, og inneholder informasjon om temaet.

Kodepakken som følger med denne serien inkluderer en enkel readme.txt fil:

Opprette ditt eget WordPress-temaramme Dette temaet støtter den seksdelte delen av denne serien for wptutsplus. Temaet inneholder følgende malfiler: archive.php index.php page.php - for statiske sider side-full-width.php archive.php - for arkivsidene header.php sidebar.php footer.php loop.php loop-single .php loop-page.php functions.php Temaet støtter utvalgte bilder, menyer og widgets og bruker dem som følger: Utvalgte bilder: Disse vises i arkiv- og indeksmalene hvis de er til stede, ved hjelp av mellomstørrelsen. Menyer: Standardmenyen er i header.php, og bruker menyadministrator Styling Temaet bruker Object Oriented CSS (OOCSS). Følgende klaser er for layout, og du kan bruke dem på sidene og innleggene dine. De er lydhør, så størrelsen blir mindre på mindre skjermer (for eksempel .half-klassen er full bredde på telefoner) .full bredde. Tre kvartaler. Tre tredjedeler. Halvfjerdedel. Kvadratkroker Det er 7 handlekroker: Over overskrift Inne i toppteksten Før innholdet Etter innholdet i sidefeltet I fotfeltet Etter fotfeltet Det er tre filterhooks: 1 i topptekst 2 i fotfeltet Widgetområder Det er seks widgetområder, alle lagt til via widgets.php-filen: - en i toppteksten - en i sidebjelken - fire i bunnteksten

Hvis du vil lage din readme filen mer brukervennlig, kan du vurdere å lage en readme.html filen i stedet som vil åpne i en brukers nettleser. Du kan bruke CSS til å merke din readme fil og gjør det enklere å lese.

Hvis du vil frigjøre temaet ditt for offentligheten via WordPress-temaarkivet, forventes det å gi en readme.txt filen som en minimumsform for dokumentasjon. Jeg vil dekke dette mer detaljert i den endelige opplæringen i denne serien, når du slipper temarammen.

Bruke automatiserte dokumentasjonsverktøy

Hvis du planlegger å fortsette å utvikle rammen og ikke vil bruke mye tid manuelt, skriv dokumentasjon for hver ny funksjon, kan et automatisk dokumentasjonsverktøy være svaret.

De fleste av disse innebærer at du bruker bestemte koder eller syntaks for å gjøre det mulig for systemet å identifisere hvor du skal generere dokumentasjon. Eksempler er:

  • PHPDocumentor som er PHP-spesifikk
  • APIgen også PHP spesifikk
  • Doxygen
  • Groc

Hvis du skal bruke ett av disse verktøyene, er det verdt å bruke litt tid på å identifisere det beste for deg før du begynner, da du ikke kan overføre dokumentasjonen fra en til en annen. 

Men når du har fått tak i systemet og fått det opprettet, kan et automatisert verktøy som disse spare deg mye tid og kan unngå hull i dokumentasjonen din nedover linjen, da du vil være så opptatt med å skrive kode du har ikke tid til å oppdatere dokumentene dine.

Opprette en Wiki eller et nettsted

Dette alternativet vil bli mer arbeid og er bare verdt å gjøre hvis du ser rammen din vokser over tid og får en betydelig brukerbase. Alle de store temarammene har egne nettsider med dokumentasjon, som enten er fritt tilgjengelige eller bare tilgjengelig for medlemmer.

Nettstedet for å støtte rammene dine kan utgjøre en del av inntektsstrategien din - det er for eksempel gratis hybridrammekonfigurasjon, men dokumentasjonen og støtten på den tilhørende nettsiden er kun tilgjengelig for betalende abonnenter.

Alternativt hvis du slipper rammen ditt som et premiumprodukt, kan du kreve at abonnenter logger på docs, eller du kan velge å gjøre dokumentasjonen din offentlig i håp om at det vil oppmuntre flere personer til å kjøpe.

Hvis rammene dine er helt gratis, kan du velge å lage et gratis nettsted med dokumentasjon, slik det er tilfelle med Wonderflux-rammeverket:

Alternativt kan du bestemme deg for å lage en wiki, som har fordelen av å la brukerne bidra til dokumentene. Dette vil ta mer tid å sette opp enn et nettsted i de fleste tilfeller, men kan være et verdifullt verktøy for samfunnet som bruker rammene dine. Du kan opprette en wiki ved hjelp av et plugin for rammens WordPress-nettsted.

Opprette opplæring eller innspilling av videoer

Tutorials kan hjelpe nye brukere, spesielt de som ikke kan skrive kode, få tak i rammen din raskere enn standard dokumentasjon. Videoer tar dette et skritt videre, og gir en enkel å bruke visuell veiledning og et godt markedsføringsverktøy.

Genesis-rammeverket har en rekke opplæringsprogrammer for brukere som kun er tilgjengelige for betalte abonnenter:

Mitt eget Edupress-rammeverk har en rekke opplæringsvideoer som jeg opprettet for å hjelpe brukere med en varierende grad av datamaskinopplevelse og lite erfaring med å bruke WordPress:

Disse vises på det offentlige nettstedet og også i brukerens instrumentpaneler, slik at de lett kan få tilgang til dem mens de arbeider med rammen. Hvis du oppretter dokumentasjon, opplæringsprogrammer eller videoer for rammen din, kan du inkludere en skjerm i oversikten med detaljer om dokumentene dine.

Å lage opplæringsprogrammer eller videoer er imidlertid svært tidkrevende og trenger mye arbeid for å få det rette: dårlig skrevet opplæringsprogrammer eller dårlig produserte videoer vil reflektere dårlig på rammen din og kan gjøre deg mer skade enn en enklere form for dokumentasjon. 

Sammendrag

Den som skal bruke tema-rammeverket, er en slags dokumentasjon viktig. Enten du bare utvikler rammen for deg og teamet ditt, eller slipper det for bredere bruk, må du registrere informasjon om filstruktur og API.

Alternativene jeg har diskutert ovenfor spenner fra de enkle kommentarene til de mer komplekse videoene, med alt i mellom. Det du bestemmer deg for å gjøre, vil avhenge av dine brukeres behov, og det kan godt endres over tid da du får en større brukerbase.