Konfiguracja vs Content w Drupal – na czym polega różnica

W pracy z Drupalem bardzo łatwo pomylić to, co jest treścią, a co stanowi konfigurację systemu. Efektem bywają problemy przy wdrażaniu nowych wersji strony, nadpisywanie ustawień na produkcji albo trudności z migracją danych między środowiskami. Zrozumienie różnicy między tymi dwoma obszarami ma kluczowe znaczenie nie tylko dla deweloperów, ale również dla administratorów i redaktorów, którzy chcą świadomie zarządzać rozwojem serwisu.

Fundamentalna różnica: czym jest konfiguracja, a czym content

Konfiguracja – logika i ustawienia serwisu

W Drupal termin konfiguracja odnosi się do wszystkiego, co opisuje, jak ma działać serwis, a nie do tego, jakie dane są w nim przechowywane. To przede wszystkim ustawienia struktury informacji, reguły działania modułów oraz definicje elementów interfejsu. Konfigurację tworzy się zazwyczaj podczas budowy i rozwoju serwisu, a następnie przenosi między środowiskami za pomocą mechanizmu Configuration Management.

Przykładowe elementy, które zaliczamy do konfiguracji:

• definicje typów treści (content type), pól i ich właściwości,
• viewsy i ich ustawienia, filtry, sortowania oraz wyświetlane pola,
• bloki, regiony i ich przypisanie do motywów,
• role i uprawnienia użytkowników,
• ustawienia modułów (np. konfiguracja cache, SEO, logowania),
• konfiguracja języków, translacji i formatów daty,
• konfiguracja workflow, moderation state czy publication state.

Te wszystkie dane są częścią logiki systemu. Określają one, w jaki sposób Drupal ma przetwarzać i prezentować informacje. Z punktu widzenia wersjonowania kodu konfiguracja powinna być przechowywana w repozytorium obok modułów i motywów, aby zmiany dało się kontrolować, przeglądać i odtwarzać.

Content – dane wprowadzane przez użytkowników

Content (treść) to wszystko, co wypełnia zdefiniowaną wcześniej strukturę. Są to dane wprowadzane, edytowane lub usuwane przez redaktorów, użytkowników końcowych bądź procesy integracyjne. Treść jest czymś zmiennym, często aktualizowanym, powiązanym z życiem serwisu i tym, co oferuje użytkownikom odwiedzającym stronę.

Przykłady typowego contentu w Drupalu:

• wpisy aktualności, artykuły, strony statyczne,
• produkty w e‑commerce, oferty, ogłoszenia,
• komentarze dodawane przez użytkowników,
• uploadowane pliki i obrazy powiązane z treściami,
• dane wprowadzane przez formularze (np. zgłoszenia, ankiety),
• tłumaczenia konkretnych węzłów, terminów czy bloków jako danych,
• profile użytkowników, jeżeli traktujemy je jako dane operacyjne.

Treść jest powiązana z bazą danych i zmienia się niezależnie od kodu czy ustawień systemu. W odróżnieniu od konfiguracji zwykle nie powinna być przenoszona pomiędzy środowiskami w trakcie typowego procesu wdrożeniowego, ponieważ każde środowisko może mieć własny, unikalny zestaw danych.

Różnice z perspektywy bazy danych i plików YAML

Od Drupala 8 konfiguracja jest przechowywana jako pliki YAML, które można eksportować i importować między środowiskami. Treść natomiast zapisuje się głównie w tabelach bazy danych odpowiedzialnych za węzły (nodes), terminy taksonomii, użytkowników, komentarze czy media.

W uproszczeniu:

• konfiguracja: odczytywana i zapisywana w plikach .yml (np. node.type.article.yml), przeznaczona do wersjonowania,
• content: przechowywany w tabelach node_field_data, taxonomy_term_field_data, users_field_data i innych, nie eksportowany standardowo przez Configuration Management.

Rozpoznanie, czy dana informacja jest konfiguracją, czy treścią, często można przeprowadzić, zadając pytanie: czy ta dana powinna być wspólna dla wszystkich środowisk (dev, stage, produkcja) i śledzona w Git, czy jest to zmienna treść specyficzna dla jednego środowiska?

