Klassiske temaer vs block themes (fse): Valg i 2026

I over et tiår (2010-2020) så utvikling av WordPress-temaer lik ut: du opprettet header.php, footer.php, en løkke i index.php og stiler i style.css. Logikken lå i PHP, utseendet i CSS, og de to verdenene møttes sjelden.

Med WordPress 5.9 kom Full Site Editing (FSE), i dag bare kalt nettstedsredigereren (Site Editor), og i 2026 er spørsmålet skarpere enn noen gang: skal du fortsatt skrive temaer i PHP, eller gå helt over til blokker, HTML-maler og theme.json?

Denne guiden går gjennom hva blokktemaer faktisk er, hvordan de skiller seg fra klassiske temaer på kodenivå, når hvert av dem vinner og hvordan du planlegger en migrering. Den dekker den klassiske, den blokkbaserte og den hybride modellen.

Kort svar: velg et blokktema når du vil styre nettstedet fra editoren, samle design tokens i én fil og følge retningen WordPress-kjernen utvikles i. Behold et klassisk tema når prosjektet fortsatt er avhengig av egne PHP-maler, streng kontroll over layout eller en arbeidsflyt tung på sidebyggere. Hybridmodellen ligger mellom de to, og det er der en stor del av profesjonelle prosjekter havner.

#Hva er et blokktema i WordPress

Et blokktema er et WordPress-tema bygget helt av blokker: malene er HTML-filer med blokkmarkering i stedet for PHP-filer, design tokens ligger i én theme.json-fil, og hver del av nettstedet (header, footer, arkiver, 404) redigeres visuelt i nettstedsredigereren. Full Site Editing (FSE) er samlebetegnelsen for dette systemet, og det lønner seg å definere delene før sammenligningen, fordi flere separate delsystemer ble innført samtidig.

Nettstedsredigereren (Utseende > Redigering) er et visuelt grensesnitt for å redigere alle deler av et nettsted: maler, maldeler, stiler, mønstre og navigasjon. I et klassisk tema redigerte du bare innholdet i innlegg og sider i blokkeditoren. I et blokktema redigerer det samme blokklerretet nå header, footer, malen for enkeltinnlegg, arkiv, 404 og søkeresultater.

theme.json er én konfigurasjonsfil i temaets rotmappe som deklarerer design tokens og innstillinger for editoren. Den definerer fargepalett, typografiskala, avstandsskala, layoutbredder og hvilke kontroller som vises i editoren. WordPress leser filen og genererer CSS-variabler (custom properties) for både frontend og editor, slik at redigeringsvisningen stemmer med den publiserte siden.

Blokkmaler og maldeler er HTML-filer under templates/ og parts/. I stedet for single.php leverer du templates/single.html, og i stedet for en hardkodet footer i footer.php leverer du parts/footer.html. Filene inneholder blokkmarkering (HTML-kommentarer som <!-- wp:post-title /-->), ikke PHP.

Globale stiler er laget brukeren ser oppå theme.json. Eieren av nettstedet kan justere farger, fonter og avstand fra Stiler-panelet uten å røre kode, og temaer kan levere alternative stilvariasjoner som ekstra JSON-filer i en styles/-mappe.

Blokkmønstre er ferdige, gjenbrukbare oppsett av blokker. De har tatt over mye av det sidebyggere tilbød: en hero, en prisseksjon, en handlingsoppfordring, alt redigerbart som innebygde blokker og registrert fra en patterns/-mappe.

Å forstå disse fem delene er det meste av jobben. Et blokktema er i bunn og grunn theme.json pluss HTML-maler pluss mønstre, redigert i nettstedsredigereren.

#Hvilke filer et WordPress-tema faktisk krever

Et klassisk tema trenger nøyaktig to filer før WordPress viser det og lar deg aktivere det: style.css, der header-kommentaren bærer temanavnet og resten av metadataene, og index.php som siste utvei for maler. Alt annet du vanligvis ser, header.php, footer.php, functions.php, single.php, page.php, er strengt tatt valgfritt og blir nødvendig først når malhierarkiet skal forgrene seg. Et blokktema bytter ut den andre filen: style.css bærer fortsatt header-kommentaren, men reservemalen er templates/index.html i stedet for index.php. theme.json er heller ikke formelt påkrevd, men et blokktema uten den arver kjernens standardverdier for farger, avstand og typografi, og det er nesten aldri det du vil ha. Et undertema (child theme) legger til én regel: Template:-linjen i headeren i style.css må peke på mappen til foreldretemaet.

