Konfiguracja PrestaShop Multistore: Kompletny przewodnik

Czym jest PrestaShop Multistore?

PrestaShop Multistore pozwala prowadzić wiele sklepów internetowych z jednej instalacji i jednego back office. Wspólna baza kodu, wspólna baza danych, wspólny ekosystem modułów, ale osobne witryny sklepowe dla Twoich klientów. Funkcja jest obecna w PrestaShop od wersji 1.5 i znacznie dojrzała w wersjach 8.x oraz 9.x — choć nadal wymaga starannego planowania.

Kiedy naprawdę potrzebujesz Multistore

Wiele marek z jednego back office. Sprzedajesz elektronikę pod marką „TechDirect” i sprzęt audio pod „SoundElite”. Obie marki korzystają z Twojego magazynu i części produktów, ale każda ma własną stronę, motyw i cennik. Twój zespół zarządza wszystkim z jednego panelu administracyjnego.

Różne kraje z osobnymi katalogami. Twój niemiecki i francuski sklep dzielą część produktów, ale różnią się asortymentem, cenami, regułami wysyłki i treścią CMS. Multistore pozwala każdemu sklepowi utrzymywać własny katalog, jednocześnie współdzieląc część wspólną.

B2B i B2C z jednej instalacji. Sklep detaliczny wyświetla ceny brutto ze standardową wysyłką. Sklep hurtowy pokazuje ceny netto, wymaga minimalnych ilości i oferuje wynegocjowane stawki. Jeden katalog produktów, dwa zupełnie różne doświadczenia zakupowe.

Sklep outletowy lub wyprzedażowy. Osobna witryna sklepowa dla produktów w obniżonych cenach z własnym motywem, korzystająca z tej samej bazy produktów.

Kiedy Multistore NIE jest odpowiedzią

• Niepowiązane biznesy: Artykuły zoologiczne i maszyny przemysłowe nie mają nic wspólnego. Osobne instalacje są prostsze.
• Potrzeba różnych wersji PS: Multistore wymaga, aby wszystkie sklepy działały na tej samej wersji.
• Sprzeczne wymagania modułów: Jeśli sklepy potrzebują niekompatybilnych modułów, osobne instalacje pozwalają uniknąć konfliktów.
• Izolacja ryzyka: Problem z bazą danych w multistore wpływa na wszystkie sklepy. Osobne instalacje ograniczają zasięg awarii.
• Potrzebujesz tylko wielu języków: PrestaShop natywnie obsługuje wielojęzyczność w ramach jednego sklepu — multistore nie jest potrzebny.

Przed włączeniem multistore wypisz, co chcesz współdzielić między sklepami, a co musi być osobne. Jeśli lista „wspólne” jest krótka, a lista „osobne” długa, lepiej zdecydować się na niezależne instalacje.

Planowanie architektury

Grupy sklepów

PrestaShop organizuje multistore jako Grupa sklepów → Sklep. Grupy definiują zasady współdzielenia, które są trudne do zmiany później:

• Współdzielenie klientów: Czy klient zarejestrowany w Sklepie A może się zalogować również w Sklepie B?
• Współdzielenie dostępnych ilości: Czy sprzedaż w Sklepie A zmniejsza stan magazynowy widoczny w Sklepie B?

Wspólny vs. osobny katalog

Produkty mogą być przypisane do wszystkich sklepów lub tylko do wybranych. Nawet współdzielone produkty mogą mieć różne ceny, opisy, zdjęcia i metadane SEO w każdym sklepie. Kategorie działają analogicznie — wspólne lub specyficzne dla sklepu, z indywidualnymi nazwami i opisami.

Strategia URL

• Osobne domeny (brand-a.com, brand-b.com) — najlepsze dla odrębnych marek. Wymagają osobnych certyfikatów SSL lub certyfikatu wielodomenowego.
• Subdomeny (de.myshop.com, fr.myshop.com) — naturalne rozwiązanie dla wariantów regionalnych. Można użyć certyfikatu wildcard SSL.
• Podkatalogi (myshop.com/wholesale/) — najprostsza konfiguracja, jeden certyfikat SSL, ale ogranicza elastyczność SEO.

Architektura bazy danych

