Dodawanie slugu strony nadrzędnej do klas body w WordPressie

#Ograniczenia domyślnej implementacji body_class w WordPressie

Funkcja body_class() wywoływana w pliku nagłówka szablonu (header.php) lub ewaluowana wewnętrznie przez silnik motywów blokowych Full Site Editing (FSE) odpowiada za dostarczenie kontekstu wizualnego przeglądarce internetowej.

Gdy użytkownik odwiedza stronę zagnieżdżoną pod adresem /uslugi/migracje/bazy-danych/, silnik generuje zestaw klas zbliżony do poniższego fragmentu HTML:

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

Przyglądając się powyższemu kodowi, zauważymy istotne braki semantyczne i architektoniczne:

1. Sztywna zależność od kluczy głównych bazy danych: Klasa parent-pageid-98 informuje jedynie, że rodzic w tabeli wp_posts otrzymał auto-inkrementowany numer 98. W arkuszu stylów CSS zapis .parent-pageid-98 .header traci jakikolwiek czytelny kontekst. Gdy inny programista analizuje reguły po kilku miesiącach, nie wie, czy klasa odnosi się do działu usług, bloga czy polityki prywatności.
2. Ryzyko zerwania stylów podczas migracji środowisk: Podczas synchronizacji bazy danych między środowiskiem lokalnym (Docker), serwerem testowym (staging) a klastrem produkcyjnym, identyfikator strony rodzica może ulec zmianie. Wystarczy, że strona została utworzona w innej kolejności lub zaimportowana przez plik WXR, a reguły CSS przestają działać.
3. Brak kontekstu dla głębszych przodków: Domyślny WordPress analizuje wyłącznie bezpośredniego rodzica poprzez pole post_parent. Jeśli drzewo podstron ma trzy poziomy zagłębienia, informacja o głównym dziale nadrzędnym /uslugi/ jest całkowicie pomijana. W efekcie stylowanie całej gałęzi wymaga ręcznego wypisywania numerów ID wszystkich podstron potomnych.

Ręczne utrzymywanie list numerycznych selektorów w arkuszu stylów rodzi dług techniczny:

/* Podatne na błędy: wymaga aktualizacji pliku CSS przy każdej nowej podstronie */
.page-id-142 .site-header,
.page-id-143 .site-header,
.page-id-144 .site-header {
    background-color: #0b2545;
}

W momencie gdy zespół redakcyjny doda nową ofertę pod adresem /uslugi/migracje/chmura/, style nagłówka nie zostaną zaaplikowane do czasu ręcznej interwencji programisty. Wstrzyknięcie czytelnych slugów do znacznika body rozwiązuje ten problem raz na zawsze.

#Budowa filtru body_class z użyciem get_post_ancestors

Do rozwiązania powyższych problemów służy filtr body_class. Hook ten przekazuje tablicę aktualnie wyliczonych klas CSS i oczekuje zwrócenia zmodyfikowanej tablicy.

Zamiast konstruować własne zapytania SQL do bazy danych lub pisać rekurencyjne pętle while odpytujące pole post_parent, wykorzystujemy funkcję WordPress core get_post_ancestors(). Przyjmuje ona identyfikator posta lub obiekt WP_Post i zwraca uporządkowaną tablicę identyfikatorów przodków: od bezpośredniego rodzica aż do korzenia danej gałęzi serwisu.

Poniższy kod stanowi kompletne, bezpieczne rozwiązanie gotowe do wdrożenia w pliku functions.php motywu potomnego lub jako samodzielna wtyczka typu Must-Use (mu-plugin):

<?php
/**
 * Nazwa wtyczki: WPPoland Semantyczne Klasy Przodków Body
 * Opis: Wzbogaca filtr body_class o oczyszczone slugi bieżącego wpisu, rodzica oraz wszystkich przodków.
 * Wersja: 1.2.0
 * Autor: WPPoland
 */

declare(strict_types=1);

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

