Slik bygger du skalerbare designsystemer i WordPress med Gutenberg 2026

Et designsystem i WordPress er settet av tokens, tillatte editorkontroller og innsettbare oppsett som Gutenberg faktisk håndhever. Figma-filer håndhever ingenting på det publiserte nettstedet. I 2026 består den kontrakten av theme.json versjon 3, mappen /patterns og et lite antall egne blokker. Alt annet er enten en prototype eller et databaseobjekt du må behandle som nettopp det.

Vi ser den samme svikten om og om igjen på store redaksjonelle nettsteder: merkevareboken ligger i Figma, CSS-en er spredt over fem stilark, og editoren tilbyr fortsatt en fri fargevelger. Markedsavdelingen lanserer så en kampanjefarge som bare finnes på én landingsside. Neste kampanje kopierer den. Et halvt år senere kan ingen si hvilken grønnfarge som er merkevaregrønn. Gutenberg kan hindre dette, men bare hvis du slår av kontrollene og legger paletten i theme.json.

Dette er ingen preken om å bytte sidebygger. Står du mellom Gutenberg og Elementor eller Divi, les sammenligningen av sidebyggere for 2026. Står du mellom et blokktema og et klassisk PHP-tema, les klassiske temaer mot blokktemaer. Denne artikkelen handler om laget etter det valget: hvordan systemet holder seg konsistent når redaktørene bruker blokkinnsetteren hver dag.

#Hvordan sette opp theme.json versjon 3 for et designsystem

Den levende spesifikasjonen er theme.json versjon 3. Den kom med WordPress 6.6: innlegget om seksjonsstiler på WordPress Developer Blog sier at skjemaet for versjon 3 bare støttes på WordPress 6.6 og nyere, eller med Gutenberg-pluginen på en eldre kjerne. Eldre filer med version: 2 lastes fortsatt. Nye innstillinger kommer i versjon 3. Det finnes ingen versjon 4 i den spesifikasjonen, uansett hva mange oppsummeringer fra 2025 påsto.

Pek filen mot skjemaet som tilsvarer den laveste WordPress-versjonen du støtter, ikke mot trunk, med mindre nettstedet alltid kjører Gutenberg-pluginen:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "settings": {},
  "styles": {}
}

settings er det editoren har lov til å gjøre. styles er standardutseendet når ingen overstyrer en blokk. Blander du de to, ender teamet fort opp med å levere et pent standardutseende som redaktørene likevel kan ødelegge med ett klikk.

For et nettsted som må holde seg innenfor merkevaren, ser den første settings-blokken vi skriver slik ut. Den stenger de frie velgerne for farge, skriftstørrelse og avstand, og gir editoren faste skalaer i stedet:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "custom": false,
      "customDuotone": false,
      "customGradient": false,
      "defaultPalette": false,
      "defaultGradients": false,
      "defaultDuotone": false,
      "palette": [
        { "slug": "base", "name": "Base", "color": "#ffffff" },
        { "slug": "contrast", "name": "Contrast", "color": "#111111" },
        { "slug": "primary", "name": "Primary", "color": "#0b3d91" },
        { "slug": "accent", "name": "Accent", "color": "#c2410c" }
      ]
    },
    "typography": {
      "customFontSize": false,
      "dropCap": false,
      "fontSizes": [
        { "slug": "small", "name": "Small", "size": "0.875rem" },
        { "slug": "medium", "name": "Medium", "size": "1rem" },
        { "slug": "large", "name": "Large", "size": "1.5rem" },
        { "slug": "x-large", "name": "Extra large", "size": "2.25rem" }
      ]
    },
    "spacing": {
      "customSpacingSize": false,
      "defaultSpacingSizes": false,
      "spacingSizes": [
        { "slug": "20", "name": "XS", "size": "0.5rem" },
        { "slug": "30", "name": "S", "size": "1rem" },
        { "slug": "40", "name": "M", "size": "1.5rem" },
        { "slug": "50", "name": "L", "size": "2.5rem" },
        { "slug": "60", "name": "XL", "size": "4rem" }
      ]
    }
  }
}