#1. Malfiler i klassiske temaer og blokktemaer

Dette er den mest grunnleggende forskjellen, og den som uroer mange erfarne utviklere.

#Klassisk tema

Bygger på PHP-filer. Når WordPress laster en side, går den gjennom malhierarkiet (for eksempel single-product.php, så single.php, så index.php), og PHP-motoren setter sammen header, løkke og footer når forespørselen kommer.

• Struktur: header.php, page.php, single.php, archive.php, sidebar.php, functions.php.
• Logikk: du kan fritt blande PHP og HTML, for eksempel if ( is_user_logged_in() ) eller en helt egen WP_Query-løkke.
• Fordel: full kontroll over markeringen og enkel innsetting av forretningslogikk, kall til eksterne API-er eller betingede visninger.
• Ulempe: eieren av nettstedet kan ikke endre header, footer eller layout uten å redigere kode eller be en utvikler.

#Blokktema

Bygger på HTML-malfiler med blokkmarkering. Det finnes ikke PHP i selve malfilene.

• Struktur: templates/index.html, templates/single.html, parts/header.html, parts/footer.html, theme.json.
• Logikk: ingen i malfilen. Malene er statisk blokkmarkering, og all dynamisk utdata kommer fra blokker som <!-- wp:post-title /-->, Query Loop-blokken eller Innleggsinnhold-blokken.
• Fordel: eieren kan redigere hele nettstedet, inkludert header og footer, på ett visuelt lerret.
• Ulempe: egen logikk på serversiden må flyttes til en egen blokk, en blokkvariasjon, Block Bindings API eller en kortkode, i stedet for å ligge direkte i malen.

Tankeskiftet er at presentasjonslogikken forlater malfilen. Der et klassisk tema legger en betingelse rett i single.php, uttrykker et blokktema det samme gjennom blokkontekst, block bindings eller en egen blokk registrert i en utvidelse eller i temaets functions.php.

#2. Hva theme.json erstatter i functions.php

I den klassiske æraen var functions.php stedet for alt: registrering av menyer, sidefelt, bildestørrelser, innlasting av stilark og skript, og flagg via add_theme_support(). Designbeslutninger lå spredt mellom PHP og én eller flere CSS-filer.

I blokkæraen samler theme.json konfigurasjonen. Den styrer:

1. Fargepalett: navngitte farger som tilbys redaktørene, skrevet ut som CSS-variabler.
2. Typografi: skriftstørrelser, skriftfamilier, linjehøyde og flytende typografi (fluid).
3. Avstand: en avstandsskala og blokkavstand (block gap) som brukes likt på tvers av blokker.
4. Layout: innholdsbredde og bred bredde (contentSize, wideSize) som styrer justering.
5. Kontroller og tilgjengelighet: appearanceTools, innstillinger per blokk og muligheten til å skru av kontroller redaktørene ikke skal røre.

Eksempel på theme.json i 2026:

{
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": { "contentSize": "720px", "wideSize": "1200px" },
    "color": {
      "palette": [
        { "slug": "primary", "color": "#0055FF", "name": "Merkeblå" }
      ]
    },
    "typography": {
      "fluid": true,
      "fontSizes": [
        { "slug": "small", "size": "14px", "name": "Liten" }
      ]
    }
  }
}

I stedet for å vedlikeholde hundrevis av linjer CSS pluss registrering i PHP, deklarerer du tokens én gang i JSON. Hvordan du bygger disse tokens opp til et designsystem som deles mellom prosjekter, står i guiden om skalerbare designsystemer med Gutenberg. WordPress genererer optimalisert CSS og CSS-variabler for frontend og editor, og derfor stemmer forhåndsvisningen i editoren endelig med det publiserte resultatet. functions.php finnes fortsatt i et blokktema, men blir liten: laste inn en font, registrere en mønsterkategori, legge til flagg for editorstøtte og lite annet.