/**
 * Dodaje semantyczne slugi rodzica i wszystkich przodków do klas znacznika body.
 *
 * Obsługuje standardowe strony hierarchiczne oraz dowolne niestandardowe typy wpisów (CPT).
 *
 * @param array<string> $classes Tablica klas wygenerowanych przez WordPress core.
 * @return array<string> Zmodyfikowana, przefiltrowana i unikalna tablica klas CSS.
 */
function wppoland_dodaj_slugi_przodkow_do_body_class( array $classes ): array {
    // Sprawdzamy wyłącznie pojedyncze widoki wpisów i stron
    if ( ! is_singular() ) {
        return $classes;
    }

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

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

    // 1. Slug bieżącej strony z czytelnym prefiksem
    if ( ! empty( $post_obj->post_name ) ) {
        $classes[] = sanitize_html_class( 'page-slug-' . $post_obj->post_name );
    }

    // 2. Obsługa relacji nadrzędnych dla typów hierarchicznych z przypisanym rodzicem
    if ( is_post_type_hierarchical( $post_obj->post_type ) && $post_obj->post_parent > 0 ) {
        // Bezpośredni rodzic
        $parent_obj = get_post( $post_obj->post_parent );
        if ( $parent_obj instanceof \WP_Post && ! empty( $parent_obj->post_name ) ) {
            $classes[] = sanitize_html_class( 'parent-' . $parent_obj->post_name );
        }

        // Pobranie pełnej ścieżki przodków (rodzic, dziadek, pradziadek)
        $ancestor_ids = get_post_ancestors( $queried_id );
        if ( ! empty( $ancestor_ids ) && is_array( $ancestor_ids ) ) {
            foreach ( $ancestor_ids as $ancestor_id ) {
                $ancestor_obj = get_post( $ancestor_id );
                if ( $ancestor_obj instanceof \WP_Post && ! empty( $ancestor_obj->post_name ) ) {
                    $classes[] = sanitize_html_class( 'ancestor-' . $ancestor_obj->post_name );
                }
            }

            // Oznaczenie korzenia sekcji (najwyższy węzeł hierarchii)
            $root_id = end( $ancestor_ids );
            if ( $root_id && $root_id !== $post_obj->post_parent ) {
                $root_obj = get_post( $root_id );
                if ( $root_obj instanceof \WP_Post && ! empty( $root_obj->post_name ) ) {
                    $classes[] = sanitize_html_class( 'section-root-' . $root_obj->post_name );
                }
            }
        }
    }

    // 3. Dodanie nazwy szablonu pliku, jeśli przypisano niestandardowy szablon
    $template_slug = get_page_template_slug( $post_obj->ID );
    if ( ! empty( $template_slug ) && is_string( $template_slug ) ) {
        $template_name = str_replace( array( '.php', '.html' ), '', basename( $template_slug ) );
        $classes[]     = sanitize_html_class( 'template-' . $template_name );
    }

    // Usunięcie duplikatów i pustych wartości z tablicy
    return array_values( array_unique( array_filter( $classes ) ) );
}
add_filter( 'body_class', 'wppoland_dodaj_slugi_przodkow_do_body_class', 10, 1 );

#Wygląd znacznika body w wynikowym dokumencie HTML

Aby przeanalizować działanie filtru w praktyce, prześledźmy strukturę adresu URL dla rozbudowanego działu korporacyjnego:

• /uslugi/ (Strona główna działu, ID 40)
• /uslugi/infrastruktura/ (Rodzic pośredni, ID 108)
• /uslugi/infrastruktura/optymalizacja-mysql/ (Bieżąca podstrona, ID 214)

Gdy przeglądarka wysyła żądanie pod ten adres URL, funkcja get_post_ancestors(214) zwraca tablicę identyfikatorów [108, 40].

W wygenerowanym kodzie źródłowym strony znacznik <body> otrzymuje czytelny, precyzyjny zestaw klas:

<body class="page-template-default page page-id-214 page-slug-optymalizacja-mysql parent-infrastruktura ancestor-infrastruktura ancestor-uslugi section-root-uslugi">

Każda z wygenerowanych klas pełni odrębną funkcję w architekturze frontendu:

• page-slug-optymalizacja-mysql: Pozwala na zaaplikowanie stylów wyłącznie dla tej jednej, konkretnej podstrony.
• parent-infrastruktura: Obejmuje bezpośrednie podstrony działu infrastruktury.
• ancestor-infrastruktura: Adresuje wszystkie elementy potomne gałęzi infrastruktury, niezależnie od poziomu zagnieżdżenia.
• ancestor-uslugi: Daje dostęp do całej sekcji usług, w tym wszystkich podstron konsultingowych, audytowych czy wdrożeniowych.
• section-root-uslugi: Jednoznacznie definiuje korzeń sekcji nadrzędnej, ułatwiając globalne przełączanie motywów kolorystycznych działu.

#Praktyczne zastosowanie klas rodzica w CSS i nowoczesnym SCSS

Semantyczne klasy w elemencie <body> pozwalają na tworzenie w pełni modularnych, deklaratywnych arkuszy stylów. Zamiast rozbudowanych reguł warunkowych w plikach szablonów PHP, cała logika prezentacji przenosi się do warstwy CSS.

#Przykład 1: Definiowanie zmiennych CSS dla poszczególnych działów

Najczystszą metodą zarządzania kolorystyką sekcji w nowoczesnym CSS jest nadpisywanie właściwości niestandardowych (CSS Custom Properties) na poziomie selektora body:

/* Domyślne wartości zmiennych dla całego serwisu */
:root {
    --theme-accent: #0066cc;
    --theme-surface-subtle: #f8fafc;
    --theme-border-color: #e2e8f0;
}

/* Wariant kolorystyczny dla całego działu Usługi */
body.ancestor-uslugi {
    --theme-accent: #0284c7;
    --theme-surface-subtle: #f0f9ff;
    --theme-border-color: #bae6fd;
}

/* Specjalny akcent dla gałęzi Bezpieczeństwo */
body.ancestor-bezpieczenstwo {
    --theme-accent: #dc2626;
    --theme-surface-subtle: #fef2f2;
    --theme-border-color: #fecaca;
}

/* Dedykowany styl dla Bazy Wiedzy */
body.ancestor-baza-wiedzy {
    --theme-accent: #059669;
    --theme-surface-subtle: #ecfdf5;
    --theme-border-color: #a7f3d0;
}

Komponenty interfejsu (nagłówki kart, ikony, przyciski, paginacja) odwołują się po prostu do zmiennej var(--theme-accent). Zmiana klasy w znaczniku body automatycznie aktualizuje wygląd wszystkich podrzędnych bloków.

#Przykład 2: Zmiana układu siatki i ukrywanie elementów sekcyjnych

W sekcjach o charakterze technicznym, takich jak dokumentacja programistyczna, układ strony wymaga często innej szerokości kontenera oraz widocznego spisu treści. Z kolei na stronach regulaminów czy polityk prywatności konieczne bywa ukrycie formularzy kontaktowych:

/* Standardowy kontener artykułu */
.site-main .content-container {
    max-width: 800px;
    margin: 0 auto;
    padding: 2.5rem 1rem;
}

/* Rozszerzony układ siatki dla całej sekcji dokumentacji */
body.ancestor-dokumentacja .site-main .content-container {
    max-width: 1440px;
    display: grid;
    grid-template-columns: 280px 1fr;
    gap: 2.5rem;
    padding: 2rem;
}

/* Ukrycie globalnego baneru marketingowego w sekcji prawnej */
body.ancestor-regulaminy .global-cta-banner,
body.ancestor-polityka-prywatnosci .global-cta-banner {
    display: none;
}

#Przykład 3: Architektura zagnieżdżonych selektorów w SCSS