color.custom: false tilsvarer det gamle add_theme_support( 'disable-custom-colors' ). defaultPalette: false skjuler kjernens grå og blå fargeprøver, slik at velgeren bare viser dine slugs. Koblingen står i håndboken Global Settings and Styles. Blir de to flaggene stående på standardverdien (true), har du ikke et designsystem. Du har et forslag.

customSpacingSize: false fjerner det frie feltet for avstand, og defaultSpacingSizes: false hindrer kjernen i å legge sin egen avstandsskala ved siden av din. Begge nøklene står under settings.spacing i den levende referansen, sammen med spacingSizes og spacingScale.

appearanceTools: true er ingen låsebryter. Den levende referansen lister hva den slår på: bakgrunnsbilde og bakgrunnsstørrelse, kantfarge, kantradius, kantstil og kantbredde, farger på lenker, overskrifter, knapper og bildetekster, sideforhold, høyde, minimumshøyde, minimumsbredde og bredde, klebrig posisjon, blokkmellomrom, marg og innvendig avstand, og linjehøyde. Bruk den når oppsettsarbeidet hører hjemme i editoren. La den være av, eller sett de enkelte nøklene, når avstand bare skal komme fra forhåndsinnstillinger.

#Hvordan Gutenberg gjør theme.json-presets om til CSS-variabler

Hver fargeslug i paletten blir en egendefinert egenskap --wp--preset--color--{slug} og hjelpeklasser som .has-{slug}-color og .has-{slug}-background-color. Skriftstørrelser og avstander følger --wp--preset--font-size--{slug} og --wp--preset--spacing--{slug}. Navngivningen står i den samme håndboken. Egen CSS i temaet bør bruke disse variablene, ikke et parallelt sett med --brand-primary-tokens som glir fra hverandre over tid.

Verdier som ikke har en egen preset-type, for eksempel skyggedybder eller hjørneradier du vil gi navn, legges under settings.custom. Håndboken beskriver at hver nøkkel der blir en --wp--custom--{key}-egenskap, der nøstede nøkler skjøtes med dobbel bindestrek. Et lite tokenark for eksemplet over ser slik ut i den genererte CSS-en:

/* Presets fra settings.color.palette og settings.typography.fontSizes */
--wp--preset--color--primary: #0b3d91;
--wp--preset--color--accent: #c2410c;
--wp--preset--font-size--large: 1.5rem;

/* Presets fra settings.spacing.spacingSizes */
--wp--preset--spacing--30: 1rem;
--wp--preset--spacing--40: 1.5rem;

/* Fra settings.custom: { "radius": { "card": "8px" } } */
--wp--custom--radius--card: 8px;

Det er hele historien om design tokens i Gutenberg. WordPress importerer ikke Tokens Studio. Den genererer presets fra theme.json. Har designteamet allerede tokens i JSON, er den ærlige løypa et byggesteg som skriver settings.color.palette (og skalaene for typografi og avstand) inn i theme.json. Deployen leverer da én fil. En webhook fra Figma som “pusher til produksjon” uten den skrivingen er en demo, ikke et system.

#Hvordan dele opp theme.json på et stort nettsted

Child-temaer slår sammen theme.json oppå foreldretemaet. Stilvarianter ligger som ekstra JSON-filer under /styles. PHP kan fortsatt endre treet med filteret wp_theme_json_data_theme når et nettsted i et nettverk trenger en annen primærfarge uten å forgreine temaet. Disse tre oppdelingene er det kjernen gir deg. Å kompilere tolv JSON-deler i en Node-oppgave er greit hvis teamet allerede eier den oppgaven. Det er ikke påkrevd, og det er ikke dokumentert som en funksjon i WordPress.

Når et team velger kompileringsveien, ser strukturen vanligvis slik ut:

theme/
├── theme.json            (generated, committed)
├── config/
│   ├── color.json
│   ├── typography.json
│   ├── spacing.json
│   └── custom.json
└── build-theme-json.js   (merges config/ into theme.json)

Design, utvikling og markedsføring kan da redigere hver sine filer uten flettekonflikter i ett stort JSON-dokument. Prisen er at flettescriptet blir kode noen må vedlikeholde, teste og oppgradere når skjemaet endres.

