Blokk, mønster, tema eller plugin? Plasser WordPress-endringen riktig

Kategori: WordPress

En ny kalkulator skal inn på nettstedet. Markedsavdelingen ønsker en kampanjeboks som kan gjenbrukes. Kontaktinformasjonen må oppdateres flere steder. En redaktør vil kunne endre bakgrunnsfargen på én bestemt seksjon.

Alle behovene kan løses i WordPress, men de bør ikke løses på samme måte. Valget mellom vanlig innhold, et Gutenberg-mønster, en egen blokk, temaet eller en plugin påvirker hvor enkelt nettstedet blir å redigere, videreutvikle og vedlikeholde.

Legges funksjonalitet på feil sted, oppstår gjerne skjulte avhengigheter. Innhold blir låst til utseendet, redaktører får for mange valg, og et senere temabytte blir unødvendig komplisert. Derfor bør bedriften ha noen faste prinsipper for hvor ulike typer endringer hører hjemme.

Start med å skille innhold, presentasjon og funksjon

Før dere velger teknisk løsning, bør behovet plasseres i én av tre hovedkategorier:

• Innhold: Tekst, bilder, video, tabeller og annen informasjon redaktøren skal forvalte.
• Presentasjon: Typografi, farger, avstander, bredder og visuelle regler som bestemmer hvordan innholdet vises.
• Funksjon: Beregninger, skjemaer, integrasjoner, søk, filtrering og annen programlogikk.

Dette skillet virker enkelt, men løser mange diskusjoner. En ingress er innhold. Hvordan ingresser ser ut, er presentasjon. Et skjema som sender data til et kundesystem, er funksjon.

Problemer oppstår når kategoriene blandes. Dersom en redaktør må skrive HTML for å få riktig design, er presentasjonen lagt inn i innholdet. Dersom en viktig integrasjon ligger i temaet, er funksjonen gjort avhengig av nettstedets visuelle drakt.

Bruk vanlige Gutenberg-blokker til vanlig innhold

Standardblokker bør være førstevalget når redaktøren skal publisere vanlig innhold. Overskrifter, avsnitt, lister, bilder, sitater, knapper og kolonner dekker mange behov uten spesialutvikling.

Fordelen er ikke bare lavere kostnad. Standardblokker er kjent for mange redaktører, fungerer godt med WordPress-redigeringen og gir mindre egen kode å vedlikeholde. Det er sjelden nødvendig å bygge en spesialblokk bare for å få en overskrift og en knapp til å stå ved siden av hverandre.

Samtidig bør ikke alle tilgjengelige blokker være åpne for alle. Hvis nettstedet har tydelige maler og designregler, kan et begrenset utvalg gjøre publiseringen enklere. Redaktøren trenger relevante valg, ikke flest mulig valg.

Velg mønster når flere blokker skal brukes sammen

Et Gutenberg-mønster passer når bedriften gjentatte ganger bruker den samme kombinasjonen av blokker. Det kan være en kundehistorie med bilde, sitat og resultatpunkter, eller en kontaktseksjon med overskrift, tekst og handlingsknapp.

Mønsteret gir redaktøren et godt utgangspunkt uten at innholdet må bygges fra bunnen hver gang. Etter innsetting kan teksten og bildene normalt redigeres som vanlig innhold.

Et mønster er særlig nyttig når behovet handler om struktur og komposisjon, ikke avansert funksjonalitet. Hvis seksjonen bare består av eksisterende blokker satt sammen på en bestemt måte, bør dere vurdere mønster før dere bestiller en egen blokk.

Bedriften bør også avklare om mønsteret skal være fritt redigerbart eller synkronisert. En fritt redigerbar variant passer når hver side skal ha eget innhold. En synkronisert variant passer når den samme informasjonen skal vises og oppdateres samlet flere steder, for eksempel en felles servicemelding.

Bygg en egen blokk når innholdet trenger faste rammer

En spesialutviklet blokk er riktig når redaktøren trenger et tydelig redigeringsskjema, faste felt eller kontrollert presentasjon. Det kan være en ansattprofil, en produktfordel, en priskomponent eller et nøkkeltall med forklaring.

Forskjellen fra et mønster er graden av styring. I et mønster arbeider redaktøren med flere selvstendige blokker. I en egen blokk fyller redaktøren ut definerte felt, mens løsningen styrer oppsett og visning.

En god spesialblokk skal gjøre redaktørens arbeid enklere. Hvis blokken inneholder mange faner, tekniske valg og fritekstfelt for design, er den sannsynligvis for komplisert. Redaktøren bør ta stilling til innholdet, ikke implementasjonen.

Før dere bygger blokken, bør dere svare på tre spørsmål:

1. Skal elementet brukes flere steder eller av flere redaktører?
2. Er det viktig at oppsettet alltid følger samme struktur?
3. Kan behovet løses tilfredsstillende med eksisterende blokker og et mønster?

Hvis svaret på de to første er ja og det siste er nei, er en egen blokk ofte fornuftig.

La temaet styre nettstedets visuelle regler

Temaet bør ha ansvar for det gjennomgående uttrykket: typografi, fargepalett, avstander, innholdsbredder og presentasjon av sentrale elementer. Det skal sørge for at en knapp, overskrift eller liste oppfører seg konsistent på tvers av nettstedet.

