Legge til forelder-side-slug i body-klasser (WordPress-snutt)

#Begrensninger i standard body_class i WordPress

I klassiske temaer og blokktemaer genererer body_class() en liste over klasser basert på gjeldende spørring. Når en bruker besøker en underside som ligger under stien /tjenester/sky/databaser/, produserer WordPress standard HTML-kode tilsvarende dette:

<body class="page-template-default page page-id-342 page-child parent-pageid-108 logged-in wp-custom-logo">

Selv om denne koden bekrefter at siden er en underside, avslører en teknisk inspeksjon tre tydelige svakheter:

1. Skjørhet ved migrering mellom miljøer: Klassen parent-pageid-108 knytter stilarket direkte til en autoinkrementell ID i MySQL-databasen. Når innhold overføres mellom lokalt utviklingsmiljø (Docker), testserver (staging) og produksjon, endres ofte disse ID-ene. En regel rettet mot .parent-pageid-108 slutter å fungere i det øyeblikket databasen synkroniseres på nytt.
2. Mangel på dypere hierarkisk kontekst: WordPress analyserer bare den direkte forelderen via parent-pageid-{ID}. Hvis nettstedet har tre nivåer, forsvinner informasjonen om rotsiden /tjenester/ fullstendig. Å style en hel avdeling krever at du manuelt lister opp hver eneste numeriske underside-ID i CSS-filen.
3. Dårlig lesbarhet i stilark og vedlikehold: Semantiske klasser som .parent-tjenester eller .ancestor-tjenester forklarer umiddelbart hva koden gjør. Numeriske selektorer krever at utviklere slår opp i databasen for å forstå hvilken seksjon regelen påvirker.

Å skrive stilark basert på tilfeldige tall skaper unødvendig arbeid:

/* Dårlig praksis: Krever manuell oppdatering for hver ny underside */
.page-id-342 .site-header,
.page-id-343 .site-header,
.page-id-344 .site-header {
    background-color: #0b2545;
}

Når redaktører oppretter en ny underside under samme avdeling, mangler den nødvendig styling frem til en utvikler oppdaterer CSS-koden. Ved å berike body-klassen med overordnede slugs løses dette automatisk.

#Bygge et body_class-filter med get_post_ancestors

For å overstyre standardoppførselen kobler vi oss på filteret body_class. Dette filteret mottar en matrise med genererte klassenavn og forventer en returnert, modifisert matrise.

I stedet for å skrive egne SQL-spørringer eller manuelle pumper mot databasen, bruker vi kjernefunksjonen get_post_ancestors(). Funksjonen tar imot en side-ID eller et WP_Post-objekt og returnerer en ordnet liste med forfedre-ID-er fra direkte forelder opp til seksjonsroten.

Her er den komplette kodesnutten som kan plasseres i et underordnet temas functions.php eller som en frittstående mu-plugin:

<?php
/**
 * Plugin Name: WPPoland Hierarkiske Body-klasser
 * Description: Tilfører rensede slugs for gjeldende side, direkte forelder og alle forfedre i body_class.
 * Version:     1.2.0
 * Author:      WPPoland
 */

declare(strict_types=1);

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

/**
 * Legger til hierarkiske slug-klasser i body-klasselisten.
 *
 * Støtter ordinære hierarkiske sider og hierarkiske egendefinerte innleggstyper (CPT).
 *
 * @param array<string> $classes Eksisterende klasser generert av WordPress.
 * @return array<string> Rensed og deduplisert klasseliste.
 */