#3. Hvordan globale stiler og stilvariasjoner fungerer

theme.json setter standardverdiene, og globale stiler lar eieren overstyre dem uten kode. Fra Stiler-panelet kan en redaktør bytte brødtekstfont, justere paletten eller endre avstanden, og valgene lagres per nettsted.

Temaer kan også levere stilvariasjoner: ekstra JSON-filer i en styles/-mappe som viser hele nettstedet i et annet uttrykk, for eksempel en mørk variant eller en med høy kontrast, valgbart med ett klikk. Klassiske temaer har aldri hatt dette innebygd, og det er et av de sterkeste argumentene for blokktemaer i prosjekter der merkevaren skal være fleksibel.

Prisen er styring. Gir du en redaktør uten opplæring full tilgang til globale stiler, kan resultatet bli inkonsekvent typografi eller ødelagt kontrast. Blokktemaer svarer med blokklåsing (block locking) og ved å skru av bestemte kontroller i theme.json, men utvikleren må sette disse grensene bevisst.

#4. Hva skjer med widgeter og menyer i et blokktema

I blokktemaer finnes det som standard ingen Widgeter-skjerm og ingen klassisk Menyer-skjerm under Utseende.

• I stedet for widgeter har du maldeler (template parts). Footeren er en HTML-maldel du redigerer på samme blokklerret som et hvilket som helst innlegg.
• I stedet for den klassiske menyeditoren har du Navigasjon-blokken, redigert direkte i headeren, og menyen lagres som et gjenbrukbart objekt av typen wp_navigation.

For kunder vant til eldre WordPress er dette et reelt kultursjokk. De kjente punktene “Widgeter” og “Menyer” er borte, erstattet av blokker. Noen utvidelser som registrerte widgeter, leverer nå blokker i stedet, og noen eldre viser widgeten sin bare gjennom den eldre Widget-blokken som en bro for kompatibilitet. Å revidere kompatibiliteten til utvidelsene er derfor et reelt steg før du binder en kunde til et blokktema.

#5. Sammenligning av funksjoner i blokktema og klassisk tema

Tabellen viser hvor de to modellene skiller lag i det daglige arbeidet.

Les tabellen som en hjelp til beslutningen, ikke som en resultattavle. Ingen kolonne er alltid best; riktig valg avhenger av hvem som redigerer nettstedet og hvor mye egen serverlogikk malene bærer.

#6. Er blokktemaer raskere enn klassiske temaer

I mange år var svaret et klart ja, og siden WordPress 6.9 er forskjellen mye mindre.

1. Stiler for kjerneblokker: blokktemaer laster CSS for kjerneblokker separat og bare for blokker som faktisk rendres, fordi _add_default_theme_supports() slår på should_load_separate_core_block_assets og should_load_block_assets_on_demand. Klassiske temaer fikk tidligere det samlede stilarket wp-block-library på hver side. Fra 6.9 setter wp_load_classic_theme_block_styles_on_demand() de samme to filtrene for klassiske temaer og legger til en utdatabuffer som flytter sene stiler opp i head. Bufferen har en kostnad: den stopper strømming av svaret, så tiden til første byte kan øke litt. Et tema som trenger strømming, kan skru den av med filteret wp_should_output_buffer_template_for_enhancement.
2. Design tokens i stedet for stilark: theme.json skriver ut CSS-variabler i stedet for en tung kaskade. Et klassisk tema får de samme tokens så snart det får en theme.json-fil.
3. Temaets eget stilark: her består en reell forskjell. Et klassisk tema har ofte én stor style.css med alle komponenter, mens et blokktema holder det meste av stilen i theme.json og i stiler per blokk.
4. Renere markering, med et forbehold: FSE gir ofte ryddig utdata, men nestede layoutblokker kan gi ekstra omsluttende div-elementer (“div-itis”) hvis mønstrene bygges uforsiktig.

Et tema har ingen Lighthouse-score, det har en side. På et ekte nettsted avhenger resultatet langt mer av samtykkebanneret, innebygde kart og skjemaer, fontfiler og bildestørrelser enn av tematypen. Mål dine egne sider; guiden til Core Web Vitals viser hvordan.

