Oxygen 6: hvorfor vi bygger komponenter før vi bygger sider

De fleste nettsider blir vanskelige å endre etter et halvt år.

Ikke fordi WordPress er dårlig. WordPress driver en stor del av verdens nettsteder og gjør det helt fint. Det handler heller ikke om byggeren. Vi bygger i Oxygen 6, men en side kan låse seg fast i hvilken som helst bygger. Problemet er hvordan fundamentet ble lagt: siden ble bygget for å se ferdig ut, ikke for å bli endret.

Symptomene er alltid de samme. Bedriften bytter merkefarge, og fargen viser seg å stå skrevet direkte på nittitre elementer fordelt på fjorten sider. Det skal legges til en tjeneste, og det finnes ingen mal for en tjenesteside — den forrige ble bygget for hånd, så den nye må også bygges for hånd, fra bunnen. Overskriftene i en seksjon er 32 piksler på tre sider og 34 på den fjerde, fordi noen skrev tallet inn i et felt en tirsdag i mars.

Ingen av delene er en feil noen gjorde med vilje. Det er summen av at hver side ble bygget som sin egen lille øy.

---

Kort vei til svaret: skal du ha en side du faktisk kan endre selv, snakk med oss om oppsettet før noen begynner å bygge. Vil du forstå hvorfor rekkefølgen betyr så mye, les videre.

Slik vurderer vi byggeverktøy

Dette er ikke en nøytral gjennomgang av alle måter å bygge WordPress på. Det er vår arbeidsmåte, og den er utviklet på våre egne prosjekter — inkludert ebizapple.no, som er bygget nøyaktig slik denne artikkelen beskriver.

Det er verdt å si rett ut: Oxygen 6 var i beta da vi tok den i bruk. Vi valgte den fordi modellen bak den — klasser og variabler framfor innstillinger på enkeltelementer — er den samme modellen vi allerede jobbet etter i CSS. Vi tok altså en bevisst risiko på en versjon som ennå ikke var ferdig, og vi har møtt kanter underveis.

Det vi kan stå inne for:

• Punktene om Oxygen 6 nedenfor er kontrollert mot byggerens egen dokumentasjon og mot bygg vi har gjort selv
• Der en funksjon ikke finnes, står det at den ikke finnes
• Der en annen bygger er et bedre valg, står det hvilken og hvorfor

Det vi ikke påstår: at dette er den eneste riktige måten, eller at resultatet er raskere å komme i mål med første gang. Det er det ikke. Gevinsten kommer på endring nummer to.

Byggere endrer seg. Denne artikkelen gjennomgås på nytt når byggerne endrer seg. Sist gjennomgått 14. august 2026.

Skrevet av Svein Tore Olsen, daglig leder i Ebizapple.

---

Rekkefølgen som avgjør alt

Her er hele poenget, i fire trinn. Det er motsatt rekkefølge av hvordan de fleste gjør det.

1. Variabler først

Farger, typografi og avstander settes som globale CSS-variabler i Oxygen Global Settings. Én gang. Ingenting skrives direkte på et element.

En CSS-variabel er ganske enkelt en navngitt verdi: i stedet for at #2347FF står nittitre steder, står --blue nittitre steder og #2347FF ett sted. Når et sett slike variabler er valgt bevisst og dekker farger, typografi, avstander og radier, er det ikke lenger bare variabler — det er designtokens: det minste felles vokabularet designet er bygget av. Forskjellen på de to begrepene er ikke teknisk, den er hvor disiplinert listen er.

Det høres ut som pedanteri helt til dagen profilen skal endres. Da er det forskjellen mellom å endre én verdi og å lete gjennom fjorten sider etter en fargekode.

2. Komponenter deretter

Header, footer, tjenestekort, priskort, CTA-blokk, FAQ-element, seksjonstittel. Dette er de gjenbrukbare komponentene en nettside settes sammen av. En komponent er en slik byggekloss: bygget én gang, brukt overalt, med ett sted å endre den.

Endrer du tjenestekortet — legger til et ikon, strammer inn avstanden, bytter knappestil — endres det på alle sidene som bruker kortet. Ikke fordi noen husket å oppdatere dem, men fordi det bare finnes ett kort.

Det er også her semantisk HTML hører hjemme. Bygger du kortet med en ekte overskrift, en ekte lenke og en ekte knapp — framfor tre div-er som ser slik ut — bygger du tilgjengeligheten inn i komponenten én gang, i stedet for å rette den på nittitre elementer senere. Skjermlesere, tastaturnavigasjon og søkemotorer leser den samme strukturen, og de leser den fra hver eneste side som bruker kortet.

3. Maler

Standardside, tjenesteside, bloggarkiv, blogginnlegg. En mal er oppskriften for en hel sidetype, og den settes sammen av komponentene fra trinn 2.

Nå eksisterer det en tjenesteside som type, ikke bare som fire enkeltsider som tilfeldigvis ligner på hverandre.