Dlaczego rozróżnienie jest tak istotne

Pomylenie konfiguracji z contentem prowadzi do poważnych konsekwencji w procesie utrzymania projektu. Jeśli element, który jest treścią, zostanie potraktowany jak konfiguracja (np. wstawiony w bloczku jako stały tekst), jego zmiana będzie wymagała pełnego cyklu wdrożeniowego i zaangażowania programistów. Z kolei przechowywanie konfiguracji jako treści (np. węzeł, który decyduje o układzie strony) sprawi, że trudno będzie kontrolować te ustawienia między środowiskami, a ewentualne różnice będą ujawniały się dopiero na produkcji.

Typowe przykłady konfiguracji i contentu w praktyce

Typy treści, pola i viewsy

Jednym z najbardziej oczywistych przykładów konfiguracji są typy treści. Gdy definiujemy content type “Artykuł” lub “Produkt”, określamy strukturę danych: jakie pola ma dany typ, jakie są ich etykiety, rodzaj (tekst, liczba, referencja do encji), walidacje, ograniczenia długości czy domyślne wartości. To wszystko jest konfiguracją. Treścią są już konkretne węzły utworzone na podstawie tych typów.

Podobnie działa to w przypadku viewsów. Sam view – jego filtrowanie, rodzaj wyświetlania (lista, tabela, siatka), sortowanie, ograniczenie liczby elementów – należy do konfiguracji. Zawartość listy, czyli to, które węzły aktualnie spełniają warunki filtra, jest treścią. Zmiana warunków w viewsie jest zmianą konfiguracji, natomiast dodanie nowego artykułu, który pojawi się w tej liście, jest zmianą contentu.

Bloki, menu i motyw graficzny

Bloki, ich ustawienia i rozmieszczenie w regionach motywu także są konfiguracją. Jeżeli przygotowujemy blok z dynamiczną listą ostatnich wpisów, jego definicja – tytuł, widok użyty do wyświetlania, warunki widoczności – to konfiguracja. Natomiast same wpisy, które będą w tym bloku prezentowane, to treść, zależna od działań redaktorów.

Menu i ich struktura (elementy, hierarchia, aliasy, sposób wyświetlania) również należą do konfiguracji. Zmiana nazwy pozycji menu, dodanie nowej zakładki czy usunięcie istniejącej to modyfikacja konfiguracji, która powinna być odzwierciedlona w repozytorium i wdrażana poprzez import konfiguracji, a nie “klikane” na produkcji bez kontroli.

Role, uprawnienia i workflow

System ról w Drupalu – od prostych ról typu “authenticated user” po rozbudowane zestawy ról redaktorskich – jest klasycznym przykładem konfiguracji. Określamy, jakie działania może wykonywać dana rola: tworzyć treści, edytować cudze treści, publikować, moderować komentarze i tak dalej. To wszystko jest trwałą logiką systemu, która powinna być taka sama w każdym środowisku.

Workflow i stany publikacji (draft, published, archived itp.) to kolejny poziom konfiguracji. Reguły mówiące o tym, kto może przenieść treść z jednego stanu do drugiego, jakie są możliwe przejścia i co dzieje się przy każdej zmianie stanu, są fundamentalne dla procesu redakcyjnego. Dlatego muszą być kontrolowane jako część konfiguracji, a nie traktowane jak luźne ustawienia w pojedynczym środowisku.

Treści redakcyjne i dane biznesowe

Treści takie jak artykuły, aktualności, strony “O nas”, opisy produktów czy wpisy blogowe są jednoznacznie contentem. Podobnie dane biznesowe w systemach intranetowych, katalogach, bazach wiedzy lub serwisach informacyjnych. To, ile jest tych treści, jak są często aktualizowane, w jakich językach występują – wszystko to zmienia się niezależnie od logiki systemu.