function wppoland_legg_til_hierarkiske_body_klasser( array $classes ): array {
    // Kjør kun på enkeltvisninger for sider og innlegg
    if ( ! is_singular() ) {
        return $classes;
    }

    $queried_id = get_queried_object_id();
    if ( ! $queried_id ) {
        return $classes;
    }

    $current_post = get_post( $queried_id );
    if ( ! ( $current_post instanceof \WP_Post ) ) {
        return $classes;
    }

    // 1. Legg til gjeldende sides slug med prefiks
    if ( ! empty( $current_post->post_name ) ) {
        $classes[] = sanitize_html_class( 'page-slug-' . $current_post->post_name );
    }

    // 2. Behandle hierarki kun for hierarkiske innleggstyper med en forelder
    if ( is_post_type_hierarchical( $current_post->post_type ) && $current_post->post_parent > 0 ) {
        // Direkte forelderside
        $parent_post = get_post( $current_post->post_parent );
        if ( $parent_post instanceof \WP_Post && ! empty( $parent_post->post_name ) ) {
            $classes[] = sanitize_html_class( 'parent-' . $parent_post->post_name );
        }

        // Hent alle forfedre i treet (forelder, besteforelder, tippoldefar)
        $ancestor_ids = get_post_ancestors( $queried_id );
        if ( ! empty( $ancestor_ids ) && is_array( $ancestor_ids ) ) {
            foreach ( $ancestor_ids as $ancestor_id ) {
                $ancestor_post = get_post( $ancestor_id );
                if ( $ancestor_post instanceof \WP_Post && ! empty( $ancestor_post->post_name ) ) {
                    $classes[] = sanitize_html_class( 'ancestor-' . $ancestor_post->post_name );
                }
            }

            // Merk rotforfedren eksplisitt
            $root_id = end( $ancestor_ids );
            if ( $root_id && $root_id !== $current_post->post_parent ) {
                $root_post = get_post( $root_id );
                if ( $root_post instanceof \WP_Post && ! empty( $root_post->post_name ) ) {
                    $classes[] = sanitize_html_class( 'section-root-' . $root_post->post_name );
                }
            }
        }
    }

    // 3. Valgfri klasse for malnavn dersom tilpasset sidemal benyttes
    $template_slug = get_page_template_slug( $current_post->ID );
    if ( ! empty( $template_slug ) && is_string( $template_slug ) ) {
        $clean_template = str_replace( array( '.php', '.html' ), '', basename( $template_slug ) );
        $classes[]      = sanitize_html_class( 'template-' . $clean_template );
    }

    // Returner unike og rensede klasser
    return array_values( array_unique( array_filter( $classes ) ) );
}
add_filter( 'body_class', 'wppoland_legg_til_hierarkiske_body_klasser', 10, 1 );

#Resultat i HTML-koden med forelder- og aneklasser

For å se hva denne endringen betyr i praksis, kan vi ta for oss en struktur i tre nivåer:

• /tjenester/ (Rotside, ID 40)
• /tjenester/radgivning/ (Mellomliggende forelder, ID 112)
• /tjenester/radgivning/sikkerhetsrevisjon/ (Aktiv underside, ID 285)

Når nettleseren laster inn siden /tjenester/radgivning/sikkerhetsrevisjon/, kjører koden get_post_ancestors(285). Funksjonen returnerer matrisen [112, 40].

I den resulterende HTML-kilden vil <body>-taggen inneholde følgende semantiske klasser:

<body class="page-template-default page page-id-285 page-child parent-pageid-112 page-slug-sikkerhetsrevisjon parent-radgivning ancestor-radgivning ancestor-tjenester section-root-tjenester">

Disse klassene gir full frihet i CSS:

• page-slug-sikkerhetsrevisjon: Gjør det mulig å isolere stiler for akkurat denne spesifikke siden uten numerisk ID.
• parent-radgivning: Treffer alle direkte undersider av rådgivningssiden.
• ancestor-radgivning: Påvirker undersider på alle dypere nivåer under rådgivning.
• ancestor-tjenester: Dekker samtlige undersider i hele tjenesteavdelingen.
• section-root-tjenester: Angir seksjonens øverste rot, nyttig for overordnede designtemaer.

#Praktisk bruk av forelderklasser i CSS og SCSS

Med meningsfulle klasser på plass kan stilarket organiseres modulært. Du unngår repetisjon og holder koden ryddig.

#Eksempel 1: Fargeprofiler per seksjon med CSS-variabler

