Share
For mange år siden pleide jeg å skrive tekniske håndbøker for klienter. Disse vil vanligvis ta form av papirdokumenter, med hundrevis av sider med teknisk informasjon trykt av og sannsynligvis brukt som et praktisk sted å hvile en kaffekrus av de fleste av menneskene de ble produsert for. Hvis klienten var eksepsjonelt avansert, kan det ha vært en PDF-versjon, men det ble sjelden brukt.
Tider har gått på, og de fleste håndbøker, eller kunnskapsbaser som de ofte er kjent, er i digital form. De kan ta formen av en app eller et nettsted, eller en slags simulering, men de vil alltid ha data i kjernen. Kunnskapsbaser må være enkle for brukere å søke og navigere rundt, og de må være enkle for forfattere å legge til innhold til eller redigere innhold uten å måtte jobbe på noe data mer enn en gang.
Dette er grunnen til at ethvert system som drives av en database, vil være den mest hensiktsmessige. Jeg har brukt WordPress til å kjøre denne typen intern nettside for en stund nå, og jeg finner fleksibiliteten WordPress gir deg over hvordan du viser og spørrer data, kombinert med admingrensesnittet som er kjent for mange mennesker, gjør det til et ideelt verktøy.
I denne serien vil jeg vise deg hvordan du bygger en kunnskapsbase ved hjelp av WordPress. Jeg tar deg gjennom følgende trinn:
Den første delen av dette planlegger, som jeg vil dekke her. Gjennom denne serien skal jeg jobbe på en imaginær kunnskapsbase, og jeg vil gi noen kode slik at du kan bruke den selv.
Det første trinnet er å identifisere hvilke typer innhold din kunnskapsbase vil inneholde. Min kunnskapsbase kommer til å være en ressurs for WordPress-brukere og utviklere.
Det vil inneholde følgende typer innhold:
Dette innholdet blir deretter sortert i henhold til målgruppen og temaene på høyt nivå. Det vil også benytte tagger for mer detaljert sortering.
Mitt publikum er delt inn i to grupper:
For utviklere er emner på høyt nivå:
For brukere er emner på høyt nivå:
Som allerede nevnt vil nettstedet også bruke tagger som vil bli lagt til av bidragsytere. Disse vil ikke være spesifikke for brukere eller utviklere.
Nettstedet vil bli administrert av et imaginært team av WordPress-eksperter som er opptatt med annet arbeid, så det må kunne legges til innhold raskt. Noen av dem bruker WordPress mobilappen for å legge til innhold.
Etter å ha identifisert hva innholdet mitt må være, må jeg matche det til WordPress-innholdstyper.
Som med så mange aspekter ved å utvikle med WordPress, er det ikke nødvendigvis bare en måte å matche innholdet ditt på som WordPress er organisert. For å identifisere den mest hensiktsmessige for deg, må du begynne med å forstå hvordan WordPress organiserer innhold.
Ut av boksen kommer WordPress med tre innholdstyper:
Vær oppmerksom på at det finnes andre innholdstyper i WordPress, for eksempel koblinger, kommentarer og navigasjonsmenyelementer, men de tre ovenfor er de som er mest relevante her.
Du kan også legge til dine egne innholdstyper, og skape så mange som du trenger, ved hjelp av egendefinerte innleggstyper. Disse kan oppføre seg som innlegg eller sider, hovedforskjellen er at sidene er hierarkiske og innlegg ikke er. I dette tilfellet er hierarkiet ikke et problem for mine hovedinnholdstyper.
WordPress har to taksonomier innebygd, som du kan bruke med innlegg, sider og egendefinerte innleggstyper:
I tillegg kan du registrere ekstra taksonomier for å muliggjøre bedre sortering og spørring av dataene dine.
Hvis kunnskapsbasen din har flere innholdstyper, kan du håndtere dette på en av tre måter:
Det første alternativet er det enkleste for nybegynnere, siden du ikke trenger å skrive noen egendefinert kode og kan arbeide med WordPress som det kommer. Det andre alternativet gir deg mer fleksibilitet og er en effektiv tilnærming hvis du vil liste opp alle innholdstyper sammen, i stedet for å splitte dem opp. Det er også nyttig hvis et innhold kan komme under mer enn én innholdstype. Det tredje alternativet gir deg størst fleksibilitet så lenge innholdstypene dine alltid vil være separate.
Når det gjelder kunnskapsbasen min, kan noe av innholdet mitt være mer enn en innholdstype (for eksempel kan et raskt tips være i form av en video eller inkludere en lenke), så jeg skal ikke registrere forskjellige posttyper . I stedet lager jeg en tilpasset taksonomi for innholdstypene mine.
I tillegg til innholdstyper, må jeg tenke på hvordan dataene mine er kategorisert. Hvert innlegg vil være i ett eller flere emner med ett eller flere publikum. Som temaene er tydelig tilpasset de to målgruppene, skal jeg registrere to taksonomier: en for brukeremner og en for utvikleremner. Dette betyr at jeg kan liste emnene for hvert publikum på de relevante sidene på nettstedet.
Dette betyr at min kunnskapsbase vil bruke følgende:
Så jeg må registrere disse tre taksonomiene, men trenger ikke å registrere noen innleggstyper. I tillegg, siden jeg ikke vil bruke innebygde kategorier, skal jeg slå dem av slik at forfatterne mine ikke tilfeldigvis tilordner elementer til kategorier.
Nå som jeg vet hvilket innhold min kunnskapsbase vil inkludere og hvordan dataene blir lagret, må jeg tenke på strukturen på kunnskapsbasens sider. Nettstedet vil bruke en kombinasjon av arkiver og statiske sider, med en startside, inkludert de siste innleggene fra alle emner.
Jeg må også tenke på navigasjonen min - i tillegg til navigering i menyen, jeg skal inkludere emnenavigering i sidefeltet, og også en søkeboks.
Så, min side vil inkludere:
Jeg vil inkludere et sidebar og en bunntekst på alle sidene på nettstedet mitt, men jeg skal variere det litt i henhold til hvilket område av nettstedet brukeren er i.
Her er hva som vil være i sidefeltet:
Alt dette høres litt komplisert, men det begynner å gi mening når vi begynner å bygge den. Jeg lager hver av disse elementene med en funksjon, og deretter bruker du betingede tagger for å feste funksjonene til en handlingskrog som jeg legger til i sidefeltet. Jeg vil også legge til et widgetområde til sidelinjen, bare i tilfelle.
Footer vil inneholde lister over taksonomi vilkårene for alle tre av mine emner pluss en liste over de siste innleggene.
Dette betyr at jeg trenger følgende malfiler:
Accentsconagua
index.phppage.phparchive.phpsingle.phpsidebar.phpJeg legger til en handlingskrok, som vil hjelpe meg å fylle sidebjørene: a tutsplus_sidebar Handling krok inn sidebar.php.
Jeg lager en funksjon knyttet til denne kroken, som vil inneholde følgende lister:
Hver av disse vil inneholde betingede koder, slik at de legges til sidelinjen på høyre side.
Jeg har nå en plan for innholdet og strukturen til min kunnskapsbase, og jeg har matchet det til WordPress-evner. Så jeg har identifisert nøyaktig hva jeg trenger å opprette i WordPress for å gjøre dette kunnskapsbasen arbeidet.
Selv om det er fristende å dykke inn og starte koding, er det en god ide å bruke litt tid på å planlegge kunnskapsbasen på denne måten, slik at du vet nøyaktig hvilke malfiler og funksjoner du trenger. På den måten når du kommer til å skrive koden, blir det mye raskere.
I neste del av denne serien vil jeg vise deg hvordan du registrerer posttyper og taksonomier for din kunnskapsdatas data og fjern alt du ikke trenger.
