Symfony czy Drupal – co wybrać dla systemu firmowego lub portalu?

Symfony czy Drupal – to nie jest wybór między dwoma równorzędnymi narzędziami, tylko między gotowym systemem zarządzania treścią a frameworkiem do budowy własnej aplikacji. Drupal wybierasz, gdy sercem projektu są treści, redakcja, wersje językowe i uprawnienia do publikacji. Symfony (albo Laravel) wybierasz, gdy sercem projektu jest logika biznesowa: zamówienia, ceny, procesy, integracje z ERP. Większość nieudanych projektów, które oglądamy, wzięła się z użycia jednego narzędzia do zadania drugiego.

Wspólne korzenie, różne przeznaczenie

Od wersji 8 Drupal jest zbudowany na komponentach Symfony. Korzysta m.in. z obsługi żądań HTTP, kontenera zależności, systemu zdarzeń i routingu, a nowoczesny kod Drupala pisze się w podobnym stylu jak w Symfony: usługi, zdarzenia, klasy z przestrzeniami nazw. Programista Symfony szybko odnajdzie się w kodzie modułu Drupala.

Na tym podobieństwa się kończą. Drupal dostarcza gotowy model danych (typy treści, pola, taksonomie), panel redakcyjny, system uprawnień, wersjonowanie treści, obieg publikacji i obsługę wielu języków. Symfony dostarcza klocki: routing, formularze, bezpieczeństwo, integrację z bazą przez Doctrine, kolejki przez Messenger. Model danych, panel i procesy projektujesz od zera.

Innymi słowy: w Drupalu dostosowujesz istniejący system, w Symfony budujesz własny. Obie drogi mają swoją cenę.

Kiedy Drupal jest dobrym wyborem

Drupal broni się w projektach, w których większość pracy to zarządzanie treścią:

• serwis korporacyjny lub portal wiedzy z wieloma autorami, recenzją i harmonogramem publikacji,
• strona w kilku wersjach językowych, z tłumaczeniem treści, interfejsu i konfiguracji – obsługa wielojęzyczności jest w rdzeniu Drupala, a nie w dodatkach,
• rozbudowane uprawnienia redakcyjne: różne zespoły edytują różne sekcje, część treści wymaga akceptacji,
• serwisy instytucji publicznych i uczelni, gdzie liczy się dostępność, długi cykl życia i duża liczba podstron,
• katalog treści, który ma być udostępniany dalej przez API – JSON:API jest dostępny w rdzeniu.

W takich projektach budowanie tego samego w frameworku oznacza miesiące pracy nad funkcjami, które Drupal ma od lat: wersjami, moderacją, polami, mediami, ścieżkami URL.

Kiedy framework (Symfony lub Laravel) wygrywa

Framework wybieramy, gdy system ma przede wszystkim „liczyć i przetwarzać”, a treść jest dodatkiem:

• portal B2B z cenami indywidualnymi, limitami kredytowymi, koszykiem i zamówieniami zapisywanymi w ERP,
• CRM, system ofertowania, obsługa zleceń lub reklamacji z własnymi statusami i regułami,
• warstwa integracyjna między ERP, PIM, e-commerce i systemami partnerów,
• aplikacja SaaS z modelem danych, który nie przypomina artykułów i stron.

Da się to zbudować w Drupalu, ale każde odejście od modelu „węzeł z polami” oznacza pisanie własnych encji, formularzy i logiki w konwencjach Drupala, przy zachowaniu zgodności z jego mechanizmami cache, uprawnień i aktualizacji. W pewnym momencie płacisz za CMS, z którego nie korzystasz, i walczysz z jego założeniami.

Przykład z praktyki: firma produkcyjna prowadzi serwis produktowy w Drupalu i chce dodać strefę dystrybutora z cenami z ERP i zamówieniami. Zamiast rozbudowywać Drupala o logikę handlową, lepiej postawić obok osobną aplikację B2B z własnym logowaniem, a z Drupala pobierać przez API opisy i materiały produktowe.

Gdzie w tym wszystkim Laravel

Pytanie „Symfony czy Drupal” często w rzeczywistości brzmi „CMS czy framework PHP”. Po stronie frameworków są dwa główne wybory: Symfony i Laravel. Laravel również korzysta z części komponentów Symfony, ale ma inną filozofię – więcej konwencji i gotowych rozwiązań „od ręki” (kolejki, powiadomienia, harmonogram zadań, panel przez gotowe pakiety), co zwykle skraca start projektu. Symfony daje więcej swobody w konfiguracji i jest częstym wyborem w dużych zespołach z rozbudowaną architekturą.

Różnice między tymi dwoma frameworkami w kontekście systemów handlowych opisujemy osobno w porównaniu Laravel vs Symfony dla systemu B2B. Na co dzień pracujemy głównie w Laravel – więcej o tym, jak prowadzimy takie projekty, znajdziesz na stronie software house Laravel.

Koszt, o którym mało kto mówi: aktualizacje głównych wersji

Koszt budowy to tylko początek. W horyzoncie pięciu–ośmiu lat więcej waży koszt utrzymania.

Drupal. Przejście z Drupala 7 na 8 było w praktyce budową serwisu od nowa, a wsparcie Drupala 7 zakończyło się w styczniu 2025 roku. Od wersji 8 aktualizacje głównych wersji są znacznie łagodniejsze: nowa wersja usuwa kod oznaczony wcześniej jako przestarzały, a narzędzia takie jak moduł Upgrade Status pokazują, co trzeba poprawić. Łagodniejsze nie znaczy jednak darmowe. Każdy moduł społecznościowy musi być zgodny z nową wersją, a moduły porzucone przez autorów trzeba zastąpić albo przejąć. Serwis z kilkudziesięcioma modułami kontrybucyjnymi i własnymi poprawkami potrafi mieć przy migracji więcej pracy niż ten z kilkunastoma.