#Hvordan stilvarianter bytter palett uten ny CSS

En alternativ palett trenger ikke et nytt stilark. Kjerneveien er en stilvariant: en JSON-fil i /styles som definerer de samme slugene på nytt. Nettstedseieren velger den i nettstedsredigeringen under Stiler, og hver blokk som allerede bruker preset-variablene, følger med.

Stilvariant i /styles/dark.json:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "title": "Dark",
  "settings": {
    "color": {
      "palette": [
        { "slug": "base", "name": "Base", "color": "#111111" },
        { "slug": "contrast", "name": "Contrast", "color": "#f5f5f5" }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--base)",
      "text": "var(--wp--preset--color--contrast)"
    }
  }
}

Varianten beholder slug-navnene og endrer bare verdiene. Det er regelen som får det til å fungere: blokker lagrer slugen, ikke hex-verdien. En automatisk bryter mellom lyst og mørkt basert på prefers-color-scheme følger ikke med kjernen. Den CSS-en skriver du fortsatt selv.

Siden WordPress 6.6 tar den samme mappen også imot varianter som bare gjelder farger eller bare typografi, ifølge Developer Blog-innlegget om blokkstilvarianter. For en gruppe merkevarer på én kodebase gir det en ryddig oppdeling: felles avstand og oppsett i hovedfilen theme.json, og én variantfil per merkevarepalett.

#Hvordan seksjonsstiler fungerer i theme.json siden WordPress 6.6

Før 6.6 betydde en egen blokkstil, for eksempel “Boxed” på en Pullquote, en CSS-klasse pluss håndskrevet CSS. WordPress 6.3 hadde bare latt theme.json redigere blokkstilene som kjernen registrerer. I Developer Blog-innlegget fra juni 2024 forklarer Justin Tadlock at WordPress 6.6 lar deg style enhver registrert blokkstilvariant i theme.json, under styles.blocks.{block}.variations.{name}, inkludert elementene og blokkene som ligger nøstet inni den. Det samme innlegget beskriver “seksjonsstiler” (section styles) som et begrep introdusert i 6.6: en blokkstilvariant brukt på en seksjon, sammen med de nøstede elementene og blokkene den gir ny stil.

En seksjonsstil kan registreres fra en JSON-fil i /styles (WordPress leter også i undermapper, så /styles/section/ fungerer). Nøkkelen blockTypes lister blokkene den gjelder for:

{
  "$schema": "https://schemas.wp.org/wp/6.6/theme.json",
  "version": 3,
  "slug": "section-dark",
  "title": "Dark section",
  "blockTypes": [ "core/group", "core/columns" ],
  "styles": {
    "color": {
      "background": "var:preset|color|contrast",
      "text": "var:preset|color|base"
    },
    "elements": {
      "link": {
        "color": { "text": "var:preset|color|accent" }
      }
    }
  }
}

Den samme varianten kan registreres i PHP. I 6.6 tar register_block_style() imot en liste med blokknavn som første argument, og en style_data-nøkkel med samme struktur som JSON-filen:

register_block_style(
	array( 'core/group', 'core/columns' ),
	array(
		'name'       => 'section-dark',
		'label'      => __( 'Dark section', 'themeslug' ),
		'style_data' => array(
			'color' => array(
				'background' => 'var:preset|color|contrast',
				'text'       => 'var:preset|color|base',
			),
		),
	)
);

For et designsystem erstatter dette den vanligste kilden til avvik: redaktører som velger bakgrunns- og tekstfarge for hånd på hver Group-blokk. Med seksjonsstiler velger de “Dark section” i stilpanelet, og kombinasjonen av bakgrunn, tekst og lenkefarge kommer fra én definisjon. En global stilvariant kan så justere den seksjonen gjennom egenskapen styles.variations på toppnivå, slik at en merkevarevariant endrer den mørke seksjonen sammen med alt annet. Innlegget nevner også en begrensning verdt å huske: seksjonsstiler fungerer best på containerblokker som Group, Columns og Cover.

#Temamønstre mot synkroniserte mønstre i WordPress

Dette er skillet som brenner prosjekter.