W projektach kompilowanych przez Sass/SCSS struktura stylów dla nawigacji głównej staje się intuicyjna dzięki wykorzystaniu selektora rodzica &:

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

    .nav-link {
        color: #334155;
        font-weight: 500;
        transition: color 0.2s ease;

        // Podświetlenie odpowiedniej pozycji w menu podczas przeglądania podstron
        body.ancestor-uslugi &--uslugi {
            color: var(--theme-accent);
            border-bottom: 2px solid var(--theme-accent);
        }

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

#Architektura specyficzności CSS z klasami rodziców i przodków

Dodanie klas na poziomie korzenia dokumentu HTML wiąże się z koniecznością kontroli specyficzności selektorów. Selektor w postaci body.ancestor-uslugi .btn ma specyficzność (0, 2, 1).

Jeśli w systemie projektowym stosowane są płaskie klasy narzędziowe (utility classes) lub domyślne style bloków o specyficzności (0, 1, 0), nadrzędny selektor może wymusić stosowanie niepożądanych reguł !important.

#Obniżanie specyficzności za pomocą pseudoklasy where

Nowoczesna specyfikacja CSS udostępnia pseudoklasę :where(). Każdy selektor przekazany wewnątrz :where() otrzymuje specyficzność równą (0, 0, 0).

/* Zero dodatkowej specyficzności dla selektora kontekstowego */
:where(body.ancestor-uslugi) .hero-banner {
    background-color: #0369a1;
    color: #ffffff;
}

/* Klasa modyfikatora komponentu bez trudu nadpisuje styl bazowy */
.hero-banner.is-style-light {
    background-color: #f8fafc;
    color: #0f172a;
}

Dzięki zastosowaniu :where() reguły sekcyjne nie kolidują z wariantami bloków konfigurowanymi przez redaktorów w edytorze Gutenberg.

#Grupowanie wielu gałęzi za pomocą pseudoklasy is

Gdy kilka odrębnych sekcji witryny dzieli ten sam zestaw modyfikacji wizualnych, zamiast powielać rozbudowane reguły, warto połączyć je za pomocą pseudoklasy :is():

/* Aplikowanie cienia nagłówka dla sekcji usług, produktów i portfolio */
body:is(.ancestor-uslugi, .ancestor-produkty, .ancestor-portfolio) .site-header {
    box-shadow: 0 4px 6px -1px rgba(0, 0, 0, 0.08);
}

Zapis ten upraszcza strukturę arkusza i ułatwia przegląd kodu podczas audytów optymalizacyjnych.

#Integracja z motywami blokowymi FSE w WordPressie 6.6 i nowszych

W architekturze Full Site Editing (wprowadzonej w WordPressie 5.9 i dynamicznie rozwijanej w wersjach 6.6, 6.7 i 7.x) klasyczne pliki PHP takie jak header.php zostały zastąpione szablonami HTML w katalogu templates/.

#Jak motywy blokowe renderują znacznik body

Mimo że w szablonach HTML motywu blokowego nie występuje bezpośrednie wywołanie funkcji body_class(), silnik WordPressa wykonuje ten proces automatycznie. W trakcie renderowania drzewa bloków silnik wywołuje funkcję pomocniczą get_body_class(), przetwarza zarejestrowane filtry i dołącza atrybut class do wyjściowego znacznika <body>.

Oznacza to, że nasz filtr PHP działa w motywach blokowych bez jakichkolwiek modyfikacji w plikach szablonów HTML.

#Współpraca z theme.json i wariantami stylów bloków

Plik konfiguracyjny theme.json definiuje globalną paletę kolorów, typografię oraz odstępy. Nie posiada on jednak wbudowanej możliwości warunkowania stylów na podstawie zagnieżdżenia adresu URL podstrony.

Aby połączyć elastyczność motywu blokowego z hierarchicznymi klasami body:

1. Zdefiniuj tokeny sekcyjne w CSS: Przypisz zmienne CSS do odpowiednich klas przodków w głównym arkuszu stylów motywu potomnego.
2. Powiąż zmienne w theme.json: W definicji palety kolorów odwołaj się do zadeklarowanych zmiennych CSS.
3. Korzystaj ze stylów blokowych: Administrator wybierający w edytorze blok “Kolor akcentu sekcji” automatycznie otrzyma właściwy odcień zależny od bieżącej gałęzi serwisu.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        {
          "slug": "akcent-sekcji",
          "color": "var(--theme-accent, #0066cc)",
          "name": "Akcent Sekcji"
        }
      ]
    }
  }
}

