Kort svar: En standardopsætning er et klonbart skabelon-site: ÉT tema, I kender til bunds, én plugin-stak med præcis ét værktøj pr. opgave, faste konfigurationer (roller, permalinks, sprog, sikkerhed) og jeres dokumentation indbygget. Nye projekter starter som en klon – aldrig fra en tom WordPress – og basen revideres hvert kvartal med changelog. Gevinsten er dobbelt: timer sparet pr. projekt, og en portefølje, hvor ALLE sites fejlfinder ens, fordi de er bygget ens.
Bureauets dødsspiral hedder „hvert site sit eget lille kunstværk“: 30 sites med 30 temaer, 30 plugin-kombinationer og 30 måder at gå i stykker på. Modtrækket er en standardopsætning – bilfabrikkens platform-tænkning overført til WordPress: samme bund under alle, forskellen ligger i karosseriet. Her er, hvad basen skal indeholde, og hvordan du holder den i live.
Standardisering handler mindre om opstartstiden (selv om 3-5 sparede timer pr. projekt er rare) og mere om ALT det efterfølgende: driften skalerer, fordi én opdateringsrutine passer alle sites; fejlfinding går hurtigt, fordi alle sites fejler på samme genkendelige måder; nye medarbejdere er produktive på dage, fordi der kun er ÉN måde at bygge på; og dine SLA-løfter bliver billige at holde, fordi risikoen er ens overalt. Hver afvigelse fra basen er til gengæld en livsvarig ekstraomkostning – så afvigelser skal VÆLGES (kunden har et reelt særbehov), aldrig bare SKE, fordi en udvikler havde lyst til at prøve noget nyt.
Temaet: ét, som hele teamet kender til bunds – valgt på vedligeholdelseshistorik og performance, ikke på demo-sitets udseende. Plugin-stakken: ét værktøj pr. opgave (SEO, formularer, sikkerhed, billedoptimering …), hver med en linje om HVORFOR netop det – og lige så vigtigt: en liste over bevidste FRAVALG, så diskussionerne ikke starter forfra hvert kvartal. Cache og backup hører som udgangspunkt til i hostinglaget, ikke i plugin-listen. Konfigurationen: permalinks, sprog/tidszone, roller efter mindste privilegium, kommentarindstillinger, billedstørrelser og de ti små indstillinger, ingen kan huske, men alle glemmer. Dokumentationen: en „om dette site“-side i wp-admin, der fødes med i klonen.
Tjeklisten er første skridt – men mennesket, der følger den, springer punkt 14 over en travl torsdag. Målet er derfor et BLUEPRINT: et færdigt skabelon-site, der klones som start på hvert projekt. På Hostious’ bureau-hosting kan du holde et skabelon-site kørende og klone det til nye kundemiljøer på minutter – alternativt vedligeholder du blueprintet som eksport/provisioneringsscript. Byg to varianter: „site“ og „shop“ (WooCommerce-laget oveni), og modstå fristelsen til flere – to blueprints kan holdes i live, seks kan ikke. Klonen går derefter gennem jeres normale ændringsproces som ethvert andet stykke arbejde.
En standardopsætning, ingen vedligeholder, er bare gammel praksis med selvtillid. Sæt en kvartalsvis revision i kalenderen: er alle valg stadig de rigtige (opdateres pluginet stadig? er der kommet noget bedre?), hvad har projekterne lært os, og hvad skal ind/ud? Før en kort changelog („Q3: skiftede formular-plugin pga. licensændring“) – den er guld, når du om to år står på et site fra dengang og skal forstå fortidens valg, og den hører naturligt hjemme i jeres værktøjskasse-dokumentation. Ændringer i basen gælder som udgangspunkt kun NYE sites; rul kun ændringer bagud, når sikkerhed eller licenser kræver det – så undgår du at forstyrre 30 stabile sites for at tilfredsstille én ny idé.
Du behøver ikke en projektuge for at komme i gang: byg basen af det NÆSTE projekt. Tag det kommende kundesite, dokumentér hvert valg undervejs (tema, plugins, indstillinger – og hvorfor), og gem resultatet som første udgave af blueprintet, FØR kundens indhold lægges på. Næste projekt starter så fra klonen og gør den lidt bedre – efter tre-fire projekter har du en gennemprøvet base, der aldrig kostede et internt projekt. Undervejs vil du opdage uenigheder i teamet („jeg plejer nu at bruge …“) – tag dem ÉN gang, skriv afgørelsen ned, og lad changeloggen være dommer fremover. Det er hele pointen: diskussionerne flytter fra hvert projekt til ét kvartalsmøde, og hverdagen bliver bare at bygge.
Ét gennemprøvet tema, én plugin-stak med ét værktøj pr. opgave (inkl. dokumenterede fravalg), faste konfigurationer for roller, permalinks og sikkerhed – og indbygget dokumentation.
Ja – en klon kan ikke springe punkt 14 over. Tjeklisten beskriver basen; blueprintet ER basen. Hold højst to varianter (site og shop), så de kan vedligeholdes.
Som udgangspunkt nej – kun når sikkerhed eller licenser kræver det. Basen gælder fremadrettet; 30 stabile sites skal ikke forstyrres af én ny præference.