Skal malen fylles med noe annet enn vanlige sider, er det WordPress-kjernen som gjør grovarbeidet — ikke byggeren. En egendefinert innholdstype (custom post type) gir deg «tjeneste» eller «prosjekt» som sin egen sort innhold ved siden av sider og innlegg. En taksonomi er måten du sorterer dem på: kategorier og stikkord er de innebygde, men du kan lage dine egne, som «bransje» eller «fylke». Begge deler lever i WordPress uavhengig av hvilken bygger du bruker, og det er en av grunnene til at et byggerbytte ikke er det samme som å miste innholdet.

4. Så sidene

Først nå bygges de faktiske sidene. Og de bygges fort, fordi det som gjenstår er å velge mal og fylle inn innhold.

Den nye tjenesten du skal legge til om åtte måneder? Den er en mal og et skjema, ikke et byggeprosjekt.

---

Fire ting Oxygen 6 gir deg uten at noe må hjemmesnekres

Dette er ikke en modell vi har funnet på og presset ned over en bygger. Oxygen 6 er class-first med CSS-variabler som designtokens — det er byggerens egen modell. Vi jobber med den, ikke mot den.

Betinget visning på innloggingsstatus er innebygd. Skal «Logg inn» vises til besøkende og «Min side» til innloggede, løses det i byggeren. Betinget visning vil si at ett og samme element vises eller skjules etter en regel — innlogget eller ikke, felt tomt eller utfylt. Ingen ekstra plugin, ingen kodesnutt i temaet, ingenting som brekker ved neste oppdatering.

Det siste er verdt en setning. Den tradisjonelle måten å legge til slik logikk på er en child theme — et lite undertema der man skriver egne funksjoner så de overlever oppdateringer av hovedtemaet. Det fungerer, men det er kode noen må vedlikeholde, og det er kode kunden ikke kan røre. Løses det samme i byggerens grensesnitt, forsvinner både filen og avhengigheten til den som skrev den.

Dynamic Data-løkker gjør oversikter til én mal. Bloggarkivet er ikke tjue sider som må vedlikeholdes — det er én mal som henter innleggene. Samme mekanikk dekker tjenesteoversikt og lokalsider. Vil du ha en ny artikkel i arkivet, publiserer du artikkelen. Ferdig.

Dynamic Data er navnet på broen: elementet i malen peker på et felt i databasen framfor å inneholde en fast tekst. Feltene kommer som regel fra ACF (Advanced Custom Fields), pluginen som lar deg definere egendefinerte felt på en innholdstype — «pris fra», «leveringstid», «ansvarlig rådgiver» — slik at redaktøren fyller ut et skjema i stedet for å formatere en side. Kombinasjonen ACF for feltene, taksonomier for sorteringen og Dynamic Data for visningen er det vi bygger de fleste dynamiske nettsider på. Skal feltene fylles av et annet system og ikke for hånd, er det en automatiseringsjobb — og da er det verdt å vite hvor vanskelig kilden er å hente data fra før noen lover en dato.

Interaksjoner gjøres i byggerens egen motor. Scroll, hover, klikk — alt settes opp i grensesnittet framfor i egen JavaScript. Det gir to gevinster: mindre kode på siden, og noe kunden faktisk kan endre selv. En animasjon skrevet i en JavaScript-fil er noe bare den som skrev den kan røre.

---

Mindre kode har en hyggelig bivirkning for hastighet. Vi lover likevel ikke et tall — vi har skrevet eget om hvorfor vi ikke gir ytelsesgaranti, og komponentbygg endrer ikke på det. Det fjerner unødvendig kode, det er alt. Bilder, tredjepartsskript og hosting avgjør resten.

---

Skal du bygge nytt i høst? Vi setter opp variabler og komponenter først, og viser deg hvordan du endrer dem etterpå — ta en prat med oss.

Der Oxygen ikke er svaret

En ærlig artikkel må ta med hvor verktøyet stopper.

Crocoblock/JetEngine støtter ikke Oxygen. Leverandøren oppgir selv Elementor, Gutenberg, Bricks og Divi. Oxygen står ikke på listen. Det er ikke en policy vi har funnet på — det er deres egen støttematrise.

Crocoblock er en samling utvidelser for WordPress, og JetEngine er den delen av samlingen som bygger egendefinerte innholdstyper, taksonomier og filtrerte oversikter uten kode. Det er et sterkt økosystem — det snakker bare ikke med Oxygen.

Oxygen 6 eller Bricks — når vi velger hva

Konsekvensen av støttematrisen over er konkret: trenger prosjektet fasettfiltrering på tusenvis av oppføringer — eiendom, bemanning, produktkatalog, det finn.no-aktige mønsteret der du krysser av for fylke, pris og tilstand og listen oppdaterer seg — så er Bricks riktigere valg enn Oxygen. Ikke fordi Oxygen er svakt, men fordi den økosystemet som løser fasettfiltrering best ikke snakker med den.

Motsatt vei finnes det ingen tilsvarende sperre. En helt vanlig tjenesteside blir bra i begge, og der er det ikke byggeren som avgjør, men om noen la variablene og komponentene på plass først. Spørsmålet er altså ikke hvilken av dem som er best, men hvilken som stopper først på akkurat din oppgave.