Innledningen om mønstre i Theme Handbook sier det rett ut: mønstre du legger i /patterns, er ikke synkronisert. De er maler for neste innsetting. WordPress kopierer blokkmarkeringen inn i innlegget. Endrer du PHP-filen senere, endres ikke eksisterende sider. Den samme håndboken legger til at synkroniserte mønstre bare kan opprettes og administreres fra WordPress-administrasjonen.

Synkroniserte mønstre (gjenbrukbare blokker før WordPress 6.3) er wp_block-innlegg i databasen. Du lager dem i editoren. Alle forekomster holdes helt i takt. Disse objektene ligger ikke i Git. Staging og produksjon trenger hver sin identiske wp_block-rad, ellers må du gjenskape dem for hånd.

Bruk den oppdelingen med vilje:

Heroer, oppsett for kundecaser og skjeletter for landingssider hører hjemme i /patterns. En juridisk ansvarsfraskrivelse, en linje om informasjonskapsler eller et banner som juristene kan skrive om i ettermiddag, hører hjemme i et synkronisert mønster, med en dokumentert eksport slik at staging ikke blir en overraskelse.

Registrer temamønstre ved å legge en PHP-fil med filheader i /patterns, som er veien kapitlet om registrering av mønstre anbefaler, eller ved å kalle register_block_pattern() på init. Ett mønster, én metode. Ikke registrer samme slug to ganger.

I praksis har et mønsterbibliotek to lag. Små seksjonsmønstre er byggeklossene: en hero med overskrift, ingress, knapp og bilde, et tjenestekort med ikon, tittel, tekst og lenke, en anbefaling med bilde, sitat, navn og rolle, et banner med handlingsoppfordring. Helsidemønstre kombinerer dem til sidetypene markedsavdelingen lager gang på gang: en landingsside for en tjeneste, en kundecase, en teamside, en kontaktside. Redaktørene velger et helsidemønster og bytter ut eksempelteksten, slik at en ny side starter innenfor merkevarereglene i stedet for på et tomt lerret.

Synkroniserte mønstre fortjener plassen sin for innhold som må endres overalt samme dag: juridiske merknader, samtykkelinjer, blokker med firmaadresse og telefonnummer, handlingsoppfordringen i den aktuelle kampanjen.

#Hvordan mønsteroverstyringer og Block Bindings API kobler innhold

Et synkronisert mønster var tidligere alt eller ingenting: enten var alle forekomster identiske, eller så koblet du det løs og mistet synkroniseringen. WordPress 6.6 la til overstyringer i synkroniserte mønstre. I Nick Diegos gjennomgang på Developer Blog beholder et kort det felles designet, mens hver forekomst endrer overskrift, tekst og knapp. I editoren åpner du det synkroniserte mønsteret med “Edit original”, velger en blokk, klikker “Enable overrides” i panelet Avansert i blokkinspektøren og gir blokken et unikt navn. Blokkmarkeringen får da en binding til kilden core/pattern-overrides.

Overstyringer bygger på to eldre mekanismer. Redigering av bare innhold, introdusert i WordPress 6.1, er templateLock: "contentOnly" på en containerblokk: bare nøstet tekst og media kan fortsatt redigeres, og inspektørkontrollene for innstillinger og stiler er deaktivert. Den andre er Block Bindings API, tilgjengelig siden WordPress 6.5, som kobler et blokkattributt til en datakilde i stedet for til statisk innhold.

Håndboken lister hvilke kjerneblokker og attributter som tar imot bindinger som standard:

De innebygde kildene er core/post-meta (metanøkkelen må registreres med show_in_rest og kan ikke begynne med understrek), core/pattern-overrides og, siden WordPress 6.9, core/post-data (dato, endringsdato og lenke) og core/term-data. En plugin kan legge til sin egen kilde med register_block_bindings_source() på init, med en label, en valgfri uses_context-liste og en get_value_callback. Selve bindingen ligger i blokkens metadata:

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"product_sku"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