Utvikleropplevelsen er mer blandet og avhenger av teamet. Utvikling av blokktemaer lener seg på JSON-konfigurasjon, blokkmarkering og JavaScript for egne blokker (block.json, register_block_type, verktøykjeden @wordpress/scripts). Team med dype røtter i PHP, men lite erfaring med React og blokkverktøy, står foran en reell læringskurve. Klassisk utvikling er umiddelbart kjent for enhver PHP-utvikler, men gir ikke kunden visuell redigering eller et system for design tokens uten ekstra arbeid. I praksis er den raskeste veien for et PHP-tungt team et hybridtema: først theme.json og mønstre, så egne blokker gradvis.

#7. Migrering fra klassisk tema til blokktema

Migrering er sjelden én bryter. Innholdet i databasen (innlegg, sider, media) påvirkes ikke, men presentasjonslaget må bygges på nytt.

Praktiske hensyn:

• Maler: hver PHP-mal trenger en tilsvarende blokkmal. Komplekse betingede maler må ofte deles opp i mønstre pluss block bindings.
• Menyer: eksisterende menyer konverteres ikke automatisk; du bygger dem på nytt som Navigasjon-blokker, men menypunktene går som regel raskt å gjenskape.
• Widgeter: widgetområder finnes ikke i et blokktema, så widgeter i sidefelt og footer blir maldeler eller blokker.
• Innstillinger i Customizer: valg gjort i Customizer (logo, farger, egen CSS) flyttes til theme.json og globale stiler. Egen CSS kan beholdes i feltet for ekstra CSS i globale stiler under overgangen.
• Utdata fra utvidelser: sjekk at hver aktive utvidelse leverer blokker eller kortkoder, og ikke er avhengig av widgeter eller malkroker som et blokktema ikke kjører på samme måte.

En trygg vei er gradvis: gjør først det klassiske temaet om til et hybridtema ved å legge til theme.json og støtte for blokkmønstre, kontroller design tokens og redigeringsopplevelsen, og bytt så ut PHP-malene med blokkmaler én etter én. Slik slipper du en risikabel omskriving på én gang og kan teste hver mal mot ekte innhold og Core Web Vitals før du går videre.

#8. Når du bør bli på et klassisk tema

Et klassisk tema er fortsatt riktig valg når:

• Prosjektet bærer mye egen PHP-logikk i visningene, for eksempel avanserte visningsbetingelser, egne løkker eller dype overstyringer av WooCommerce-maler.
• Kunden ikke er komfortabel med full redigering, og du må hindre utilsiktede endringer i header eller footer.
• Nettstedet er bygget på en sidebygger som Elementor eller Divi, som fortsatt forutsetter en klassisk struktur og i stor grad går utenom FSE.
• Du vedlikeholder et modent nettsted der kostnaden ved migrering klart overstiger gevinsten.
• Teamet er først og fremst PHP-basert og har lite kapasitet til å investere i blokkverktøy nå.

#9. Når du bør velge et blokktema

Et blokktema er det sterkeste valget når:

• Nettstedet er drevet av innhold: et bedriftsnettsted, en blogg, en publikasjon eller en portefølje.
• Eieren vil redigere header, footer og maler uten en utvikler ved hver endring.
• Du vil ha design tokens og stiler per blokk som standard i stedet for et stort stilark i temaet.
• Fleksibilitet i merkevaren betyr noe, og stilvariasjoner gir reell verdi.
• Du vil følge retningen til WordPress-kjernen, som nå konsentrerer utviklingen om blokkopplevelsen og FSE.

#10. Blokktema eller klassisk tema for WooCommerce, blogger og LMS

• Småbedrift eller bedriftsnettsted: blokktema. Redaktørene får trygg kontroll over hele layouten.
• Blogg eller publikasjon: blokktema. Query Loop-blokken, mønstre og ren markering passer godt til redaksjonelle arbeidsflyter.
• Portefølje eller presentasjonsside: blokktema, ofte med et par stilvariasjoner for sesongbaserte uttrykk.
• WooCommerce-butikk: det kommer an på. Moderne blokkbasert handlekurv og kasse passer et blokktema, men butikker med omfattende egne PHP-maler for produkter kan bli på klassisk eller hybrid.
• Medlemskap, LMS eller kompleks applikasjon: klassisk eller hybrid. Tung visningslogikk og integrasjoner med eksterne systemer er enklere å kontrollere i PHP-maler.
• Nettsted styrt av en sidebygger: klassisk. Byggeren eier allerede layouten, så FSE tilfører lite.

