Utvikling, tilpasning og tematilpasning for WordPress

#Utvikling av WordPress-nettsider og butikker

Mesteparten av temaarbeidet som havner på vårt bord er ikke et nybygg. Det er en arvet kodebase fra perioden 2018 til 2020, med en functions.php som har vokst til 1200-1800 linjer, tre eller fire “must-use”-plugins som aldri ble installert riktig, og en mal-hierarki som brytes på subtile måter så snart en custom post type legges til. Vi avgjør om temaet bør refaktoriseres eller bygges om til et block theme etter en kodegjennomgang, ikke før.

#Block themes mot klassiske temaer i 2026

Full Site Editing er standardflaten for nye WordPress-prosjekter. Valget mellom et block theme og et klassisk tema er ikke lenger en stilpreferanse, det er et arkitektonisk valg med konsekvenser for redaktør-UX, innholdsportabilitet og hvor mye PHP teamet ditt må vedlikeholde.

Et block theme er det riktige valget når redaksjonen trenger direkte kontroll over layout, når nettstedet baserer seg på gjenbrukbare patterns i stedet for faste maler, og når det meste av designintensjonen kan leve inne i theme.json. Konfigurasjonen dekker fargepalett, fluid typografi via clamp(), spacing-skalaen og blokkspesifikke stilvarianter. Kombinert med register_block_pattern_category og et lite bibliotek av patterns registrert via register_block_pattern, får redaksjonen et kontrollert komponentsett i stedet for et åpent lerret.

Et klassisk tema gir fortsatt mening i smale tilfeller: en tung WooCommerce-butikk med egne checkout-maler, en langvarig redaksjonell arbeidsflyt knyttet til PHP-template parts, eller et prosjekt som hviler på en ACF-basert innholdsmodell redaksjonen allerede kan. Vi migrerer ikke fungerende klassiske temaer til FSE for prinsippets skyld. Vi migrerer dem når kostnaden ved å vedlikeholde den gamle strukturen overstiger kostnaden ved et rent rebuild.

Det vi unngår er det verste fra begge verdener: et block theme som omgår theme.json og hardkoder stiler i CSS, eller et klassisk tema som har fått isolerte Gutenberg-blokker etterklistret. Begge produserer den slags splittede logikk som gjør et endags-fix om til en uke med detektivarbeid et år senere.

#Norsk redaksjonsestetikk i theme.json

Norske redaksjonelle prosjekter har en gjenkjennelig estetikk: rikelig med whitespace, sparsom dekorasjon, typografi som bærer hierarkiet uten farge eller bokser. Vi konfigurerer theme.json med skriftpar som speiler den tradisjonen, Söhne paret med Tiempos Headline, eller Inter med Source Serif, i NRK-aktig retning. Spacing-skalaen følger en typografisk vertikalrytme (8/16/24/40/64 px), ikke vilkårlige Tailwind-defaults. Linjelengden låses til 60-72 tegn for brødtekst, ikke 100+ som i mange amerikanske block themes.

#WCAG og Aksess-test innebygd

Tilgjengelighet er ikke et lag som legges på til slutt. theme.json-paletten valideres mot WCAG 2.2 AA-kontrast under designfasen, ikke etter launch. Block patterns registreres med ARIA-landmark-roller, fokusrekkefølge testes manuelt med tastatur før hver milepæl, og semantisk HTML5 (<article>, <aside>, <nav>) erstatter <div>-supper. Skjermleser-testing kjøres med VoiceOver og NVDA mot kritiske flyter, frontside, artikkelvisning, skjema, checkout. Det er forutsetningen for å passere norsk Aksess-test, og det er det utgangspunktet vi leverer fra.

#Custom blocks gjort riktig

Egne blokker hører hjemme i @wordpress/scripts, med en block.json-metadatafil som beskriver attributter, supports og editor-skript. Server-side rendering via en render_callback holder markup konsistent mellom redigeringsverktøy og frontend, unngår hydration-mismatch og gjør det mulig å videreutvikle den gjengitte HTML-en uten å bryte eldre innlegg. Statiske blokker som lagres i post_content er fortsatt gyldige for rent strukturelle elementer (en stylet callout, en layout-wrapper), men alt som avhenger av dynamiske data bør rendres serverside.

#Ytelse der det faktisk vises

Core Web Vitals-mål vi jobber mot: LCP under 2,0 s, CLS under 0,05, INP under 200 ms. Å treffe disse tallene på en reell WordPress-installasjon handler først og fremst om å fjerne, ikke legge til. Vi inliner kritisk CSS for above-the-fold-visningen, utsetter eller eliminerer render-blokkerende JavaScript, fjerner jQuery-avhengigheten klassiske temaer fortsatt drar med seg, og reserverer plass for medier for å holde CLS lav. Det handler ikke om audit-poengsummen. Det handler om at LCP på 2,4 s og LCP på 0,7 s oppfører seg ulikt i konverteringsdata, og det andre tallet er oppnåelig på delt hosting med et riktig bygget tema.

#Arbeid med arvede temaer