Symfony. Symfony wydaje wersje według przewidywalnego harmonogramu, a wersje LTS mają kilkuletnie wsparcie. Aktualizacja dotyczy frameworka i bibliotek, które sam dobrałeś – nie ma warstwy modułów społeczności, od której zależy działanie całego serwisu. Za to cały kod aplikacji jest Twój i Ty odpowiadasz za jego aktualność.

Wniosek: Drupal obniża koszt budowy funkcji redakcyjnych, ale każdy dodatkowy moduł to przyszła pozycja w budżecie aktualizacji. Framework wymaga więcej pracy na starcie, ale zależności są pod Twoją kontrolą. Harmonogramy wsparcia obu projektów warto sprawdzić na ich oficjalnych stronach przed decyzją, bo zmieniają się z każdym wydaniem.

Bezpieczeństwo, wydajność i ludzie

Bezpieczeństwo. Drupal ma zespół bezpieczeństwa, który publikuje komunikaty dla rdzenia i modułów objętych jego polityką. To duża zaleta, pod warunkiem że ktoś te komunikaty czyta i wdraża poprawki w ciągu dni, a nie kwartałów. Popularność Drupala sprawia też, że znane podatności są szybko wykorzystywane automatycznie. W aplikacji frameworkowej powierzchnia ataku jest mniejsza, bo nie ma w niej funkcji, których nie potrzebujesz, ale za bezpieczeństwo własnego kodu odpowiada wyłącznie Twój zespół.

Wydajność. Drupal ma rozbudowany system cache i dobrze radzi sobie z ruchem anonimowym na treściach. Trudniej jest przy dużej liczbie zalogowanych użytkowników, z których każdy widzi inne dane – a tak wygląda typowy portal B2B z cenami indywidualnymi. We frameworku projektujesz cache pod konkretne dane, co przy takim profilu ruchu jest prostsze.

Ludzie. Specjalistów Drupala jest na rynku mniej niż programistów PHP pracujących w Laravel czy Symfony. Zanim wybierzesz technologię, sprawdź, kto będzie system rozwijał za trzy lata i czy łatwo będzie znaleźć zastępstwo.

Rozwiązania mieszane

Coraz częściej odpowiedź brzmi „jedno i drugie, ale z jasnym podziałem”:

• Drupal jako źródło treści, aplikacja frameworkowa jako system transakcyjny. Redakcja pracuje w Drupalu, aplikacja B2B pobiera treści przez JSON:API i sama obsługuje logowanie, ceny i zamówienia.
• Headless Drupal z frontendem w Vue.js lub React. Drupal jest tylko zapleczem redakcyjnym, a warstwę prezentacji buduje się osobno. Ma to sens przy rozbudowanym interfejsie, ale dodaje drugi projekt do utrzymania.
• Framework z prostym modułem treści. Jeśli treści to kilkanaście stron i blog, prosty moduł w panelu aplikacji wystarczy i nie ma powodu utrzymywać osobnego CMS.

Warunek powodzenia każdego z tych modeli jest ten sam: jeden system jest właścicielem danej informacji. Opis produktu żyje w jednym miejscu, cena w drugim, i nikt nie edytuje ich w dwóch panelach naraz.

Lista decyzyjna

Odpowiedz na poniższe pytania. Im więcej odpowiedzi po stronie „treść”, tym mocniej wskazują na Drupala:

1. Kto będzie głównym użytkownikiem panelu? Redaktorzy i marketing – Drupal. Handlowcy, obsługa klienta, logistyka – framework.
2. Co jest najważniejszym obiektem? Artykuł, strona, dokument – Drupal. Zamówienie, klient, oferta, zlecenie – framework.
3. Ile integracji z systemami transakcyjnymi? Brak lub jedna prosta – Drupal. Kilka, z zapisem danych do ERP – framework.
4. Czy potrzebujesz obiegu publikacji i wersji treści? Tak – Drupal ma je w rdzeniu. Nie – nie płać za nie.
5. Jak wygląda zespół po wdrożeniu? Dostęp do specjalistów Drupala – Drupal. Zespół PHP pracujący w Laravel lub Symfony – framework.
6. Jak długo system ma żyć? W obu przypadkach zaplanuj budżet na aktualizacje głównych wersji co kilka lat.

Jeśli odpowiedzi rozkładają się mniej więcej po równo, to zwykle znak, że potrzebujesz dwóch systemów z jasnym podziałem, a nie jednego, który robi wszystko. Przy wyborze technologii dla całego projektu pomocny może być też nasz tekst o tym, jak wybrać stack technologiczny dla aplikacji B2B.

Co zrobić przed decyzją

Spisz na jednej stronie trzy najważniejsze procesy, które system ma obsłużyć, i kto będzie w nich pracował. To wystarczy, żeby ocenić, czy mówimy o CMS, aplikacji, czy o obu. Jeśli masz już serwis w Drupalu i zastanawiasz się, czy rozbudowywać go o funkcje handlowe, czy postawić obok osobny system, opisz nam swoją sytuację – powiemy wprost, która droga będzie tańsza w utrzymaniu, także jeśli okaże się, że to nie my powinniśmy ją budować.