Multistore używa jednej bazy danych z kolumnami id_shop różnicującymi dane. Jeden backup obejmuje wszystkie sklepy, ale uszkodzenie również dotyczy wszystkich sklepów, a zapytania obarczone są narzutem filtrowania po sklepie.

Włączanie i konfiguracja Multistore

Krok 1: Włącz funkcję

Przejdź do Advanced Parameters → General (PS 1.7.x) lub Advanced Parameters → Multistore (PS 8.x/9.x). Ustaw Enable Multistore na Yes. W nagłówku back office pojawi się selektor kontekstu sklepu.

Krok 2: Utwórz grupę sklepów

W Advanced Parameters → Multistore kliknij Add a new shop group. Ustaw nazwę grupy i opcje współdzielenia (klienci, ilości). Pamiętaj: te ustawienia są trudne do zmiany później.

Krok 3: Dodaj nowy sklep

Kliknij Add a new shop. Wybierz nazwę, grupę, kategorię główną i opcjonalnie zaimportuj dane z istniejącego sklepu, aby zaoszczędzić czas konfiguracji.

Krok 4: Skonfiguruj adresy URL

Kliknij nazwę sklepu i dodaj adres URL. Przykłady:

# Separate domain
Domain: www.my-second-shop.com
Physical URI: /
Virtual URI: (empty)

# Subdomain
Domain: shop2.myshop.com
Physical URI: /
Virtual URI: (empty)

# Subdirectory
Domain: www.myshop.com
Physical URI: /
Virtual URI: wholesale/

Krok 5: Konfiguracja serwera

W przypadku osobnych domen/subdomen wszystkie domeny muszą wskazywać na ten sam katalog PrestaShop w konfiguracji serwera WWW. Dla wirtualnych adresów URL (podkatalogów) dodatkowa konfiguracja serwera zazwyczaj nie jest potrzebna — PrestaShop obsługuje routing przez .htaccess.

Po skonfigurowaniu adresów URL zawsze wyczyść cache PrestaShop. Routing URL jest agresywnie cache’owany, a przestarzałe wpisy powodują pętle przekierowań.

Zarządzanie treścią w wielu sklepach

Selektor kontekstu sklepu

Lista rozwijana w górnej części back office kontroluje, którego sklepu dotyczą Twoje zmiany: All shops, konkretna grupa lub konkretny sklep. Złota zasada: zawsze pracuj w najbardziej szczegółowym kontekście. Edytowanie w trybie „All shops”, gdy chciałeś zmienić tylko jeden sklep, to najczęstszy błąd w multistore.

Dziedziczenie konfiguracji

Wartości ustawione w „All shops” stają się wartościami domyślnymi. Poszczególne sklepy mogą je nadpisać. Na stronie konfiguracji checkboxy obok pól kontrolują, czy pole używa wartości dziedziczonej, czy nadpisanej dla danego sklepu. Odznacz, aby ustawić własną wartość dla bieżącego sklepu.

Zachowanie checkboxów dziedziczenia zmieniało się między wersjami PrestaShop. Zawsze przetestuj na swojej konkretnej wersji, aby zrozumieć, który stan oznacza „dziedziczone”, a który „własne”.

Produkty i kategorie

Kluczowe zachowania:

• Utworzenie produktu w kontekście „All shops” udostępnia go wszędzie.
• Utworzenie w kontekście konkretnego sklepu ogranicza go do tego sklepu. Możesz później przypiąć go do innych.
• Wyłączenie produktu w jednym sklepie nie wpływa na inne sklepy.
• Usunięcie w „All shops” trwale usuwa go zewsząd.
• Zachowanie stanów magazynowych zależy od ustawień współdzielenia w grupie.

Motyw, język i waluta per sklep

Każdy sklep może mieć własny motyw, własny zestaw włączonych języków i własne waluty. Najpierw wybierz kontekst sklepu, a następnie skonfiguruj w Design → Theme & Logo lub International → Localization.

Zachowanie modułów w Multistore

Jak działają moduły obsługujące Multistore

Prawidłowo zbudowany moduł przechowuje konfigurację per sklep (używając Configuration::updateValue(), które respektuje kontekst sklepu), sprawdza Shop::getContextShopID() w hookach i prawidłowo obsługuje kontekst „All shops”. Tabela ps_configuration przechowuje wartości per sklep z kolumną id_shop.

Typowe problemy z modułami