Taki model pozwala zachować pełną czystość kodu w theme.json, pozostawiając zarządzanie logiką hierarchii po stronie lekkiego filtra PHP.

#Obsługa hierarchicznych typów wpisów Custom Post Types

Wiele zaawansowanych instalacji WordPressa przechowuje rozbudowane struktury danych w dedykowanych typach wpisów (CPT) zamiast w standardowych stronach statycznych. Typowymi przykładami są bazy wiedzy (kb_article), katalogi dokumentacji technicznej (docs) czy struktury lokalizacyjne (lokalizacje).

Aby filtr poprawnie przetwarzał hierarchię w danym typie wpisu, typ ten musi zostać zarejestrowany z obsługą hierarchii:

register_post_type( 'baza_wiedzy', array(
    'labels'       => array( 'name' => 'Baza Wiedzy' ),
    'public'       => true,
    'has_archive'  => true,
    'hierarchical' => true, // Kluczowy parametr aktywujący post_parent
    'supports'     => array( 'title', 'editor', 'page-attributes' ),
    'rewrite'      => array( 'slug' => 'baza-wiedzy', 'hierarchical' => true ),
) );

Ustawienie 'hierarchical' => true oraz dodanie 'page-attributes' w parametrze supports aktywuje w edytorze blokowym panel wyboru strony nadrzędnej.

Nasz filtr weryfikuje warunek is_post_type_hierarchical( $post_obj->post_type ). Dzięki temu standardowe wpisy blogowe (gdzie pole post_parent nie występuje) nie generują zbędnych zapytań, a hierarchiczne CPT otrzymują kompletne klasy parent-{slug} oraz ancestor-{slug}.

#Wpływ na wydajność i buforowanie przodków w pamięci podręcznej

W serwisach o standardowej skali wywołanie get_post_ancestors() generuje minimalne obciążenie serwera. WordPress domyślnie buforuje obiekty postów w pamięci podręcznej zapytania głównego (WP_Post cache).

Jednak na portalach o dużym natężeniu ruchu (high-traffic enterprise), przy drzewach zagnieżdżonych na 5 lub więcej poziomów, warto zadbać o izolację obliczeń za pomocą mechanizmu wp_cache_get.

#Optymalizacja z użyciem obiektu cache WordPressa

Gdy serwis korzysta z trwałego silnika pamięci podręcznej obiektów (np. Redis lub Memcached), wyliczoną listę klas można zapisać w cache obiektu:

/**
 * Buforowana wersja filtru klas hierarchicznych body.
 *
 * @param array<string> $classes Tablica klas bazowych.
 * @return array<string> Wzbogacona tablica klas.
 */
function wppoland_buforowane_klasy_przodkow_body( array $classes ): array {
    if ( ! is_singular() ) {
        return $classes;
    }

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

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

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

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

        if ( $post instanceof \WP_Post ) {
            if ( ! empty( $post->post_name ) ) {
                $cached_classes[] = 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_classes[] = sanitize_html_class( 'ancestor-' . $ancestor->post_name );
                    }
                }

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

        // Zapisujemy wyliczone klasy w pamięci podręcznej na 12 godzin
        wp_cache_set( $cache_key, $cached_classes, $cache_group, 43200 );
    }

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

/**
 * Czyści pamięć podręczną klas po zapisaniu lub aktualizacji wpisu.
 *
 * @param int $post_id Identyfikator modyfikowanego wpisu.
 */
function wppoland_wyczysc_cache_klas_body( int $post_id ): void {
    wp_cache_delete( 'slugs_' . $post_id, 'wppoland_body_classes' );
}
add_action( 'save_post', 'wppoland_wyczysc_cache_klas_body' );

Powyższy mechanizm eliminuje potrzebę ponownego odpytywania obiektów przodków przy każdym odświeżeniu strony, redukując zużycie cykli procesora PHP do minimum.

#Sanityzacja i obsługa przypadków brzegowych z sanitize_html_class

