Lag et pluginbudsjett: Slik holder bedriften WordPress ryddig og robust

Kategori: WordPress-forvaltning

En WordPress-side blir sjelden uoversiktlig på én dag. Problemene oppstår gradvis: Et skjema trenger et tillegg, markedsavdelingen ønsker et nytt analyseverktøy, og en kampanje krever en funksjon som må på plass raskt. Etter noen år kan virksomheten sitte med en samling utvidelser ingen har full oversikt over.

Et pluginbudsjett handler ikke først og fremst om å sette et maksimalt antall utvidelser. Det er en praktisk styringsmodell for hvilke funksjoner dere slipper inn, hva de koster å forvalte, og hvem som tar ansvar når de påvirker ytelse, sikkerhet eller redaksjonell arbeidsflyt.

Antallet alene sier lite

Ti godt vedlikeholdte utvidelser kan være enklere å håndtere enn tre omfattende tillegg som griper inn i hele nettstedet. Derfor bør dere ikke bruke antall plugins som eneste mål på kvalitet.

Det viktige er hvor stor teknisk og organisatorisk belastning hver utvidelse skaper. En enkel funksjon kan blant annet føre med seg:

• nye skript og stilark på mange sider
• egne tabeller og store mengder data i databasen
• avhengigheter til eksterne tjenester
• flere innstillinger redaktørene må forstå
• konflikter med tema, blokker eller andre utvidelser
• behov for samtykke, databehandleravtaler eller intern kontroll
• ekstra testing ved hver oppdatering

Pluginbudsjettet bør derfor måle konsekvenser, ikke bare telle installasjoner.

Start med et enkelt register

Før dere vurderer nye løsninger, må dere vite hva som allerede er installert. Lag et register over både aktive og inaktive utvidelser. Registeret trenger ikke være avansert, men det bør være tilgjengelig for dem som bestiller, utvikler og forvalter nettstedet.

Registrer minst følgende for hver utvidelse:

• hvilket forretningsbehov den dekker
• hvilke sider eller prosesser den påvirker
• hvem som er intern eier
• hvem som har teknisk ansvar
• om den lagrer eller sender personopplysninger
• hvilke eksterne tjenester den er avhengig av
• hvordan funksjonen skal testes etter oppdatering
• hva som skjer dersom utvidelsen fjernes

Formålet er ikke dokumentasjon for dokumentasjonens skyld. Registeret skal gjøre det mulig å svare raskt når en lisens utløper, en oppdatering skaper problemer eller en tjeneste skal erstattes.

Vurder behovet før løsningen

Bestillinger kommer ofte som ferdige løsningsforslag: «Vi trenger en plugin for dette.» Be heller bestilleren beskrive oppgaven, brukeren og ønsket resultat. Kanskje funksjonen allerede finnes i WordPress, i dagens tema eller i en eksisterende utvidelse.

Et ønske om en ny innholdsfortegnelse kan for eksempel løses med god overskriftsstruktur og en eksisterende blokk. Et nytt felt for kampanjetekst kan høre hjemme i en kontrollert sidemal. Et sporingsbehov kan kanskje dekkes gjennom verktøy dere allerede bruker.

Still fire spørsmål før dere installerer noe:

1. Hvilket konkret problem skal løses?
2. Kan behovet dekkes med eksisterende funksjonalitet?
3. Skal funksjonen brukes ofte og over lang tid?
4. Er nytten stor nok til å forsvare videre vedlikehold?

Det siste spørsmålet er viktig. En utvidelse installeres på minutter, men kan bli en forpliktelse i flere år.

Bruk Gutenberg som en kontrollert verktøykasse

Gutenberg reduserer behovet for enkelte sidebygger- og innholdsutvidelser, men kan også åpne for unødvendig mange blokker og valgmuligheter. Hvis hvert tillegg legger til en hel blokkpakke, får redaktørene raskt flere varianter av knapper, kolonner, faner og bildeoppsett.

Resultatet kan bli ujevn design, svakere universell utforming og sider som er vanskelige å overta for andre redaktører. Et pluginbudsjett bør derfor også omfatte blokkene som følger med.

Definer hvilke blokker virksomheten faktisk trenger. Skjul blokker som ikke skal brukes, og lag mønstre for vanlige innholdsseksjoner. Dersom en viktig funksjon brukes mange steder, kan en enkel, spesialtilpasset blokk være lettere å forvalte enn en stor samling med funksjoner dere aldri tar i bruk.

Målet er ikke å fjerne redaktørens frihet. Målet er å gjøre riktige valg enkle og feil bruk mindre sannsynlig.