For et designsystem er dette måten et mønster forblir et mønster mens dataene kommer fra strukturerte felt. Et produktkortmønster kan binde SKU-avsnittet sitt til post meta, slik at redaktørene aldri skriver det inn i oppsettet. To begrensninger fra håndboken er viktige her. Registrering på editorsiden med registerBlockBindingsSource() kom i 6.7, og en bundet verdi kan ikke redigeres i editoren med mindre kilden tilbyr canUserEditValue. Innlegget om overstyringer påpekte også, per juni 2024, at synkroniserte mønstre bare lagres i databasen og ikke kan pakkes som mønsterfiler i et tema, og at de første utforskningene av dette følges i en Gutenberg-issue.

#Hvordan versjonere temamønstre med Git

WordPress versjonerer ikke mønstre: det finnes ingen tilstander, ingen godkjenninger og ingen automatisk migrering av forekomster som allerede er satt inn. Det som finnes, er Git på mappen /patterns, og teamet bestemmer syklusen selv:

1. Utkast: det nye mønsteret ligger på en gren.
2. Gjennomgang: merkevare- eller juridisk ansvarlig godkjenner det i pull requesten.
3. Publisert: det er deployet og vises i blokkinnsetteren.
4. Pensjonert: det fjernes fra innsetteren ved å slette filen eller kallet til register_block_pattern(). Sider som allerede har satt det inn, beholder markeringen sin, og dem må du gå gjennom én etter én.

Steg fire er grunnen til å holde mønstersettet kort. Hvert mønster du publiserer, etterlater kopier i innholdet som temaet ikke lenger når.

#Hvordan låse Gutenberg-maler med templateLock

En palett med custom: false svikter likevel hvis sidemalen er en tom Group og innsetteren tilbyr alle kjerneblokker. For sidetyper som må holde seg til modellen (produkt, lokasjon, dokumentasjon), låser du malen: allowedBlocks på gruppen, templateLock: "insert" eller "all" der oppsettet ikke skal omorganiseres, og et mønster som standardinnhold, slik at redaktøren aldri starter fra et tomt lerret.

Referansen for blokkmaler definerer verdiene. all hindrer innsetting, flytting og sletting av blokker. insert hindrer innsetting og fjerning av blokker, men tillater flytting av eksisterende. contentOnly hindrer alle operasjoner, skjuler blokker uten innhold fra listevisningen og kan ikke overstyres av underordnede blokker. Group-blokken deklarerer templateLock som attributt i sin block.json, så låsen kan ligge direkte i markeringen til en mal eller et mønster.

Det finnes to nivåer til. En enkelt blokk kan ha et lock-attributt med flaggene move og remove, og referansen sier at låsen på blokknivå har forrang foran templateLock. En egen innleggstype kan registrere sin egen template-liste og en template_lock i register_post_type(), slik at hvert nye produkt starter fra den samme blokkstrukturen.

Inne i en egen blokk gjelder den samme låsen for de indre blokkene:

<InnerBlocks
	template={ TEMPLATE }
	templateLock="all"
	allowedBlocks={ [ 'core/heading', 'core/paragraph', 'core/button' ] }
/>

Redaktørene kan fortsatt endre tekst og bilder, men de kan ikke flytte, fjerne eller legge til blokker utenfor den definerte strukturen.

#Når lønner det seg å bygge en egen Gutenberg-blokk med block.json

Det er også her egne blokker gjør seg fortjent. Kjerneblokkene Heading, Paragraph og Image dekker de fleste markedsmoduler. En sammenligningstabell som må bære en SKU, en valuta og en dato for “sist verifisert”, trenger attributter og validering i block.json. Slike bygger vi med @wordpress/scripts, holder save-markeringen kjedelig og nekter å gjenskape en sidebygger inne i inspektøren. Er blokken bare et skall rundt indre blokker, velg heller et mønster.

En blokkmappe i designsystemets repository ser slik ut:

blocks/
└── product-comparison/
    ├── block.json
    ├── edit.js       (editor UI)
    ├── save.js       (front-end markup)
    ├── style.scss    (front-end and editor styles)
    └── editor.scss   (editor-only styles)

Referansen for blokkmetadata bruker "apiVersion": 3 i eksemplet sitt. Vit hvor valideringen i block.json stopper. Referansen for attributter sier at hver attributtdefinisjon inneholder minst en type eller en enum, pluss hvor verdien leses fra. enum begrenser den lagrede verdien. Det finnes ingen maxLength, minimum eller maximum som Gutenberg håndhever for deg:

{
  "apiVersion": 3,
  "name": "wppoland/product-comparison",
  "attributes": {
    "heading": { "type": "string", "default": "" },
    "price": { "type": "number", "default": 0 },
    "variant": {
      "type": "string",
      "enum": [ "primary", "secondary", "accent" ],
      "default": "primary"
    }
  }
}

Grenser for verdiområde og lengde legges i edit-komponenten eller i REST-valideringen ved lagring:

<RichText
	tagName="h3"
	value={ attributes.heading }
	onChange={ ( heading ) => setAttributes( { heading: heading.slice( 0, 120 ) } ) }
/>

Referansen for @wordpress/scripts dekker resten av verktøykjeden fra én avhengighet. build lager en produksjonsbundle, og start bygger på nytt ved hver endring. lint-js og lint-style bruker WordPress-kodestandardene på skript og stilark. test-e2e kjører ende-til-ende-tester med Playwright, og plugin-zip pakker pluginen. Den samme pakken finner block.json-filer i kildemappen og bruker dem som inngangspunkter, så en ny blokkmappe krever ingen endring i webpack.

#Hvordan bruke Storybook for UI-komponenter i Gutenberg

Gutenberg-prosjektet dokumenterer selv UI-komponentene sine i Storybook. README-filen i storybook-mappen i Gutenberg-repositoryet sier at prosjektet “bruker Storybook til å vise og arbeide med UI-komponentene som utvikles i WordPress-pakkene” (egen oversettelse), publiserer resultatet på wordpress.github.io/gutenberg og kjøres lokalt med npm run storybook:dev fra roten av repositoryet.

To fremgangsmåter fra den README-filen lar seg godt overføre til et designsystem for en kunde. Hver komponentside oppgir en status (recommended, use-with-caution, not-recommended eller unaudited) som vises i sidefeltet, slik at utviklerne ser hvilke komponenter som er trygge å bygge videre på. Og repositoryet committer et manifest-øyeblikksbilde av alle komponenter og deres props: en pull request som fjerner en prop-beskrivelse, feiler til noen bekrefter endringen.

Det Storybook ikke dekker, er innholdslaget. Mønstre, theme.json-presets og seksjonsstiler rendres inne i blokkeditoren, så den pålitelige forhåndsvisningen for dem er en side på et staging-nettsted som setter inn alle mønstrene, redigert med en redaktørkonto. Storybook passer for React-delene av systemet: edit-komponentene i egne blokker og eventuelle felles sidefeltkontroller bygget med @wordpress/components, som er biblioteket den offentlige Storybook-en dokumenterer.

#Hvordan flytte Figma-tokens inn i theme.json

Det finnes ingen offisiell synkronisering mellom Figma og WordPress. Kjernen leser ikke Figma-filer, og ingen Figma-plugin skriver til et produksjonsnettsted på egen hånd. Det du kan bygge, er et byggesteg: tokens forlater designverktøyet som JSON, og et script skriver dem inn i theme.json, som er det deployen leverer.

Navnene stemmer nesten aldri overens i starten, så den koblingen er kode noen må vedlikeholde. En arbeidsflyt som holder:

1. Designeren endrer en farge i Figma.
2. En token-plugin eksporterer de oppdaterte tokenene som JSON.
3. CI kjører byggescriptet, som skriver om settings.color.palette i theme.json.
4. Visuelle regresjonstester sammenligner skjermbilder før og etter.
5. Et menneske leser diffen i theme.json og godkjenner pull requesten.

Stopp automatiseringen ved steg fem. En webhook som deployer til produksjon uten at noen leser diffen, er en demo, ikke et system. En merkevarefarge er nettopp den typen endring som fortjener en menneskelig gjennomgang.

Dokumentasjonen kan komme nesten gratis fra materiale som allerede finnes: en side på nettstedet som setter inn alle mønstrene i biblioteket, Git-historikken for /patterns og theme.json som endringslogg, og skjermbildene fra de visuelle testene som dokumentasjon av før og etter.

#Hvordan sjekke tilgjengelighet i et designsystem for WordPress

