Wiele działających od lat sklepów internetowych oraz hurtowni B2B wciąż opiera swoją sprzedaż na systemie Drupal 7 Commerce. Katalog generuje stabilne przychody, wyszukiwarki przez dekadę zaindeksowały ponad tysiąc stron produktów i kategorii, a zespół obsługi zna na pamięć każdy ekran w panelu administracyjnym. Jednocześnie wsparcie dla Drupala 7 oficjalnie wygasło, karty produktów na telefonach ładują się cztery sekundy, a każda próba zmiany reguł dostawy lub płatności grozi awarią starego modułu PHP.
Kiedy właściciele takich sklepów proszą tradycyjne agencje o wycenę migracji, zazwyczaj otrzymują zaporową ofertę: od sześciu do dziewięciu miesięcy przepisywania całego monolitu na Drupal 10 Commerce lub Magento za ponad 60 000 €, z budową każdego szablonu i modułu od zera.
Migracja w architekturze rozdzielonej (decoupled) dzieli ten problem na dwie znacznie prostsze części. Zamiast zmuszać ciężką bazę danych PHP do generowania kodu przy każdej wizycie klienta, warstwa frontowa w Astro renderuje z wyprzedzeniem ponad 1600 adresów URL produktów i kategorii jako błyskawiczny statyczny HTML. Równolegle lekki backend e-commerce obsługuje przez API stany magazynowe na żywo, ceny wariantów, koszyk i bramki płatnicze. Sklep zachowuje dokładnie te same adresy URL oraz pozycje w Google, strony na telefonach otwierają się w ułamku sekundy, a całe wdrożenie zamyka się w tygodniach zamiast kwartałów.
Główne wnioski
- Dlaczego migracje Drupal 7 Commerce utykają w martwym punkcie: W przeciwieństwie do zwykłych stron firmowych, Drupal 7 Commerce łączy encje
commerce_productz węzłami wyświetlanianode, wywołaniami AJAX przy zmianie wariantów, regułami podatkowymi oraz historią zamówień. - Audyt 1600 adresów URL przed startem: Zanim powstanie wycena i pierwsza linijka kodu, skanujemy mapę strony oraz bazę danych, oddzielając publiczne podstrony SEO (~1400 produktów, ~160 kategorii, ~40 artykułów) od punktów transakcyjnych (koszyk, zamówienia, konto klienta).
- Architektura Astro + Headless API: Wstępne generowanie kart produktów w Astro eliminuje ponad 30 zapytań MySQL przy każdym wyświetleniu strony, pozostawiając dynamiczną logikę koszyka i płatności w czystym API.
- Realny czas i budżet: Przeniesienie średniego sklepu (ok. 1600 adresów URL) z Drupal 7 Commerce na frontend Astro i nowoczesny silnik e-commerce zajmuje zazwyczaj od 5 do 8 tygodni i kosztuje o 40% do 55% mniej niż pełna przebudowa monolityczna na Drupal 10.
Dlaczego migracja Drupal 7 Commerce jest trudniejsza niż aktualizacja zwykłego CMS-a
Migracja Drupal 7 Commerce stanowi szczególne wyzwanie, ponieważ produkty i strony wyświetlania są zapisane w bazie jako osobne encje połączone polami referencyjnymi, przez co prosty eksport bazy psuje wybór wariantów, kanoniczne adresy URL oraz historię zamówień.
W naszym wcześniejszym studium przypadku pokazaliśmy, jak przyspieszyliśmy korporacyjną stronę na Drupalu 7 z wyniku PageSpeed 15 do 98 bez utraty ruchu SEO. W przypadku sklepu na Drupal 7 Commerce dochodzą jednak cztery warstwy transakcyjne, których automatyczne kreatory migracji nie potrafią przenieść jeden do jednego:
- Podział na stronę wyświetlania (Node) i warianty SKU (Commerce Product): W Drupalu 7 adres URL odwiedzany przez klienta to zazwyczaj standardowy węzeł
node, który odwołuje się do kilku lub kilkunastu rekordówcommerce_product(rozmiarów, kolorów, pojemności lub opakowań zbiorczych). Gdy kupujący zmienia wariant z listy rozwijanej, Drupal 7 wysyła powolne zapytanie AJAX (/system/ajax) do serwera, aby przeliczyć cenę, kod SKU i podmienić zdjęcie. - Złożone reguły cenowe i podatkowe: Rabaty ilościowe, cenniki hurtowe B2B, progi darmowej dostawy oraz stawki VAT często znajdują się w starych konfiguracjach modułu
Rulesalbo w pisanych lata temu funkcjach PHPhook_commerce_cart_line_item_refresh. - Nawarstwione przez lata adresy URL w indeksie Google: Przez osiem lub dziesięć lat działania sklepu filtry kategorii, wycofane warianty sezonowe i duplikaty ścieżek taksonomii potrafią zmienić katalog 300 produktów w ponad 1600 zaindeksowanych adresów URL w Google Search Console.
- Wymogi bezpieczeństwa bramek płatniczych: Stare moduły PHP obsługujące płatności Stripe, PayPal, Przelewy24 czy PayU korzystają z nieaktualnych bibliotek, które nie spełniają dzisiejszych wymogów PCI-DSS v4.0 oraz silnego uwierzytelniania (SCA).
Stary Drupal 7 Commerce
Ciężki monolit PHPKażde wyświetlenie produktu i zmiana wariantu uruchamia hooki PHP oraz łączenia tabel MySQL po stronie serwera.
- Od 400 ms do 900 ms opóźnienia przy zmianie wariantu
- Brak łat bezpieczeństwa dla PHP i modułów D7
- Mobilny PageSpeed zablokowany na poziomie 22-38 / 100
Frontend Astro + Commerce API
Architektura rozdzielonaKarty produktów i kategorii są gotowym kodem HTML z wbudowanymi wariantami JSON; koszyk i płatności działają przez szybkie API.
- Natychmiastowa zmiana wariantu i zdjęcia w przeglądarce
- 100% zachowania dotychczasowych adresów URL
- Mobilny PageSpeed 95+ i zielone Core Web Vitals
Krok 1: Audyt 1600 adresów URL przed napisaniem pierwszej linijki kodu
Bezpieczna migracja zaczyna się od automatycznego przeskanowania mapy strony, tabel bazy danych oraz zapytań sieciowych, aby precyzyjnie oddzielić statyczną część katalogową od dynamicznych procesów koszyka i płatności.
Przy wycenie sklepu obejmującego około 1600 publicznych adresów URL szacowanie prac na podstawie samej strony głównej zawsze kończy się przekroczeniem budżetu. Przed zamknięciem specyfikacji przeprowadzamy inwentaryzację techniczną w czterech obszarach:
| Warstwa audytu | Co sprawdzamy w sklepie z 1600 URL-ami | Typowe znaleziska w praktyce | Decyzja migracyjna |
|---|---|---|---|
| 1. Mapa strony i adresy URL | sitemap.xml, tabela url_alias oraz 1000 najważniejszych podstron z Google Search Console | ~1400 adresów produktów i wariantów, ~160 stron kategorii, ~40 stron poradnikowych oraz setki martwych linków z filtrów | Zachowujemy 1:1 ścieżki URL dla wszystkich stron generujących ruch; wygasłe parametry filtrów przekierowujemy regułami 301. |
| 2. Schemat katalogu i wariantów | Tabele commerce_product, field_data_commerce_price, słowniki taksonomii i załączniki PDF/zdjęcia | Od 2 do 8 wariantów SKU na jedną kartę produktu, dodatkowe pola z wymiarami i kartami technicznymi, nieskompresowane pliki JPEG | Eksportujemy uporządkowany katalog do JSON/SQL i osadzamy wszystkie warianty bezpośrednio w danych podstrony Astro. |
| 3. Reguły koszyka i promocji | Tabela rules_config, tabele wagowe dostaw, kody rabatowe i reguły VAT dla B2B | Zwykle od 3 do 5 aktywnych reguł cenowych i wysyłkowych obok 25 nieużywanych reguł z dawnych kampanii promocyjnych | Przepisujemy wyłącznie aktywne reguły cenowe i kosztu dostawy jako przejrzyste funkcje w TypeScript lub Pythonie objęte testami. |
| 4. Płatności i integracje ERP | Webhooki bramek płatniczych, synchronizacja stanów magazynowych z ERP i powiadomienia e-mail | Bezpośrednie zapisy do bazy danych lub kruche zadania cron wymieniające pliki XML z systemem magazynowym | Zastępujemy bezpośrednie łączenie z bazą bezpieczną kolejką webhooków między nowym API koszyka a systemem ERP. |
Krok 2: Jak działa rozdzielona architektura Astro Storefront w praktyce
Rozdzielona architektura serwuje strony produktów i kolekcji jako gotowy, statyczny kod HTML wygenerowany w Astro, dołączając lekkie komponenty interaktywne wyłącznie tam, gdzie klient wybiera wariant, sprawdza dostępność lub finalizuje zamówienie.
Usunięcie wąskiego gardła /system/ajax na kartach produktów
W klasycznym sklepie na Drupal 7 Commerce kliknięcie innego rozmiaru, pojemności lub wersji produktu wysyła zapytanie POST do /system/ajax. Na połączeniu mobilnym klient czeka prawie sekundę, zanim zobaczy zaktualizowaną cenę i zdjęcie.
W architekturze opartej na Astro wszystkie warianty danego produktu są zapisywane w lekkim (ok. 2 KB) obiekcie JSON osadzonym bezpośrednio w kodzie HTML podczas budowania strony. Gdy kupujący wybiera inny wariant, niewielki skrypt w przeglądarce podmienia cenę, kod SKU, zdjęcie w galerii oraz dane strukturalne Offer w mniej niż 15 milisekund bez odpytywania serwera. Równoległe, asynchroniczne zapytanie do API potwierdza aktualny stan magazynowy, nie blokując ładowania strony.
Dobór odpowiedniego silnika e-commerce na zapleczu
W zależności od tego, jak zespół zarządza katalogiem i zamówieniami, łączymy frontend Astro z jednym z trzech rozwiązań backendowych:
- Headless Medusa.js lub Saleor (własny serwer VPS w UE): Najlepszy wybór przy braku prowizji od obrotu, pełnej kontroli nad bazą PostgreSQL, indywidualnych cennikach B2B oraz bezpośredniej integracji z systemem ERP.
- Shopify Storefront API (Headless): Rozwiązanie dla marek konsumenckich, które chcą korzystać z gotowego koszyka i panelu Shopify, ale muszą zachować swoją dotychczasową strukturę adresów URL z Drupala (bez przymusowych prefiksów
/products/i/collections/). - Dedykowany lekki backend PostgreSQL/SQLite + Stripe/PayU: Optymalny dla przejrzystych katalogów (do 2000 SKU), w których ceny i stany magazynowe pochodzą bezpośrednio z systemu ERP klienta, a utrzymywanie rozbudowanego kombajnu e-commerce jest zbędne.
Przebudowa na Drupal 10 Commerce vs Astro + Headless API: porównanie kosztów i czasu
Przepisanie sklepu z Drupal 7 na Drupal 10 Commerce wymaga jednoczesnej migracji struktur bazodanowych oraz budowy złożonych szablonów Twig/PHP, natomiast oddzielenie warstwy frontowej w Astro skraca czas wdrożenia o połowę i eliminuje kosztowne aktualizacje bezpieczeństwa CMS-a.
| Kryterium porównania | Monolityczna aktualizacja (Drupal 7 do Drupal 10 Commerce) | Przejście na standardowy szablon Shopify Plus / Magento | Rozdzielony frontend Astro + Headless Commerce API |
|---|---|---|---|
| Typowy czas wdrożenia | Od 5 do 9 miesięcy | Od 3 do 6 miesięcy | Od 5 do 8 tygodni |
| Szacunkowy budżet wdrożeniowy | Od 35 000 € do 75 000+ € | Od 25 000 € do 60 000 € | Od 14 000 € do 28 000 € (zależnie od integracji z ERP i logiki koszyka) |
| Zachowanie dotychczasowych adresów URL | Wysokie (przy poprawnej migracji aliasów pathauto) | Niskie w Shopify (wymuszone prefiksy /products/ wymagają ponad 1600 przekierowań 301) | 100% zgodności ścieżek URL (brak wymuszonych zmian struktury linków) |
| Wynik mobilny PageSpeed (LCP / INP) | 55 do 75 (nadal ograniczony przez PHP/Twig i zapytania do bazy) | 45 do 70 (szablony Liquid i zewnętrzne skrypty wtyczek) | 95 do 100 (statyczny HTML + obrazy AVIF z sieci CDN) |
| Miesięczny koszt utrzymania serwerów | Od 150 € do 500 €/mies. za zarządzany hosting PHP/MySQL i łaty bezpieczeństwa | Od 300 € do 2300 €/mies. opłat licencyjnych + prowizje od transakcji | Od 20 € do 60 €/mies. na europejskim serwerze VPS i CDN |
Najczęściej zadawane pytania (FAQ)
Co dzieje się z kontami klientów, hasłami i historią zamówień z Drupala 7?
Przenosimy konta klientów, adresy dostaw oraz historię dotychczasowych zamówień do nowej bazy danych, dzięki czemu stali klienci po zalogowaniu widzą swoje wcześniejsze zakupy. Ponieważ Drupal 7 zapisuje hasła za pomocą starszego algorytmu SHA-512 z solą ($S$...), wdrażamy most weryfikacyjny, który przy pierwszym logowaniu klienta automatycznie aktualizuje skrót hasła do nowoczesnego standardu Argon2 lub bcrypt, albo uruchamiamy wygodne logowanie jednorazowym kodem wysyłanym na e-mail.
Czy stracimy pozycje w Google po odejściu od Drupala 7?
Nie, pod warunkiem zachowania identycznych ścieżek URL, tagów kanonicznych, hierarchii nagłówków oraz danych strukturalnych produktu (Product, Offer oraz BreadcrumbList w JSON-LD). Wyszukiwarka Google ocenia ciągłość adresów URL, treść oraz szybkość ładowania strony niezależnie od tego, czy kod HTML wygenerował Drupal, czy Astro. Przed przełączeniem domeny uruchamiamy automatyczny skaner porównujący wszystkie ponad 1600 adresów na środowisku testowym z wersją produkcyjną.
Jak nasz zespół będzie zmieniać ceny, stany magazynowe i opisy produktów po migracji?
Zespół nadal pracuje w przejrzystym panelu administracyjnym w przeglądarce (lub bezpośrednio w dotychczasowym systemie ERP/magazynowym). Każda zmiana ceny, zdjęcia lub opisu automatycznie przebudowuje w kilka sekund konkretną kartę produktu w Astro, natomiast stany magazynowe i ceny w koszyku aktualizują się natychmiast przez API.
Zamów wycenę i audyt migracji swojego sklepu
Jeśli Twój sklep internetowy lub katalog B2B wciąż działa na niewspieranym Drupalu 7 Commerce, Magento 1 lub przeciążonym WooCommerce, nie podpisuj w ciemno umowy na dziewięciomiesięczne przepisywanie systemu. Prześlij nam adres swojej domeny. Przeskanujemy publiczną mapę strony, sprawdzimy złożoność wariantów oraz koszyka i przygotujemy konkretny plan architektoniczny ze stałym harmonogramem i budżetem.
Zobacz nasze usługi modernizacji systemów webowych lub zamów techniczny audyt strony, aby sprawdzić dokładny zakres migracji swojego katalogu.