Gi hver ny utvidelse en kostnadsvurdering

Lag en fast vurdering som brukes før godkjenning. Den kan være enkel, for eksempel lav, middels eller høy belastning innen fem områder:

• Forretningsverdi: Hvor viktig er funksjonen for kunder, ansatte eller inntekter?
• Ytelse: Legger den til kode, forespørsler eller databasearbeid på mange sider?
• Vedlikehold: Hvor mye testing, lisenshåndtering og oppfølging kreves?
• Risiko: Behandler den data eller får den omfattende tilgang i WordPress?
• Binding: Hvor krevende blir det å bytte løsning senere?

En utvidelse med høy forretningsverdi kan være riktig selv om den krever mye oppfølging. Poenget er at kostnaden blir synlig og akseptert før funksjonen tas i bruk.

Test påvirkningen på riktige sider

Ytelsestesting bør skje før og etter installasjon, men ikke bare på forsiden. Test sidetypene der utvidelsen faktisk brukes, og kontroller også om den påvirker sider der funksjonen ikke er synlig.

Se blant annet etter ekstra skript, stilark, eksterne kall og endringer i lastetid. Kontroller sentrale brukeroppgaver som innsending av skjema, søk, innlogging og kjøp dersom nettstedet har nettbutikk.

En vanlig svakhet er at en utvidelse laster ressursene sine på hele nettstedet, selv om funksjonen bare brukes på én landingsside. Da bør dere undersøke om ressursene kan avgrenses. Hvis ikke, må ytelseskostnaden inngå i beslutningen.

Installer aldri direkte som første test

Nye utvidelser bør prøves i et separat testmiljø. Der kan dere kontrollere oppsett, datalagring, redaktøropplevelse og kompatibilitet uten å påvirke besøkende.

En trygg innføringsflyt kan se slik ut:

1. Beskriv behov og forventet effekt.
2. Sjekk om eksisterende funksjoner dekker behovet.
3. Vurder vedlikehold, data, binding og ytelse.
4. Installer og konfigurer i testmiljøet.
5. Test berørte sidemaler og brukeroppgaver.
6. Dokumenter eier, lisens og plan for avvikling.
7. Godkjenn og publiser i en planlagt endring.

For større funksjoner bør dere også ha en plan for å gå tilbake dersom noe svikter. Det kan innebære sikkerhetskopi, eksport av innstillinger eller en beskrivelse av hvordan funksjonen deaktiveres uten at innhold går tapt.

Rydd etter en fast kalender

Plugins bør gjennomgås regelmessig, ikke bare når noe slutter å virke. En halvårlig gjennomgang passer for mange bedriftsnettsteder, mens løsninger med hyppige endringer kan trenge kortere intervaller.

Gå gjennom registeret sammen med relevante eiere og spør:

• Brukes funksjonen fortsatt?
• Finnes det overlapp med andre løsninger?
• Er lisensen og ansvaret fortsatt avklart?
• Har utvidelsen skapt problemer ved oppdateringer?
• Kan data eller innhold eksporteres ved et senere bytte?
• Bør funksjonen bygges inn i en mer kontrollert løsning?

Inaktive utvidelser bør som hovedregel fjernes når dere har kontrollert at de ikke lenger trengs. De bidrar ikke med funksjonalitet, men må fortsatt inngå i oversikt og risikovurdering så lenge de ligger installert.

Sett grenser for hasteinstallasjoner

Kampanjer og korte frister er vanlige årsaker til at pluginbudsjettet sprekker. Et midlertidig behov blir fort permanent fordi ingen rydder etter lansering.

Hvis en hasteinstallasjon er nødvendig, bør den få en utløpsdato og en navngitt eier. Avtal allerede ved installasjon når løsningen skal vurderes, fjernes eller gjøres permanent. Da unngår dere at nettstedet fylles med gamle konkurranser, skjemaer og sporingsverktøy ingen lenger kjenner bakgrunnen for.

Et budsjett gir bedre beslutninger, ikke bare færre plugins

Et godt pluginbudsjett kan fortsatt ende med at dere installerer en ny utvidelse. Forskjellen er at beslutningen bygger på et dokumentert behov, en kjent kostnad og et tydelig ansvar.

Begynn med registeret, innfør en enkel vurdering før installasjon, og rydd etter en fast kalender. Kombinert med en kontrollert Gutenberg-verktøykasse gir dette et WordPress-nettsted som er enklere å oppdatere, raskere å feilsøke og tryggere å videreutvikle.