architektura SASS dla WordPress custom theme

Dobrze dobrana architektura katalogów i plików sass ułatwia kodowanie, jest czytelna i skalowalna. Dzięki czemu współpraca z innymi developerami czy wprowadzanie kolejnych zmian jest znacznie ułatwione.

Rekomendowana struktura katalogów (przykład)

my-theme/
├── assets/
│ └── scss/
│ ├── abstracts/ # bez CSS output
│ │ ├── _variables.sass
│ │ ├── _colors.sass
│ │ ├── _mixins.sass
│ │ ├── _functions.sass
│ │ └── _breakpoints.sass
│ │
│ ├── base/ # podstawy projektu
│ │ ├── _reset.sass
│ │ ├── _typography.sass
│ │ ├── _helpers.sass
│ │ └── _global.sass
│ │
│ ├── layout/ # layout strony
│ │ ├── _header.sass
│ │ ├── _footer.sass
│ │ ├── _grid.sass
│ │ └── _navigation.sass
│ │
│ ├── components/ # UI / reusable
│ │ ├── _button.sass
│ │ ├── _form.sass
│ │ ├── _card.sass
│ │ └── _modal.sass
│ │
│ ├── blocks/ # Gutenberg / ACF blocks
│ │ ├── _hero.sass
│ │ ├── _cta.sass
│ │ └── _gallery.sass
│ │
│ ├── pages/ # strony specjalne
│ │ ├── _home.sass
│ │ ├── _contact.sass
│ │ └── _blog.sass
│ │
│ ├── vendors/ # zewnętrzne style
│ │ └── _slick.sass
│ │
│ ├── main.sass # JEDYNY plik kompilowany
│ └── editor.sass # style edytora WP
│
├── style.css # wymagany przez WP (header)
└── functions.php

Kluczowe zasady

•  tylko jeden plik kompilowany czyli main.scss → style.min.css
• każdy plik zaczynający się od _ nie generuje CSS i służy tylko do importów
• używaj @use, nie @import (import jest deprecated)
• Gutenberg / ACF -> każdy blok = osobny plik i odpowiednie nazewnictwo class .block-testimonial – dzięki temu łatwo usunąć lub przenieść blok

Czego NIE robić

• nie kompiluj _header.sass,
• nie wrzucaj wielu CSS do frontu,
• jednego style.scss z 3000 linii,
• mieszania bloków, komponentów i layoutu,
• wielu plików CSS enqueue’owanych w WP,
• stylowania „po tagach” zamiast klas

Style edytora (editor.scss)

body.editor-styles-wrapper {
  @use 'abstracts/variables';

  h1 {
    color: variables.$primary;
  }
}

W functions.php

add_theme_support('editor-styles');
add_editor_style('assets/css/editor.css');

Czym jest layout a czym są komponenty a czym Bloki?

layout – duże, strukturalne części strony (szkielet)

components – małe, wielokrotnego użytku elementy UI (klocki)

Layout

Layout odpowiada na pytanie: „Jak strona jest zbudowana?”

• występują raz lub kilka razy
• definiują układ, nie detale
• często są powiązane z HTML/PHP theme

Przykłady layoutu w WordPressie:

• header – jest na każdej stronie, trzyma logo + menu
• footer – globalny, strukturalny
• main – kontener treści
• sidebar – układ kolumn
• navigation – główna nawigacja
• grid – system kolumn

Components

Components odpowiadają na pytanie: „Z czego strona się składa?”

elementy:

• małe
• powtarzalne
• niezależne od miejsca
• można je wrzucić do headera, bloku, strony
• .btn nie wie, czy jest w headerze, footerze czy bloku
• ma wyglądać tak samo wszędzie

Przykłady komponentów:

• button – header, hero, form, CTA
• card – listingi, blog, slider
• form – kontakt, popup
• input – formularze
• icon – wszędzie

Kluczowa zasada (najważniejsza)

• Layout NIE styluje komponentów
• Komponent NIE zależy od layoutu

A gdzie są Bloki (Gutenberg / ACF)?

To trzecia kategoria, bardzo ważna w WP.
Blok:

• jest kawałkiem strony
• składa się z:
  • layoutu
  • komponentów
• może używać komponentów
• nie zmienia ich definicji

Szybka ściąga

layout

• header
• footer
• grid
• section
• container
• kolumny

components

• button
• card
• input
• badge
• icon
• modal

blocks

• hero
• CTA
• testimonials
• pricing

Jak się nie pomylić? praktyczna reguła

Zadaj sobie pytanie:

„Czy ten element mógłby istnieć w innym miejscu bez zmiany CSS?”

• ✅ tak → component
• ❌ nie → layout lub block

Podsumowanie

• layout = szkielet strony
• components = klocki UI
• blocks = sekcje treści (WP)
• components są nie zależne od miejsca
• layout ustawia strukturę, nie wygląd detali