Vanlige mønstre vi løser opp:

• Underordnede temaer som overstyrer foreldretemaet direkte i functions.php i stedet for via add_filter- og add_action-hooks, slik at en parent-oppdatering stille knekker halve nettstedet.
• Temaer bygget før Gutenberg som registrerer sidebars og widgets redaksjonen ikke har brukt på to år, men som fremdeles laster sine ressurser på hver side.
• Egendefinerte page-templates som hviler på globale variabler satt i header.php, og som forsvinner når WordPress går over til en blokkbasert header-pattern.
• WooCommerce-template-overstyringer kopiert fra eldre plugin-versjoner, som driver to-tre minor-releases bak de kanoniske templatene.

Vi lapper dem ikke på stedet. Vi mapper hver custom funksjon mot enten en blokk, en pattern eller et lite fokusert plugin, og bygger så temaet på nytt på toppen av theme.json og en ren mal-hierarki. Det gamle temaet ligger tilgjengelig på staging til det nye består paritetstesten.

#Et nylig rebuild

Ett kundeoppdrag som fanger den typiske formen på dette arbeidet: et custom-tema fra 2018 med rundt 1400 linjer functions.php, seks widget-områder redaksjonen hadde sluttet å bruke, og en LCP på 2,4 s på forsiden. Nettstedet hvilte på tre plugins som kun fantes for å lappe rundt begrensninger i originalen (en custom shortcode-renderer, et “ytelse”-plugin som forsøkte å reversere temaets render-blokkerende CSS, og et tredje som koblet menu-walker til et megamenu-bibliotek).

Rebuildet flyttet hele flaten til et block theme. Fluid typografi og spacing-skala vandret inn i theme.json. Shortcodene ble fire custom-blokker bygget med @wordpress/scripts og rendret serverside. Megamenuen kollapset til den native navigation-blokken pluss én pattern. Etter launch falt LCP til 700 ms på samme hosting, de tre lappepluginene ble fjernet, og functions.php krympet til omtrent 180 linjer som kun gjør det som ikke kan uttrykkes i theme.json eller blokk-konfigurasjon. Den redaksjonelle arbeidsflyten ble bedre som sideeffekt: redaktørene sluttet å åpne tickets for å be utviklere legge til seksjoner, fordi pattern-biblioteket dekket behovet.

#Norsk SEO og redaksjonell arbeidsflyt

Norskspråklig SEO i WordPress handler ikke bare om å oversette nøkkelord. theme.json konfigureres med slug-mønstre som tar høyde for æ, ø, å (bærekraftig, støy, fårikål), strukturerte data (Schema.org Article, BreadcrumbList, Organization) inkluderer inLanguage: nb-NO, og hreflang håndteres via Polylang eller WPML når prosjektet kombinerer bokmål, nynorsk og engelsk. Custom block-patterns leveres med korrekt norsk typografi: anførselstegn (« »), tankestrek (–) i stedet for em-dash, og ikke-brytende mellomrom før prosenttegn og enheter.

For redaksjonelle CMS-arbeidsflyter integrerer vi gjerne med eksterne redaksjonssystemer (planlegging, oppgavestyring, fact-checking) via WordPress REST API, slik at journalistene jobber i sitt vante grensesnitt og publiseringen skjer transaksjonelt mot WordPress.

#Slik jobber vi

Hvert oppdrag begynner med en kort teknisk gjennomgang. Vi ser på det eksisterende temaet (eller designfilene, ved nybygg), hostingen, plugin-listen, custom post types og den redaksjonelle arbeidsflyten teamet faktisk bruker. Resultatet er en skriftlig vurdering med to eller tre implementeringsalternativer, kompromissene ved hvert, og en realistisk tidsplan.

Derfra går arbeidet i milepæler, ikke i én stor leveranse. Et typisk theme-rebuild deles i discovery, theme.json og pattern-bibliotek, custom blocks, innholdsmigrering med paritetstest, og et launch-vindu med rollback-plan klar. Koden ligger i Git fra dag én, kjører på et staging-miljø som speiler produksjon, og deployer via CI, ikke via FTP.

Pris settes individuelt fordi prosjektene sjelden ligner. En fokusert refaktorering av et tema ligger i én bracket; et fullt block-theme-rebuild med WooCommerce i en annen, og et headless-oppsett med WordPress som innholdslag i en tredje. Vi gir tilbud etter den tekniske gjennomgangen, mot definert scope.

#Når custom temautvikling er riktig valg

Custom temautvikling lønner seg i et avgrenset sett situasjoner. Det er det riktige valget når redaksjonen trenger et kontrollert komponentbibliotek i stedet for en fri builder, når ytelsesbudsjettet er trangt nok til at et generisk tema ikke holder, når nettstedet må integreres med CRM, ERP eller fulfillment-system som krever egne blokker og admin-skjermer, eller når et eksisterende tema har samlet nok teknisk gjeld til at vedlikehold per kvartal koster mer enn et engangs-rebuild.