En ren metode for å styre seksjonsfarger er å overstyre CSS-variabler på body-elementet:

/* Globale fargevariabler */
:root {
    --theme-accent: #2563eb;
    --theme-surface-subtle: #f8fafc;
    --theme-header-border: #e2e8f0;
}

/* Seksjonsfarger for Tjenester */
body.ancestor-tjenester {
    --theme-accent: #0284c7;
    --theme-surface-subtle: #f0f9ff;
    --theme-header-border: #bae6fd;
}

/* Eget fargetema for Rådgivning */
body.parent-radgivning {
    --theme-accent: #4f46e5;
    --theme-surface-subtle: #eef2ff;
    --theme-header-border: #c7d2fe;
}

/* Grønt designtema for Dokumentasjon */
body.ancestor-dokumentasjon {
    --theme-accent: #059669;
    --theme-surface-subtle: #ecfdf5;
    --theme-header-border: #a7f3d0;
}

Komponenter på siden bruker bare var(--theme-accent). Når klassen på body endres, tilpasser alle knapper, rammer og lenker seg automatisk.

#Eksempel 2: Endring av rutenett og sidespalte

Ulike seksjoner krever ofte ulik bredde. For eksempel kan dokumentasjonssider trenge full bredde med en fast innholdsfortegnelse, mens vanlige sider har en sentrert kolonne:

/* Standard innholdsbredde */
.site-main .content-container {
    max-width: 840px;
    margin: 0 auto;
    padding: 3rem 1.5rem;
}

/* Utvidet rutenett for teknisk dokumentasjon */
body.ancestor-dokumentasjon .site-main .content-container {
    max-width: 1400px;
    display: grid;
    grid-template-columns: 280px 1fr;
    gap: 3rem;
    padding: 2rem;
}

/* Skjul nyhetsbrev-skjemaer på juridiske sider */
body.ancestor-juridisk .site-footer .newsletter-cta,
body.ancestor-personvern .site-footer .newsletter-cta {
    display: none;
}

#Eksempel 3: Organisering i SCSS

I prosjekter som benytter Sass/SCSS, kan overordnede regler nøstes ryddig ved hjelp av ampersand-selektoren:

.main-navigation {
    display: flex;
    align-items: center;

    .nav-item {
        color: #334155;
        font-weight: 500;

        // Markere aktiv menypost for hele seksjonen
        body.ancestor-tjenester &--tjenester {
            color: var(--theme-accent);
            border-bottom: 2px solid var(--theme-accent);
        }

        body.ancestor-kundecaser &--kundecaser {
            color: var(--theme-accent);
            border-bottom: 2px solid var(--theme-accent);
        }
    }
}

#Spesifisitet i CSS med forelderklasser og pseudoklasser

Når du fester regler til body-elementet, som body.ancestor-tjenester, har selektoren en CSS-spesifisitet på (0, 1, 1). Dette kan i noen tilfeller overstyre komponentklasser utilsiktet.

#Nullstille spesifisitet med CSS where

Den moderne CSS-pseudoklassen :where() fjerner spesifisitet helt. Regler inni :where() teller som (0, 0, 0):

/* Null ekstra spesifisitet på seksjonsregelen */
:where(body.ancestor-tjenester) .hero-banner {
    background-color: #0369a1;
    color: #ffffff;
}

/* En vanlig verktøyklasse overstyrer enkelt regelen */
.hero-banner.is-style-light {
    background-color: #f8fafc;
    color: #0f172a;
}

Dette gjør det enkelt å sette seksjonsstandarder uten å blokkere redaktørers valg i blokkeditoren Gutenberg.

#Slå sammen seksjonsregler med CSS is

Dersom flere seksjoner skal dele samme utseende, kan du samle dem effektivt med :is():

/* Felles skygge for topptekst i tre ulike seksjoner */
body:is(.ancestor-tjenester, .ancestor-produkter, .ancestor-portefolje) .site-header {
    box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.08);
}

Dette holder stilarket kort og reduserer kodevolumet.

#Blokktemaer og FSE-støtte i WordPress 6.6 og nyere