Ważne jest, aby nie mieszać konfiguracji z treścią na poziomie projektowym. Jeśli redaktorzy mają często modyfikować jakiś fragment strony (np. nagłówek, lead na stronie głównej, tekst promocji), należy umożliwić im to w formie edytowalnego contentu – np. węzła, paragrafu, pola konfiguracyjnego dostępnego z poziomu UI, ale nadal zarządzanego jako treść, a nie “zabetonowanego” w motywie lub module.

Zarządzanie konfiguracją: Configuration Management w Drupal

Export i import konfiguracji

Od Drupala 8 wprowadzono rozbudowany system Configuration Management, który umożliwia eksport i import ustawień serwisu w postaci plików YAML. Typowy proces pracy z konfiguracją wygląda następująco: deweloperzy w środowisku lokalnym modyfikują konfigurację (np. dodają nowe pole do typu treści), testują zmiany, a następnie eksportują całą konfigurację do katalogu przechowywanego w repozytorium. Na środowisku testowym lub produkcyjnym importuje się następnie te pliki, synchronizując konfigurację z kodem.

Polecenia Drush takie jak drush config:export i drush config:import (lub ich skrócone formy) automatyzują ten proces i pozwalają włączyć go w pipeline CI/CD. Dzięki temu konfiguracja staje się częścią cyklu życia aplikacji, a nie chaotycznie zmienianym zbiorem ustawień.

Konfiguracja jako kod (Configuration as Code)

Przechowywanie konfiguracji w repozytorium razem z modułami i motywami realizuje ideę konfiguracja jako kod. Oznacza to, że każda zmiana ustawień serwisu jest wersjonowana, można przeglądać jej historię, porównywać różnice, cofać się do poprzednich wersji oraz recenzować zmiany (code review). To radykalnie zwiększa kontrolę nad tym, jak rozwija się projekt, a także ułatwia współpracę wielu osób nad jednym serwisem.

W praktyce wdrożenie tego podejścia wymaga dyscypliny: wszelkie istotne ustawienia trzeba zmieniać na środowisku deweloperskim, eksportować i commitować do repozytorium. Klikanie ustawień bezpośrednio na produkcji powinno być wyjątkiem, poprzedzonym świadomą decyzją, ponieważ utrudnia śledzenie zmian i może prowadzić do niespójności między środowiskami.

Środowiska: deweloperskie, testowe, produkcyjne

Kluczowa zasada brzmi: konfiguracja powinna być możliwie taka sama w każdym środowisku, natomiast content może być różny. Na środowiskach deweloperskich często używa się przykładowych danych lub zanonimizowanych kopii produkcji, natomiast konfiguracja typów treści, widoków, bloków czy workflow musi odzwierciedlać aktualny stan projektowy.

Typowy scenariusz pracy wygląda tak:

• zmiany konfiguracji powstają lokalnie (lub na dedykowanym środowisku konfiguracyjnym),
• konfiguracja jest eksportowana do plików YAML i commitowana do repozytorium,
• na środowiskach testowych i produkcyjnych konfiguracja jest importowana,
• content powstaje głównie na produkcji, a na środowiskach niższych wykorzystuje się kopie bazy lub generatory danych testowych.

Takie podejście minimalizuje ryzyko, że przy wdrażaniu nowej wersji kodu coś nieoczekiwanie zmieni się w sposobie działania serwisu, ponieważ konfiguracja przechodzi przez te same procesy weryfikacji co zmiany w kodzie.

Konflikty konfiguracji i ich rozwiązywanie

W praktyce zdarza się, że kilka osób równolegle pracuje nad konfiguracją, co może prowadzić do konfliktów. Konfiguracja w plikach YAML jest tekstowa, więc narzędzia kontroli wersji potrafią wykryć kolizje. Jednak nie wszystkie konflikty da się rozwiązać automatycznie – czasem trzeba ręcznie scalić różne zmiany w jednym pliku.

W takich sytuacjach szczególnie ważne jest, by rozumieć, które elementy są konfiguracją, a które treścią. Gdy błąd wynika z próby nadpisania danych treści poprzez import konfiguracji (np. przez błędne potraktowanie przykładowej treści jako konfiguracji), skutki mogą być trudne do odwrócenia. Dlatego zanim cokolwiek zostanie zapisane w plikach YAML i zaciągnięte na produkcję, trzeba upewnić się, że faktycznie należy to do warstwy konfiguracji.