Ingenting av dette gjør WordPress for deg. Dette er kontroller du bygger rundt temaet.

Paletten er en kort liste med hex-verdier i en JSON-fil, så kontrasten kan sjekkes i bygget. En test går gjennom de tillatte parene av tekst og bakgrunn, beregner WCAG-forholdet og stopper bygget når et par faller under 4.5:1 for vanlig tekst. Den navngir den feilende kombinasjonen med slug, ikke hex, slik at rettelsen havner i theme.json. Blokkeditoren varsler allerede i inspektøren når en valgt fargekombinasjon har lav kontrast, men varselet hindrer ikke publisering. Seksjonsstiler hjelper her: når paret av bakgrunn og tekst er definert én gang i en seksjonsstil, testes det én gang.

I CI kjører du axe-core mot hovedmalene og hver publiserte stilvariant, og legger til tester for tastaturnavigasjon for mønstrene som inneholder interaktive elementer. Husk begrensningen: automatiske verktøy fanger bare en del av WCAG-kriteriene. Resten er fortsatt en manuell gjennomgang med tastatur og skjermleser.

#Hvordan blokkressurser lastes ved behov i et blokktema

Et dårlig bygget designsystem kan være tregere enn et håndkodet nettsted, fordi hvert mønster drar med seg sin egen CSS. Kjernen hjelper hvis du lar den. I _add_default_theme_supports(), som kjører for blokktemaer, legger WordPress til både should_load_separate_core_block_assets og should_load_block_assets_on_demand som __return_true-filtre (se wp-includes/theme.php i wordpress-develop). Docblocken i script-loader.php beskriver effekten: blokkressurser lastes bare når blokken rendres. Et klassisk tema slår det på med:

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

En side uten galleri laster da ikke galleriets CSS. For egne blokker følger en praktisk regel av dette: deklarer style, editorStyle, viewScript eller viewScriptModule i block.json i stedet for å laste filer globalt fra functions.php, slik at WordPress kan laste dem bare der blokken vises. Det WordPress ikke gjør, er å generere kritisk CSS eller fjerne ubrukte regler. Det er fortsatt jobben til bygget ditt eller et cachelag.

Budsjetter per komponent er en beslutning teamet tar, ikke en måling i kjernen, og de fungerer bare hvis noen sjekker dem i hver pull request. Den billigste gevinsten er ofte å slippe skript helt: et FAQ-trekkspill bygget på Details-blokken gir <details> og <summary>, som åpnes og lukkes uten JavaScript og fungerer med tastaturet.

#Sjekkliste for et skalerbart designsystem i WordPress

I utviklingsarbeid med WordPress er rekkefølgen den samme hver gang:

1. Tokens i theme.json versjon 3, velgeren låst, kjernens palett skjult.
2. Seksjonsstiler for parene av bakgrunn og tekst, slik at redaktørene slutter å fargelegge Group-blokker for hånd.
3. Et kort mønstersett i /patterns for oppsettene markedsavdelingen faktisk gjentar.
4. Ett eller to synkroniserte mønstre for tekst som juristene eier, eksportert sammen med innholdssynkroniseringen, aldri overlatt til “vi gjenskaper det i produksjon”.
5. Egne blokker først når et mønster på kjerneblokker har strandet på et reelt krav til attributter.
6. En gjennomgang i nettstedsredigeringen med en redaktørkonto, ikke en administratorkonto, fordi administratorer fortsatt ser verktøy du trodde du hadde skjult.

Bruker forsiden allerede utility-CSS, beholder du theme.json som kilde for tokens og kobler slugene inn i den CSS-en. Vi har beskrevet den oppdelingen for Tailwind i Tailwind CSS i WordPress-utvikling. Gutenberg bryr seg ikke om hvilket CSS-rammeverk som bruker --wp--preset--color--primary. Det som teller, er at editoren og forsiden bruker samme slug.

Systemet fungerer når en ny landingsside er en mønsterinnsetting, fargevelgeren har åtte fargeprøver, og en forespørsel om “bare denne ene oransjefargen” blir en pull request mot theme.json, ikke en hex-verdi i en Group-blokk.

Planlegger du et designsystem i WordPress? Skriv til oss.