Blokktemaer (Full Site Editing) har endret måten maler bygges på, men PHP-filtrene i kjernen fungerer som før.

#Hvordan blokktemaer behandler body-taggen

I klassiske temaer kaller header.php eksplisitt <?php body_class(); ?>. I blokktemaer er malfilene rene HTML-filer (som templates/page.html).

Under oppbyggingen av siden kaller WordPress automatisk den interne hjelpefunksjonen get_body_class(). Filteret body_class kjøres som normalt, og de ferdige klassene skrives ut på <body>-elementet før siden sendes til nettleseren. Koden vår fungerer derfor like godt i moderne blokktemaer i WordPress 6.6, 6.7 og nyere.

#Samspill med theme.json

Konfigurasjonsfilen theme.json inneholder farger og typografi, men støtter ikke logikk for URL-stier. Du kobler disse sammen ved å definere fargepaletten i theme.json mot CSS-variabler:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        {
          "slug": "seksjonsaksent",
          "color": "var(--theme-accent, #2563eb)",
          "name": "Seksjonsaksent"
        }
      ]
    }
  }
}

Når en redaktør velger fargen “Seksjonsaksent” på en blokk, henter blokken fargen fra variabelen som er satt på body-elementet.

#Støtte for hierarkiske egendefinerte innleggstyper (CPT)

Mange nettsteder lagrer strukturert innhold i egne innleggstyper, for eksempel dokumentasjon (docs) eller kurssider (kurs). For at snutten skal fungere med disse, må innleggstypen registreres med hierarkistøtte:

register_post_type( 'dokumentasjon', array(
    'labels'       => array( 'name' => 'Dokumentasjon' ),
    'public'       => true,
    'has_archive'  => true,
    'hierarchical' => true, // Nødvendig for at post_parent skal fungere
    'supports'     => array( 'title', 'editor', 'page-attributes' ),
    'rewrite'      => array( 'slug' => 'dokumentasjon', 'hierarchical' => true ),
) );

Funksjonen vår sjekker is_post_type_hierarchical( $current_post->post_type ). Dermed ignoreres vanlige innlegg, mens hierarkiske typer automatisk får parent- og ancestor--klasser.

#Ytelse og hurtigbufring av forfedre ved dype sidetrær

På vanlige nettsteder gir get_post_ancestors() nesten ingen merkbar belastning, ettersom WordPress hurtigbuffer objekter i minnet under hovedspørringen.

På store bedriftsnettsteder med mange besøkende og hierarkier på fem eller flere nivåer, kan det likevel lønne seg å lagre resultatet i objektbufferen:

/**
 * Hurtigbufret filter for hierarkiske body-klasser.
 *
 * @param array<string> $classes Eksisterende klasser.
 * @return array<string> Beriket klasseliste.
 */
function wppoland_bufret_hierarkiske_body_klasser( array $classes ): array {
    if ( ! is_singular() ) {
        return $classes;
    }

    $post_id = get_queried_object_id();
    if ( ! $post_id ) {
        return $classes;
    }

    $cache_group = 'wppoland_body_klasser';
    $cache_key   = 'slugs_' . $post_id;

    $cached_additions = wp_cache_get( $cache_key, $cache_group );

    if ( false === $cached_additions || ! is_array( $cached_additions ) ) {
        $cached_additions = array();
        $post             = get_post( $post_id );

        if ( $post instanceof \WP_Post ) {
            if ( ! empty( $post->post_name ) ) {
                $cached_additions[] = sanitize_html_class( 'page-slug-' . $post->post_name );
            }

            if ( is_post_type_hierarchical( $post->post_type ) && $post->post_parent > 0 ) {
                $ancestors = get_post_ancestors( $post_id );
                foreach ( $ancestors as $ancestor_id ) {
                    $ancestor = get_post( $ancestor_id );
                    if ( $ancestor instanceof \WP_Post && ! empty( $ancestor->post_name ) ) {
                        $cached_additions[] = sanitize_html_class( 'ancestor-' . $ancestor->post_name );
                    }
                }

                $parent = get_post( $post->post_parent );
                if ( $parent instanceof \WP_Post && ! empty( $parent->post_name ) ) {
                    $cached_additions[] = sanitize_html_class( 'parent-' . $parent->post_name );
                }
            }
        }

        // Lagre i hurtigbuffer i 12 timer
        wp_cache_set( $cache_key, $cached_additions, $cache_group, 43200 );
    }

    return array_values( array_unique( array_merge( $classes, $cached_additions ) ) );
}
add_filter( 'body_class', 'wppoland_bufret_hierarkiske_body_klasser', 10, 1 );