Wstrzykiwanie dynamicznych danych pochodzących z bazy do atrybutów HTML wymaga bezwzględnego przestrzegania zasad bezpieczeństwa i higieny kodu:

1. Obowiązkowa funkcja sanitize_html_class(): Tytuły i slugi wpisów tworzone przez redaktorów mogą zawierać znaki niedozwolone w specyfikacji CSS. Wywołanie sanitize_html_class() usuwa niedozwolone znaki i spacje, zabezpieczając atrybut class przed uszkodzeniem składni HTML.
2. Slugi rozpoczynające się od cyfr: Zgodnie ze specyfikacją CSS, poprawny identyfikator klasy nie może zaczynać się od cyfry bez jej specjalnego maskowania. Jeśli podstrona nadrzędna ma slug 2026-raport, próba utworzenia selektora .2026-raport zakończy się błędem parsera CSS. Zastosowanie prefiksów semantycznych (parent-2026-raport, ancestor-2026-raport) gwarantuje, że klasa zawsze rozpoczyna się od litery.
3. Walidacja obiektów WP_Post: W przypadku ręcznych ingerencji w bazę danych lub błędów importu może dojść do sytuacji, w której pole post_parent wskazuje na usunięty wpis. Sprawdzenie if ( $parent_obj instanceof \WP_Post ) zapobiega wygenerowaniu błędu krytycznego PHP Trying to get property of non-object.

#Testowanie automatyczne poprawności klas body w procesach CI/CD

W projektach klasy enterprise zarządzanych w systemach kontroli wersji Git, stabilność klas znacznika body decyduje o spójności wizualnej całego serwisu. Wdrożenie testów integracyjnych w środowisku PHPUnit lub wp-browser pozwala wykryć regresje zanim zmiany trafią na serwer produkcyjny.

#Przykładowy test jednostkowy w PHPUnit dla filtru body_class

Poniższy fragment kodu ilustruje strukturę testu sprawdzającego poprawność dodawania klas dla hierarchicznego drzewa stron:

<?php
/**
 * Klasa testowa weryfikująca wstrzykiwanie klas przodków do znacznika body.
 */
namespace WPPoland\Tests;

use WP_UnitTestCase;

class TestHierarchicalBodyClasses extends WP_UnitTestCase {

    public function test_hierarchical_classes_added_correctly(): void {
        // Tworzymy stronę główną sekcji
        $parent_id = $this->factory->post->create( array(
            'post_type'  => 'page',
            'post_title' => 'Usługi Korporacyjne',
            'post_name'  => 'uslugi-korporacyjne',
        ) );

        // Tworzymy stronę potomną
        $child_id = $this->factory->post->create( array(
            'post_type'   => 'page',
            'post_title'  => 'Audyt Bezpieczeństwa',
            'post_name'   => 'audyt-bezpieczenstwa',
            'post_parent' => $parent_id,
        ) );

        // Ustawiamy bieżące zapytanie na stronę potomną
        $this->go_to( get_permalink( $child_id ) );

        $classes = get_body_class();

        $this->assertContains( 'page-slug-audyt-bezpieczenstwa', $classes );
        $this->assertContains( 'parent-uslugi-korporacyjne', $classes );
        $this->assertContains( 'ancestor-uslugi-korporacyjne', $classes );
    }

    public function test_non_hierarchical_post_skips_ancestor_classes(): void {
        // Standardowy wpis blogowy nie powinien posiadać klas rodziców
        $post_id = $this->factory->post->create( array(
            'post_type'  => 'post',
            'post_title' => 'Wpis Blogowy',
            'post_name'  => 'wpis-blogowy',
        ) );

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

        $classes = get_body_class();

        $this->assertContains( 'page-slug-wpis-blogowy', $classes );
        
        $has_parent_class = false;
        foreach ( $classes as $class_name ) {
            if ( str_starts_with( $class_name, 'parent-' ) ) {
                $has_parent_class = true;
                break;
            }
        }
        $this->assertFalse( $has_parent_class );
    }
}