• Tylko globalna konfiguracja: Moduł zapisuje ustawienia bez id_shop — zmiana jednego sklepu zmienia wszystkie.
• Zakodowane na sztywno ID sklepu: Moduł zakłada id_shop = 1, ignorując pozostałe sklepy.
• Brak filtra sklepu w zapytaniach: Zwraca pomieszane dane ze wszystkich sklepów.
• Kolizje cache: Klucze cache bez ID sklepu serwują dane niewłaściwego sklepu.

Sprawdzanie obsługi Multistore w module

• Czy opis wspomina o „multistore compatible”?
• Czy istnieje dokumentacja dotycząca konfiguracji per sklep?
• Czy po zainstalowaniu strona konfiguracji wyświetla checkboxy dziedziczenia w kontekście konkretnego sklepu?
• Test: ustaw różne konfiguracje w dwóch sklepach i sprawdź, czy obie witryny odzwierciedlają różnicę.

Moduł nieobsługujący multistore niekoniecznie zepsuje sklep — ale wszystkie sklepy będą współdzielić jego ustawienia. To może, ale nie musi być akceptowalne w zależności od funkcji modułu.

Kwestie SEO

Adresy kanoniczne

Każda strona w każdym sklepie musi mieć adres kanoniczny wskazujący na siebie. Zweryfikuj, że produkt na shop-a.com ma canonical wskazujący na shop-a.com, a nie na shop-b.com. W przypadku identycznej treści między sklepami zdecyduj o jednym głównym źródle i zaimplementuj międzydomenowe adresy kanoniczne.

Hreflang dla sklepów wielojęzycznych

Jeśli sklepy są skierowane do różnych języków/regionów, tagi hreflang informują wyszukiwarki, którą wersję pokazać poszczególnym odbiorcom:

<link rel="alternate" hreflang="de" href="https://de.myshop.com/produkt" />
<link rel="alternate" hreflang="fr" href="https://fr.myshop.com/produit" />
<link rel="alternate" hreflang="x-default" href="https://www.myshop.com/product" />

PrestaShop obsługuje hreflang dla wariantów językowych w ramach jednego sklepu, ale nie między osobnymi sklepami. Do międzysklepowego hreflang potrzebujesz modułu lub modyfikacji szablonów. Tagi muszą być dwukierunkowe — jeśli Sklep A odwołuje się do Sklepu B, Sklep B musi odwoływać się do Sklepu A.

Mapy witryn i duplikacja treści

Każdy sklep potrzebuje własnego sitemap.xml zawierającego wyłącznie jego adresy URL. Każdy sklep zarejestruj osobno w Google Search Console. Aby uniknąć kar za duplikację treści: dostosuj opisy produktów per sklep, używaj tagów kanonicznych dla współdzielonej treści i wyróżniaj strony kategorii unikalnymi opisami.

W przypadku sklepów wielojęzycznych na osobnych domenach tagi hreflang są wymagane, a nie opcjonalne. Bez nich wyszukiwarki mogą indeksować niewłaściwy język dla każdego rynku.

Wpływ na wydajność

Multistore dodaje narzut w trzech obszarach:

• Tabele konfiguracji: N wierszy na ustawienie (jeden per sklep) zamiast jednego. Więcej danych przy każdym odczycie konfiguracji.
• Zapytania SQL: Prawie każde zapytanie zyskuje klauzulę WHERE id_shop = X. Bez odpowiednich indeksów spowalnia to działanie wraz ze wzrostem bazy danych.
• Rozmiar cache: Każdy sklep ma własne wpisy cache dla szablonów, konfiguracji i list. Pamięć skaluje się z liczbą sklepów, a rozgrzewanie cache trwa dłużej.

W przypadku Redis/Memcached zweryfikuj, czy prefiksy kluczy cache zawierają ID sklepu, aby zapobiec wyciekom danych między sklepami. Monitoruj bazę danych tymi zapytaniami:

# Check table sizes
SELECT table_name, ROUND(data_length/1024/1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'prestashop'
ORDER BY data_length DESC LIMIT 20;

# Find missing indexes on id_shop columns
SELECT t.table_name, c.column_name
FROM information_schema.columns c
JOIN information_schema.tables t
  ON c.table_schema = t.table_schema AND c.table_name = t.table_name
WHERE c.table_schema = 'prestashop' AND c.column_name = 'id_shop'
  AND c.column_name NOT IN (
    SELECT column_name FROM information_schema.statistics
    WHERE table_schema = 'prestashop' AND table_name = c.table_name
  );

Typowe problemy z Multistore

Produkty w niewłaściwym sklepie

Przyczyna: Produkt utworzony w kontekście „All shops”. Rozwiązanie: Przełącz się na kontekst niepożądanego sklepu i wyłącz/usuń przypisanie produktu. Zweryfikuj zapytaniem:

SELECT ps.id_product, ps.id_shop, ps.active
FROM ps_product_shop ps WHERE ps.id_product = 123;

Zmiany konfiguracji wpływające na wszystkie sklepy

Przyczyna: Byłeś w kontekście „All shops” lub moduł zapisuje wartości globalnie. Sprawdź sposób przechowywania:

SELECT id_shop, name, value FROM ps_configuration
WHERE name = 'MODULE_SETTING_NAME' ORDER BY id_shop;

Jeśli jest tylko jeden wiersz z id_shop = NULL, moduł przechowuje dane globalnie. Skontaktuj się z dostawcą lub ręcznie utwórz wpisy per sklep.

Moduł nie zapisuje ustawień per sklep

Przyczyna: Moduł używa Configuration::updateGlobalValue() zamiast Configuration::updateValue(). Wymaga poprawki w kodzie modułu lub aktualizacji od dostawcy.

Mieszane koszyki między sklepami

Przyczyna: Domena cookie ustawiona zbyt szeroko (np. .myshop.com zamiast shop-a.myshop.com). Popraw w Shop Parameters → General — ustaw domenę cookie na konkretną subdomenę per sklep.

Import umieszcza produkty w złym sklepie

Przyczyna: Narzędzie importu respektuje bieżący kontekst. Zawsze wybierz docelowy sklep przed otwarciem strony importu. Po imporcie zweryfikuj wpisy w ps_product_shop.

Pętle przekierowań po dodaniu sklepu

Przyczyna: Nieprawidłowa konfiguracja URL lub przestarzały .htaccess. Rozwiązanie: wygeneruj ponownie .htaccess z ustawień wydajności, zweryfikuj wpisy w ps_shop_url i upewnij się, że konfiguracja SSL jest spójna:

SELECT s.name, su.domain, su.domain_ssl, su.physical_uri, su.virtual_uri
FROM ps_shop s
JOIN ps_shop_url su ON s.id_shop = su.id_shop AND su.main = 1;

Lista kontrolna utrzymania Multistore

Co tydzień

• Sprawdź, czy witryna każdego sklepu się ładuje (brak przekierowań, brak błędów)
• Zweryfikuj, czy ostatnie zamówienia są przypisane do właściwego sklepu
• Przetestuj proces checkout w każdym sklepie

Co miesiąc

• Przeprowadź audyt przypisania produktów — czy jakieś produkty są w niewłaściwych sklepach?
• Przejrzyj konfiguracje per sklep, przełączając się na każdy kontekst
• Sprawdź logi błędów per sklep
• Zweryfikuj, czy mapy witryn są aktualne i dostępne
• Przetestuj doręczanie e-maili z każdego sklepu
• Monitoruj przyrost rozmiaru bazy danych

Po aktualizacjach modułów

• Sprawdź stronę konfiguracji modułu w kontekście każdego sklepu
• Zweryfikuj zachowanie front-endu per sklep
• Potwierdź, że ustawienia per sklep zapisują się niezależnie
• Wyczyść cache dla wszystkich sklepów

Po aktualizacjach PrestaShop

• Natychmiast przetestuj wszystkie sklepy — regresje multistore są częste
• Ponownie sprawdź konfigurację URL
• Wygeneruj ponownie .htaccess
• Przetestuj pełny checkout w każdym sklepie

Podsumowanie

PrestaShop Multistore centralizuje operacje, gdy odpowiada Twoim potrzebom, ale dodaje złożoność wszędzie. Sprzedawcy, którzy odnoszą sukces, traktują go jako decyzję architektoniczną, a nie przełącznik funkcji. Zaplanuj go dobrze, utrzymuj starannie i zawsze rób kopie zapasowe.

Related: Checkout Revolution · Performance Revolution · Performance Optimization Guide