/**
 * Tømmer hurtigbufferen når en side oppdateres.
 *
 * @param int $post_id Oppdatert side-ID.
 */
function wppoland_tom_body_klasse_buffer( int $post_id ): void {
    wp_cache_delete( 'slugs_' . $post_id, 'wppoland_body_klasser' );
}
add_action( 'save_post', 'wppoland_tom_body_klasse_buffer' );

Dette sikrer at oppslagene kun gjøres én gang per side, noe som sparer prosessorkraft ved høy trafikk.

#Renslighet og sikkerhet med sanitize_html_class

Når dynamiske strenger fra databasen legges til i HTML-attributter, må de renses grundig:

1. Obligatorisk bruk av sanitize_html_class(): Funksjonen fjerner ugyldige tegn og mellomrom, slik at HTML-strukturen ikke ødelegges.
2. Slugs som starter med tall: CSS tillater ikke klasseidentifikatorer som starter med et siffer uten spesiell escaping. Prefikser som parent- eller ancestor- sikrer at klassenavnet alltid starter med en bokstav, selv om siden heter 2026-rapport.
3. Validering mot WP_Post: Ved å bekrefte at get_post() returnerer et gyldig objekt unngår vi PHP-feil dersom en foreldreside skulle være slettet fra databasen.

#Automatisk testing av hierarkiske body-klasser i CI/CD

På store bedriftsnettsteder som forvaltes i Git med automatiserte distribusjonsløp, er det viktig å sikre at endringer i kildekoden ikke ødelegger de semantiske CSS-klassene. En regresjonstest i PHPUnit eller Pest verifiserer at filteret alltid leverer forventede verdier for både foreldre, besteforeldre og vanlige innlegg.

#Eksempel på enhetstest i PHPUnit

Følgende testklasse viser hvordan du kan teste hierarkiske body-klasser i et lokalt testmiljø:

<?php
/**
 * Testklasse for verifisering av hierarkiske body-klasser.
 */
namespace WPPoland\Tester;

use WP_UnitTestCase;

class TestHierarkiskeBodyKlasser extends WP_UnitTestCase {

    public function test_hierarkiske_klasser_legges_til_korrekt(): void {
        // Opprett en overordnet rotside
        $parent_id = $this->factory->post->create( array(
            'post_type'  => 'page',
            'post_title' => 'Bedriftstjenester',
            'post_name'  => 'bedriftstjenester',
        ) );

        // Opprett en underside tilknyttet foreldersiden
        $child_id = $this->factory->post->create( array(
            'post_type'   => 'page',
            'post_title'  => 'Sikkerhetsrevisjon',
            'post_name'   => 'sikkerhetsrevisjon',
            'post_parent' => $parent_id,
        ) );

        // Simuler at forespørselen går til undersiden
        $this->go_to( get_permalink( $child_id ) );

        $klasser = get_body_class();

        $this->assertContains( 'page-slug-sikkerhetsrevisjon', $klasser );
        $this->assertContains( 'parent-bedriftstjenester', $klasser );
        $this->assertContains( 'ancestor-bedriftstjenester', $klasser );
    }