#Hva er et hybridtema i WordPress

Hybridmodellen er den pragmatiske mellomveien. Det er et klassisk PHP-tema som legger til theme.json (for fargepalett, typografi og avstandstokens i editoren) og støtte for blokkmønstre, men beholder utvalgte PHP-maler som header.php eller single.php for kontroll over strukturen. Mange profesjonelle prosjekter i 2026 leveres akkurat slik: blokkredigering der det hjelper, PHP der det betyr noe.

#Hvilke funksjoner i nettstedsredigereren som fungerer med klassiske temaer, etter WordPress-versjon

Grensen mellom de to tematypene har flyttet seg i nesten hver versjon. Theme Handbook beskriver hybridtemaer som “klassiske temaer som har tatt i bruk noen moderne blokkrelaterte funksjoner”, og påpeker at hybrid ikke er en offisiell tematype (What is a theme, egen oversettelse). Tabellen viser hva som kom til klassiske temaer og når, med datoer fra WordPress sitt utgivelsesarkiv.

I dagens kjerne gir wp-admin/menu.php et klassisk tema hele Design-oppføringen i nettstedsredigereren når temaet har theme.json eller deklarerer støtte for editor-styles, og ellers bare Mønstre-oppføringen. Et blokktema får Redigering-oppføringen. Derfor er det praktiske spørsmålet i 2026 sjelden “klassisk eller blokk” i det abstrakte. Det er hvilke av disse funksjonene et prosjekt tar i bruk, i hvilken rekkefølge, og om det siste steget, å legge til templates/index.html, i det hele tatt lønner seg.

#WordPress blokktema eller klassisk tema: hva du bør velge i 2026

Valget avhenger av tre faktorer: hvor komplekst prosjektet er, kundens tekniske ferdigheter og kravene til vedlikehold på lang sikt.

Velg et blokktema når:

• Kunden må redigere header, footer og maler uten hjelp fra en utvikler
• Redaktørene skal endre maler og globale stiler uten en utrulling
• Du vil bruke theme.json til design tokens (farger, typografi, avstand) i stedet for spredt CSS
• Prosjektet er nytt og har ingen gammel kode å vedlikeholde

Velg et klassisk tema når:

• Du trenger kompleks PHP-logikk i malene (egne løkker, betingede layouter, overstyringer i WooCommerce)
• Prosjektet er avhengig av widgeter, klassiske menyer eller Customizer
• Teamet har dyp PHP-kompetanse, men begrenset erfaring med utvikling av Gutenberg-blokker
• Du vedlikeholder et eksisterende nettsted, og migreringen koster mer enn den gir

Hybridtilnærmingen: mange profesjonelle WordPress-prosjekter i 2026 bruker et klassisk tema med selektiv blokkstøtte. Registrer blokkmønstre og maler der de gir verdi, og behold PHP-maler der de gir mer kontroll. WordPress tvinger deg ikke til et alt-eller-ingenting-valg.

WordPress 7.0 kom 20. mai 2026 og 7.1 19. august 2026; gjeldende versjon er 7.1.3 fra 6. oktober 2026. Abilities API kom tidligere, i 6.9, og virker likt med begge tematyper, så det er ikke et argument for noen av arkitekturene.

#Oppsummering av klassiske temaer og blokktemaer

WordPress-verdenen har delt seg i to leirer. Ikke kjemp mot det. Lær deg syntaksen til theme.json, det er en ferdighet som er like viktig i 2026 som å kunne CSS var i 2015.

Valget mellom klassisk tema og blokktema følger deg videre i hver eneste endring du gjør i theme.json. Skal noen se på temaoppsettet ditt med friske øyne, finner du oss under WordPress-utvikling for temaer og FSE.