Dette betyr ikke at all styling må være identisk. Men variasjonene bør være planlagte. Hvis redaktører kan velge vilkårlige farger, skriftstørrelser og marger for hver blokk, blir nettstedet raskt ujevnt. Fleksibilitet bør gis gjennom et avgrenset sett med varianter som er testet i designet.

Temaet bør derimot ikke eie forretningskritisk funksjonalitet. En produktkalkulator, integrasjon eller egendefinert innholdstype bør normalt kunne overleve at bedriften endrer design. Ellers blir et fremtidig temabytte også et funksjonsprosjekt.

Bruk plugin til funksjonalitet som skal leve uavhengig av designet

En plugin er vanligvis riktig sted for funksjoner som behandler data, kobler systemer sammen eller introduserer varig forretningslogikk. Det gjelder blant annet skjemaer, søkefunksjoner, produktdata, kalkulatorer og integrasjoner.

Det sentrale spørsmålet er om funksjonen fortsatt skal finnes etter et temabytte. Hvis svaret er ja, bør den ikke være bundet til temaet.

Det betyr ikke at bedriften trenger en ny plugin for hver lille endring. Beslektet, egenutviklet funksjonalitet kan samles på en ryddig måte. Målet er tydelig ansvar, ikke flest mulig tekniske komponenter.

Vurder også om funksjonen allerede dekkes av en etablert løsning dere bruker. Dobbelt funksjonssett gir mer vedlikehold, flere innstillinger og større risiko for konflikter. En ny plugin bør løse et reelt behov som ikke håndteres godt nok i dagens oppsett.

Unngå kortkoder som langsiktig innholdsstrategi

Kortkoder kan være praktiske i enkelte tilfeller, men de gjør ofte innholdet vanskeligere å forstå og redigere. Redaktøren ser en kode i stedet for en visuell representasjon, og innholdet kan sitte igjen med ubrukelige tekstbiter dersom løsningen fjernes.

For nye redaksjonelle komponenter er en blokk som regel bedre. Den kan gi forhåndsvisning, tydelige felt og validering direkte i redigeringsflaten. Eksisterende kortkoder trenger ikke nødvendigvis bygges om umiddelbart, men de bør registreres som teknisk gjeld og vurderes når aktuelle sider likevel skal endres.

Vurder konsekvensene før utviklingen starter

En liten bestilling kan påvirke mer enn den aktuelle siden. Før en endring blir utviklet, bør ansvarlig person gå gjennom en kort konsekvensvurdering:

• Hvem skal opprette og redigere innholdet?
• Hvor mange steder skal løsningen brukes?
• Skal innholdet være likt eller forskjellig mellom sidene?
• Hva skal skje dersom temaet byttes?
• Inneholder løsningen data som må kunne flyttes eller eksporteres?
• Hvordan påvirkes mobilvisning, tilgjengelighet og lastetid?
• Hvem skal teste og godkjenne endringen?

Denne gjennomgangen avdekker ofte at bestillingen bør justeres. En ønsket spesialblokk kan vise seg å være et mønster. En visuell komponent kan i realiteten være en integrasjon. En engangsløsning kan vise seg å være starten på en ny innholdstype.

Dokumenter valget, ikke bare løsningen

Når nettstedet utvikles over tid, er det nyttig å vite hvorfor en komponent ble laget som blokk, mønster eller plugin. Legg derfor inn en kort beslutning i prosjektets dokumentasjon. Beskriv behovet, valgt plassering, hvem som eier innholdet, og eventuelle avhengigheter.

Dokumentasjonen trenger ikke være omfattende. Et par presise avsnitt kan spare mye tid når løsningen skal endres senere. Den gjør det også enklere for en ny utvikler eller leverandør å forstå arkitekturen uten å måtte tolke alle tidligere valg på nytt.

Innfør en enkel beslutningsregel

Bedriften kan bruke følgende rekkefølge hver gang et nytt behov kommer inn:

1. Kan behovet løses med en vanlig blokk?
2. Kan flere eksisterende blokker settes sammen som et mønster?
3. Trenger redaktøren en spesialblokk med faste felt og rammer?
4. Er dette en visuell regel som hører hjemme i temaet?
5. Er dette varig funksjonalitet som bør ligge i en plugin?

Rekkefølgen hjelper dere med å velge den enkleste løsningen som faktisk dekker behovet. Målet er ikke å unngå spesialutvikling, men å bruke den der den gir tydelig verdi.

Riktig plassering gir et mer håndterbart nettsted

Et ryddig WordPress-nettsted kjennetegnes ikke av hvor mange blokker eller plugins det har, men av at hver del har et forståelig ansvar. Innhold skal kunne redigeres uten kode. Designet skal være konsistent uten manuell finjustering på hver side. Funksjonalitet skal kunne vedlikeholdes uten å være unødvendig bundet til utseendet.

Når bedriften vurderer plasseringen før løsningen bygges, blir både publisering og videreutvikling enklere. Redaktørene får færre feilvalg, utviklerne møter tydeligere grenser, og nettstedet tåler endringer bedre over tid.