    public function test_flate_innlegg_utelater_foreldreklasser(): void {
        // Et standard blogginnlegg skal ikke ha foreldreklasser
        $post_id = $this->factory->post->create( array(
            'post_type'  => 'post',
            'post_title' => 'Blogginnlegg',
            'post_name'  => 'blogginnlegg',
        ) );

        $this->go_to( get_permalink( $post_id ) );

        $klasser = get_body_class();

        $this->assertContains( 'page-slug-blogginnlegg', $klasser );

        $har_parent_klasse = false;
        foreach ( $klasser as $klasse ) {
            if ( str_starts_with( $klasse, 'parent-' ) ) {
                $har_parent_klasse = true;
                break;
            }
        }
        $this->assertFalse( $har_parent_klasse );
    }
}

Disse testene kjøres automatisk i GitHub Actions eller GitLab CI før koden rulles ut til produksjon, noe som forhindrer feil i grensesnittet.

#Strategi for migrering og opprydding i eldre stilark

Mange eldre WordPress-løsninger har opparbeidet seg hundrevis av linjer med CSS basert på numeriske selektorer som .page-id-12, .page-id-14 og .page-id-99. Å erstatte alle disse på én gang kan føre til utilsiktede feil hvis enkelte sider overses.

#Trygg overgang i tre steg

1. Introdusere nye klasser parallelt: Filteret vårt fjerner ikke standardklassene fra WordPress-kjernen. Begge klassetypene vil eksistere side om side i HTML-koden. Dette betyr at eksisterende stiler fortsetter å fungere nøyaktig som før uten nedetid eller visuelle avvik.
2. Trinnvis omskriving per avdeling: Ta for deg én seksjon av gangen, for eksempel tjenesteavdelingen. Erstatt reglene som ramser opp ti ulike side-ID-er med én enkelt semantisk regel: body.ancestor-tjenester. Dette slanker stilarket og gjør koden oversiktlig.
3. Visuell regresjonstesting: Bruk automatiserte verktøy som Playwright for å sammenligne skjermbilder av staging mot produksjon før og etter migreringen. Når du har bekreftet at alt ser identisk ut, kan de gamle numeriske selektorene slettes trygt fra kodelageret.

#Feilsøking når body-klassene ikke vises

Dersom de nye klassene ikke dukker opp i nettleseren etter implementering, kan du gå gjennom disse punktene:

1. Sjekk at body_class() kalles i malen: I eldre temaer må du kontrollere at header.php faktisk kaller funksjonen og ikke har en hardkodet <body>-tagg uten PHP-utkalling.
2. Filterrekkefølge og konflikter: Sjekk om andre tillegg overskriver listen. Prøv å øke prioriteten i add_filter til 20 eller 30 slik at din funksjon kjører sist.
3. Tøm hurtigbufferen: Tøm hurtigbufferen i tillegg som WP Rocket eller LiteSpeed, samt i eventuelle CDN-tjenester som Cloudflare. Statisk hurtigbufret HTML vil ikke vise nye klasser før den slettes.
4. Kun for enkeltvisninger: Filteret er avgrenset med is_singular(). Det er ikke ment for arkivsider, kategorilister eller bloggoversikter.

#Integrasjon med design tokens og CSS-rammeverk

I moderne front-end-utvikling struktureres stilark ofte rundt design tokens og CSS-rammeverk som Tailwind CSS eller egne modulære komponentbiblioteker. Når du kombinerer design tokens med semantiske body-klasser, oppnår du en arkitektur der hele nettstedet responderer på konteksten til gjeldende underside.

#Bruk av Tailwind CSS med overordnede klasser

Dersom prosjektet ditt bruker Tailwind CSS, kan du utnytte varianter og egendefinerte verktøyklasser for å tilpasse elementer basert på foreldersiden. Ved å konfigurere Tailwind til å lytte etter overordnede klasser på body, kan du skrive konsis utility-basert kode direkte i malene:

<!-- En informasjonsboks som automatisk tilpasser kantfargen etter seksjonen -->
<div class="rounded-lg p-6 bg-white border-l-4 border-slate-300
            [body.ancestor-tjenester_&]:border-sky-500
            [body.ancestor-dokumentasjon_&]:border-emerald-500
            [body.ancestor-sikkerhet_&]:border-rose-500">
    <h3 class="text-lg font-semibold text-slate-900">Viktig seksjonsinformasjon</h3>
    <p class="text-slate-600 mt-2">Dette innholdet arver aksentfargen dynamisk fra forelderens slug.</p>