Pogranicze konfiguracji i contentu: przypadki szczególne

Bloki z treścią a bloki konfiguracyjne

Bloki w Drupalu bywają mylące, ponieważ mogą pełnić zarówno funkcję w pełni konfiguracyjną, jak i być nośnikiem treści. Przykładowo blok typu “Custom block” z tekstem promocyjnym na stronie głównej jest w istocie contentem, choć jego pozycja w regionie motywu, widoczność na określonych ścieżkach czy ustawienia cache to już konfiguracja.

Bez jasnego rozdzielenia tych ról łatwo o błędy. Jeżeli blok z ważną treścią jest modyfikowany na środowisku deweloperskim i jego zawartość zostaje przypadkowo wyeksportowana jako część konfiguracji, import na produkcję może nadpisać aktualną treść. Dlatego warto wypracować zasady: które bloki traktujemy jako treść redakcyjną (edytowaną zwykle na produkcji), a które jako elementy czysto konfiguracyjne (np. techniczne bloki z widokami).

Taksonomie, słowniki i terminy

Taksonomia to szczególnie ciekawy przykład z punktu widzenia rozróżnienia konfiguracji i contentu. Definicja słowników taksonomii (np. “Kategorie artykułów”, “Tagi”, “Typy produktów”) stanowi konfigurację – to część struktury systemu. Jednak same terminy (konkretne kategorie, tagi) bywają traktowane różnie w zależności od projektu.

W niektórych przypadkach terminy są względnie stałe i zarządzane centralnie (np. zamknięty słownik branż czy krajów). Wtedy można rozważyć traktowanie ich jak elementu konfiguracji, szczególnie jeśli są kluczowe dla logiki systemu. W innych projektach tagi lub kategorie tworzą redaktorzy na bieżąco, a ich ilość i nazwy często się zmieniają. W takiej sytuacji terminy pełnią rolę contentu i nie powinny być przenoszone przez Configuration Management między środowiskami.

Konfiguracja przechowywana jako treść

Zdarza się, że w celu ułatwienia pracy nietechnicznym użytkownikom, część konfiguracji celowo przenosi się do warstwy treści. Przykładowo można stworzyć specjalny typ treści “Ustawienia strony głównej”, w którym redaktorzy określają nagłówek, banery, listę promowanych artykułów czy kolory przycisków. W sensie technicznym jest to content, ale z punktu widzenia logiki systemu – konfiguracja wyglądu strony.

Takie rozwiązania mają swoje plusy (łatwiejsza edycja, brak konieczności angażowania deweloperów przy każdej zmianie), ale również wady: trudniejsze wersjonowanie ustawień, ryzyko wprowadzania niespójności oraz konieczność ręcznego odtwarzania konfiguracji na innych środowiskach. Przed ich użyciem trzeba świadomie zdecydować, jaki poziom kontroli i automatyzacji jest dla danego projektu najważniejszy.

Import treści, migracje i synchronizacja

Odrębnym zagadnieniem jest import contentu z zewnętrznych systemów lub wcześniejszych wersji strony. Moduł Migrate oraz powiązane narzędzia pozwalają tworzyć procesy, w których treść jest automatycznie przenoszona i aktualizowana. Tutaj granica między konfiguracją a treścią znów się zaciera: definicje procesów migracji (mapowanie pól, źródeł i celów) to konfiguracja, natomiast wyniki uruchomienia tych procesów – zaimportowane węzły, terminy, media – są treścią.

Rozumienie tej różnicy jest kluczowe przy planowaniu cyklicznych migracji lub synchronizacji danych (np. codziennego pobierania ofert z systemu zewnętrznego). Błędy w konfiguracji migracji mogą doprowadzić do uszkodzenia treści, duplikacji danych lub utraty powiązań między encjami. Dlatego konfiguracja procesów migracyjnych powinna być starannie wersjonowana i testowana, podobnie jak inne elementy logiki systemu.