Vi bygger begge deler. Skillet går på datamengde og filtreringsbehov, ikke på smak. Er prosjektet en katalog eller en oppføringsside, hører det hjemme under dynamiske nettsider. Er det en tjeneste- eller bedriftsside under femti sider, er Oxygen 6 vårt valg — og det er den samme vurderingen vi gjør på WordPress-nettsider generelt.

Når er Oxygen riktig — og når ikke?

Tabellen er vår vurdering, ikke en fasit. Flere av radene ender i at svaret er en annen bygger, eller at det ikke er noe å bygge om i det hele tatt.

---

Eie siden, eller leie den

Her er kjerneargumentet, uten teknisk innpakning.

En side bygget av komponenter kan du endre selv. Du bytter en farge i innstillingene, og hele siden følger etter. Du legger til en tjeneste ved å velge malen. Du retter en formulering i CTA-blokken ett sted, og den er rettet overalt.

En side bygget element for element kan bare den som bygde den endre. Ikke fordi noen holder deg som gissel, men fordi kunnskapen om hvor de nittitre fargeverdiene ligger bor i hodet til én person. Hver endring blir en liten utredning, og hver utredning blir en faktura.

Det er forskjellen på å eie siden og å leie den.

Det er verdt å understreke hva som ikke står på spill her. Teksten, bildene, innleggene, de egendefinerte innholdstypene og ACF-feltene ligger i WordPress-kjernen og eies av deg uansett bygger. Det som er bygget i Oxygen, er presentasjonen. Det er en reell kostnad ved et byggerbytte, men det er ikke det samme som å miste innholdet — og det gjelder like fullt for Elementor, Bricks og alle andre.

Det er også grunnen til at vi bruker de første dagene på et prosjekt på noe kunden ikke kan se. Det finnes ingen skjermbilde av «variabler er satt opp riktig». Men det er den delen som avgjør om siden fortsatt er redigerbar om to år — på samme måte som at valg av betalingsløsning i en nettbutikk avgjør kostnader du først kjenner et år senere.

---

Spørsmål om komponenter i Oxygen 6

Hva er en komponent i Oxygen?

Et element du bygger én gang og gjenbruker — for eksempel et tjenestekort, en CTA-blokk eller et FAQ-element. Endrer du originalen, endres alle stedene den brukes. Det motsatte er å kopiere elementet inn på hver side, som betyr at hver framtidig endring må gjøres like mange ganger som du limte inn.

Hvorfor bygge komponenter før sider?

Fordi rekkefølgen bestemmer hva som er lett å endre senere. Bygger du sidene først, blir designvalgene liggende spredt på enkeltelementer. Bygger du variabler og komponenter først, ligger valgene ett sted, og sidene arver dem.

Tar det ikke lengre tid?

Første side tar litt lengre tid. Side nummer fem tar mye kortere tid, og endring nummer ti tar minutter i stedet for timer. På et prosjekt med under fem sider som aldri skal endres, er gevinsten liten — det er en ærlig forbehold.

Kan jeg endre nettsiden selv etterpå?

Det er hele hensikten. Farger, tekst, avstander og innhold er ment å være tilgjengelig for deg. Strukturelle endringer — nye seksjonstyper, nye maler — er fortsatt utviklerarbeid, men de vanlige endringene skal du ikke trenge å be om.

Støtter Crocoblock Oxygen?

Nei. Crocoblock oppgir Elementor, Gutenberg, Bricks og Divi. Trenger du JetEngine og JetSmartFilters til tung filtrering, bygger vi i Bricks i stedet. Det er ikke et nederlag for Oxygen — det er å velge verktøy etter oppgave.

Blir jeg låst til Oxygen?

Innholdet ditt ligger i WordPress og følger med uansett. Selve oppsettet er bygget i Oxygen og må bygges om ved et byggerbytte — det gjelder alle sidebyggere, ikke bare denne. Fordelen med et variabelbasert oppsett er at designsystemet er dokumentert i seg selv, så en ombygging starter med et kart i stedet for med detektivarbeid.

---

Videre lesing om WordPress og Oxygen

• WordPress-nettsider — hva vi leverer og hvordan vi jobber
• Dynamiske nettsider — kataloger, oppføringer og filtrering
• Én mal, ett datasett, én port — malen som må tåle den fattigste raden
• Hvorfor vi ikke lover deg en score på 99 — om ytelsesløfter
• Betalingsløsning for nettbutikk — kostnadene du oppdager senere
• PayPal, Stripe og kort i WooCommerce — når malen skal romme en kasse
• N1 til N5: hvor vanskelig er katalogen din? — før du lover at feltene kan fylles automatisk
• Vi prøvde å hente en hel produktkatalog — hva som møter deg på den andre siden
• Automatisering — når innholdet skal komme av seg selv
• Alle artikler i bloggen

Skal du bygge nytt, eller sitter du med en side du ikke får endret? Vi går gjennom oppsettet med deg og sier ærlig hva som lønner seg å bygge om — ta kontakt.