</div>

Denne teknikken eliminerer behovet for egne PHP-betingelser i malfilene for å bytte ut CSS-klasser på komponentnivå. Nettleseren evaluerer reglene direkte basert på klassen i <body>.

#Bruk av semantiske klasser i klientside JavaScript og sporingsverktøy

Semantiske body-klasser er ikke bare verdifulle for CSS, men gir også et solid fundament for skript på klientsiden, hendelsessporing og analyse.

#Seksjonsbasert hendelsessporing med Google Tag Manager

I stedet for å parse URL-strukturen eller sende komplekse datalayer-objekter fra PHP, kan JavaScript enkelt lese av den aktive seksjonen direkte fra DOM:

// Les av aktive forfedreklasser fra body-elementet
document.addEventListener('DOMContentLoaded', () => {
    const bodyClasses = document.body.classList;
    let aktivSeksjon = 'generell';

    bodyClasses.forEach((klasseNavn) => {
        if (klasseNavn.startsWith('ancestor-')) {
            aktivSeksjon = klasseNavn.replace('ancestor-', '');
        }
    });

    // Send tilpasset hendelse til Google Analytics via dataLayer
    if (window.dataLayer) {
        window.dataLayer.push({
            event: 'seksjonsvisning',
            innholdsseksjon: aktivSeksjon,
            sideSlug: document.body.className.match(/page-slug-([\w-]+)/)?.[1] || ''
        });
    }
});

Dette gir markedsførings- og analyseteamet mulighet til å segmentere brukeratferd basert på avdelinger uten å måtte konfigurere avanserte regler i Google Tag Manager.

#Flerspråklige nettsteder og multisite-nettverk

Når WordPress settes opp med flerspråklige verktøy som WPML, Polylang eller i et WordPress Multisite-nettverk, blir hierarkiske body-klasser et viktig verktøy for å håndtere variasjoner i typografi, leseretning og regionale designforskjeller.

#Håndtering av oversatte slugs og språkspesifikke stiler

På et tospråklig nettsted (for eksempel norsk og engelsk) vil siden /tjenester/ hete /services/ på den engelske versjonen. Det betyr at undersidene vil få henholdsvis ancestor-tjenester og ancestor-services.

Dersom du ønsker at samme CSS-regel skal gjelde for begge språkene uten duplisering, kan du kombinere :is()-pseudoklassen med språkattributtet eller slå sammen reglene:

/* Felles aksentfarge for tjenesteavdelingen på tvers av språk */
body:is(.ancestor-tjenester, .ancestor-services) {
    --theme-accent: #0284c7;
    --theme-surface-subtle: #f0f9ff;
}

/* Spesifikke typografiske justeringer for det norske språket */
body.ancestor-tjenester:lang(nb) .site-header h1 {
    letter-spacing: -0.01em;
}

Denne strukturen gjør det mulig for globale merkevarer å opprettholde en konsistent profil, samtidig som lokale redaksjoner har frihet til å oversette sidetitler og permalenker uten å ødelegge nettstedets visuelle identitet.

Å berike WordPress body_class med forelder- og aneslugs gir en ryddig og skalerbar CSS-arkitektur. Det fjerner avhengigheten av database-ID-er og sikrer at nettstedet forblir enkelt å vedlikeholde.

Når du implementerer denne løsningen i din egen kodebase, anbefaler vi å starte med å plassere filteret i en modulær mu-plugin i stedet for i det aktive temaet. Dette sikrer at klassene forblir operative selv om kunden eller designteamet bytter ut temaet i fremtiden. Kombinert med moderne CSS-egenskaper som tilpassede variabler og pseudoklassen :where(), får du et solid fundament som tåler fremtidig vekst i innholdstreet uten å generere uventet teknisk gjeld.