Det er ikke det riktige valget når prosjektet er en fem-siders brosjyre uten integrasjoner og uten ytelsespress. I det tilfellet er et godt konfigurert block theme med et lite pattern-bibliotek raskere ute og enklere å vedlikeholde enn et custom build, og vi sier ifra.

Headless-veien, med WordPress som innholds-API bak en Astro- eller Next.js-frontend, er en separat avgjørelse og sjelden riktig svar for et rent markedsføringsnettsted. Den fortjener kompleksiteten når samme innhold må mate flere flater (web, mobil, in-product), eller når frontend-stacken allerede finnes og WordPress legges til som CMS-lag.

#Avsluttende tanker

Temaarbeid handler i stor grad om hva som skal fjernes. De fleste ytelses-, sikkerhets- og redaksjonsproblemer vi blir bedt om å rette starter med et tema som gjør for mye: laster render-blokkerende CSS for seksjoner ingen bruker, registrerer custom post types som aldri kom inn i arbeidsflyten, hekter seg på filtre som ikke lenger eksisterer. Et rent tema på toppen av theme.json, et lite bibliotek av blokker og patterns, og en functions.php som får plass på én skjerm overlever hvert “all-in-one”-tema fra markedet.

Hvis du har et arvet WordPress-tema som har sluttet å tjene virksomheten, eller et nytt prosjekt der du vil ha arkitekturen avgjort før designet er ferdig, ta kontakt via kontaktsiden. Vi starter med en teknisk gjennomgang og et individuelt tilbud.

#FAQ - Vanlige spørsmål

Hvor lang tid tar det å utvikle et tilpasset WordPress-tema?

Tiden det tar å utvikle et tilpasset WordPress-tema avhenger av kompleksiteten i prosjektet. Et enkelt tema med grunnleggende funksjonalitet kan ta mellom to og fire uker, mens mer komplekse prosjekter med avanserte funksjoner, e-handelsintegrasjon eller omfattende tilpasninger kan ta flere måneder. Vi gir alltid en estimert tidsramme basert på en grundig gjennomgang av dine spesifikke krav, og vi holder deg oppdatert gjennom hele prosessen.

Hva koster et tilpasset WordPress-tema?

Prisen for et tilpasset WordPress-tema varierer basert på omfanget av prosjektet og hvilke funksjoner som kreves. Enkle tema-tilpasninger kan starte på noen tusen kroner, mens full temautvikling med omfattende funksjonalitet og design kan koste betydelig mer. Vi tilbyr konkurransedyktige priser og transparente kostnadsoverslag, og vi diskuterer alltid budsjettet med deg før vi starter arbeidet.

Kan jeg beholde mitt eksisterende innhold når jeg bytter til et nytt tema?

Ja, i de fleste tilfeller kan allt ditt eksisterende innhold overføres til det nye temaet. WordPress lagrer innholdet separat fra temaet, så innlegg, sider, bilder og andre medier vil forbli intakte. Vi tester alltid nøye at alt innhold vises riktig i det nye temaet før lansering, og vi gjør eventuelle justeringer som er nødvendige for å sikre at alt fungerer som det skal.

Hvordan sikrer dere at temaet er kompatibelt med fremtidige WordPress-oppdateringer?

Vi følger strenge utviklingsstandarder og beste praksis for WordPress-utvikling. Dette inkluderer bruk av de nyeste WordPress API-ene og -funksjonene, unngåelse av foreldede funksjoner, og grundig testing av kompatibilitet. Vi dokumenterer all kode grundig og gir deg detaljerte instruksjoner for vedlikehold. Med våre vedlikeholdsavtaler sørger vi også for at temaet oppdateres regelmessig for å forbli kompatibelt med nye WordPress-versjoner.

Tilbyr dere opplæring i hvordan jeg bruker det nye nettstedet?

Ja, vi tilbyr omfattende opplæring som en del av alle våre prosjekter. Du vil få en gjennomgang av alle funksjoner i temaet, inkludert hvordan du oppretter og redigerer innhold, hvordan du håndterer bilder og medier, og hvordan du bruker eventuelle egendefinerte funksjoner vi har bygget. Vi gir også skriftlige dokumentasjon og videoer som du kan referere til senere.

Hva skjer hvis jeg opplever problemer med nettstedet etter lansering?

Vi gir alltid en garantiperiode etter lansering der vi løser eventuelle problemer uten ekstra kostnad. Etter garantiperioden kan du kjøpe en av våre støtteavtaler for assistanse, eller du kan kontakte oss for enkeltstående oppdrag. Vårt mål er å sikre at du alltid er fornøyd med ditt nettsted og at det fungerer problemfritt.

Kan dere hjelpe med å flytte mitt eksisterende nettsted til WordPress?

Absolutt. Vi har erfaring med å migrere nettsteder fra ulike plattformer til WordPress. Enten du kommer fra en annen CMS-løsning, en eldre HTML-side, eller til og med fra en annen WordPress-installasjon, kan vi hjelpe deg med å flytte innholdet ditt sømløst. Vi sørger for at alle URL-er omdirigeres riktig for å bevare din SEO-verdi, og vi tester alt grundig etter overføringen.