Tego rodzaju testy chronią zespół programistyczny przed przypadkowym usunięciem filtru podczas aktualizacji motywu lub refaktoryzacji wtyczek bazowych serwisu.

#Strategia migracji i refaktoryzacji starszych arkuszy CSS

Wiele funkcjonujących witryn korporacyjnych posiada rozbudowane arkusze stylów stworzone lata temu, w których setki reguł opierają się na selektorach typu .page-id-45 lub .page-id-89. Nagła zmiana wszystkich selektorów na semantyczne slugi w jednym commicie niesie ze sobą ryzyko przeoczenia rzadziej odwiedzanych podstron.

#Trzyetapowy proces bezpiecznej transformacji arkuszy stylów

1. Wdrożenie filtru przy zachowaniu klas domyślnych: Prezentowany filtr body_class nie usuwa klas domyślnych generowanych przez WordPress core. Oznacza to, że po wdrożeniu funkcji obie grupy klas współistnieją równolegle w kodzie HTML. Żadna ze starych reguł bazujących na identyfikatorach numerycznych nie ulega uszkodzeniu.
2. Stopniowa migracja selektorów w oparciu o sekcje biznesowe: Zamiast modyfikować cały arkusz naraz, refaktoryzację warto przeprowadzać partiami według działów serwisu. Rozpoczynając od działu usług, zastępujemy wiązki selektorów .page-id-45, .page-id-46, .page-id-47 pojedynczą regułą body.ancestor-uslugi. W ten sposób redukujemy objętość kodu CSS o kilkadziesiąt procent już w pierwszym sprincie.
3. Audyt regresji wizualnej za pomocą Playwright lub BackstopJS: Po zaktualizowaniu arkuszy stylów dla danego działu uruchamiamy automatyczne zrzuty ekranu porównujące wersję staging z produkcją. Po potwierdzeniu braku różnic w pikselach usuwamy stare selektory numeryczne z repozytorium.

#Najczęstsze problemy diagnostyczne i ich rozwiązywanie

Gdy po wdrożeniu kodu klasy nie pojawiają się w strukturze dokumentu, warto zweryfikować następujące elementy:

1. Brak wywołania body_class w szablonie: W autorskich motywach klasycznych upewnij się, że plik header.php zawiera prawidłowe wywołanie <?php body_class(); ?>. Jeśli w kodzie szablonu wpisano statyczny znacznik <body class="site-body"> bez funkcji silnika, filtry WordPressa nie zostaną uruchomione.
2. Nadpisywanie tablicy przez inne wtyczki: Jeśli inna wtyczka podpięta pod ten sam hook zwraca nową tablicę bez łączenia jej z poprzednią, klasy mogą zostać utracone. Zwiększ priorytet funkcji (np. na 20 lub 30) w wywołaniu add_filter.
3. Agresywne buforowanie HTML: Pamiętaj o wyczyszczeniu pamięci podręcznej wtyczek optymalizacyjnych (WP Rocket, LiteSpeed, W3 Total Cache) oraz reguł cache na brzegu sieci (Cloudflare). Zmiany w klasach PHP nie będą widoczne, dopóki przeglądarka pobiera statyczny plik HTML wygenerowany przed modyfikacją.
4. Weryfikacja kontekstu is_singular: Filtr celowo ogranicza działanie do pojedynczych stron i wpisów. Widoki archiwów, stron kategorii czy strony głównej bloga nie posiadają relacji hierarchicznych post_parent, więc klasy przodków nie zostaną dla nich wygenerowane.

Dodanie slugów stron nadrzędnych do klas znacznika body to sprawdzona technika, która uniezależnia arkusze stylów od zmiennych identyfikatorów bazy danych. Zapewnia pełną semantykę, czytelność kodu i ułatwia rozwój serwisów korporacyjnych opartych na WordPressie.

Jeśli rozwijasz niestandardowy motyw korporacyjny, skalujesz zaawansowany portal lub porządkujesz dług techniczny w warstwie szablonów, sprawdź, jak prowadzimy profesjonalne programowanie i wsparcie techniczne WordPress.