PrestaShop Multistore: wiele sklepów z jednego panelu administracyjnego

Zweryfikowano w czerwcu 2026 - model grup sklepów / sklepów / adresów URL sklepów oraz ekran Parametry zaawansowane → Multistore dotyczą PrestaShop 1.7, 8 i 9.

PrestaShop Multistore to funkcja, po którą sprzedawcy sięgają wtedy, gdy jeden sklep zmienia się w trzy: niemiecką witrynę sprzedażową, francuską wersję i dział hurtowy. Obietnica brzmi atrakcyjnie - prowadzić je wszystkie z jednego panelu administracyjnego, współdzielić jeden katalog produktów i logować się tylko raz. I w dużej mierze to działa. Ale Multistore nie jest przełącznikiem wielu języków ani sposobem na sklejenie ze sobą niepowiązanych biznesów. To konkretny element architektury PrestaShop, z własnym modelem kontekstu, własnymi pułapkami i jedną decyzją (co współdzielisz, a co rozdzielasz), którą podejmujesz raz i z którą żyjesz przez lata. Ten przewodnik dotyczy właśnie tej architektury i codziennej pracy z nią - tego, co naprawdę daje zaplecze sklepu, gdzie kontekst sklepu może Cię zaboleć i kiedy Multistore jest po prostu złym narzędziem.

Czym Multistore naprawdę jest od strony struktury

Pod spodem PrestaShop Multistore składa się z trzech zagnieżdżonych poziomów. Zrozumienie ich to różnica między pewnym zarządzaniem a przypadkowym uszkodzeniem danych w kilku sklepach naraz:

• Grupy sklepów (tabela shop_group, id_shop_group). Grupa wyznacza granicę współdzielenia. Klienci, zamówienia, dostępne stany magazynowe i koszyki mogą być współdzielone w ramach grupy, ale nigdy między grupami. Jeśli dwa sklepy mają współdzielić logowanie klienta, muszą należeć do tej samej grupy.
• Sklepy (tabela shop, id_shop). Pojedyncza witryna sprzedażowa - z własnym motywem, własnym wyborem produktów z katalogu i własnymi wartościami konfiguracji.
• Adresy URL sklepów (tabela shop_url). Do każdego sklepu prowadzi jedna lub kilka kombinacji domeny i fizycznego URI - myshop.de, myshop.fr albo shop.example.com/de. To właśnie ten mechanizm mapuje przychodzące żądanie na właściwy sklep.

Cały system włącza się w Parametry zaawansowane → Multistore (w starszych instalacjach 1.6 znajdował się w Preferencje → Ogólne → Włącz Multistore). Po włączeniu niemal każda strona zaplecza dostaje w lewym górnym rogu selektor kontekstu sklepu. To najważniejsza kontrolka w instalacji Multistore: decyduje, czy zmiana, którą za chwilę zapiszesz, trafi do Wszystkich sklepów, jednej grupy sklepów, czy pojedynczego sklepu.

Model współdzielenia i nadpisywania

Model współdzielenia nie jest jednym uniwersalnym mechanizmem - działa inaczej dla encji katalogu, a inaczej dla konfiguracji, i ta różnica ma znaczenie. Dla danych katalogowych, takich jak produkty, kategorie i przewoźnicy, PrestaShop przechowuje jeden rekord bazowy i dodaje tabelę powiązań dla poszczególnych sklepów - product_shop, category_shop, carrier_shop i tak dalej - która pozwala danemu sklepowi nadpisać konkretne pola (w przypadku produktu np. cenę, status aktywności, przekierowanie, a nawet nazwę), dziedzicząc resztę. Naprawdę zarządzasz więc jednym produktem, ale jego cena w sklepie francuskim i widoczność w sklepie hurtowym mogą się różnić. Ustawienia działają inaczej: nie są wierszami powiązań, tylko zapisami w tabeli configuration z zakresem sklepu i grupy sklepów, więc wartość może być zapisana globalnie, dla grupy albo dla konkretnego sklepu. Ta warstwowa możliwość nadpisywania to prawdziwa przewaga Multistore nad osobnymi instalacjami: edytujesz raz, a różnicujesz świadomie.

Kiedy Multistore jest właściwym narzędziem

Sklepy krajowe na różnych domenach

Najczystszy przypadek użycia. myshop.de, myshop.fr i myshop.es jako trzy sklepy w jednej grupie, współdzielące produkty i klientów, każdy z własnym motywem, domyślną walutą, domyślnym językiem i regułami podatkowymi. Magazyn jest wspólny, więc nie uzgadniasz trzech osobnych stanów. To Multistore działający dokładnie tak, jak zaprojektowano - ale zwróć uwagę na wyraźną granicę: Multistore obsługuje witryny sklepowe, natomiast sam z siebie nie zapewnia poprawnie zlokalizowanych walut, wyświetlania cen z podatkiem według kraju ani hreflang. To osobne zadania opisane w artykułach sprzedaż w Europie: języki, waluty i podatki oraz tagi hreflang.

Marki premium i budżetowe, jeden magazyn

Te same fizyczne produkty, dwie witryny sprzedażowe o różnych nazwach, motywach i poziomach cen, korzystające z jednego wspólnego magazynu. Nadpisywanie ceny i nazwy produktu per sklep sprawia, że wymaga to kilku kliknięć, a nie duplikowania całego katalogu.

B2B i B2C obok siebie

Sklep detaliczny pokazujący ceny brutto i sklep hurtowy pokazujący ceny netto, minimalne ilości zamówienia oraz płatność fakturą - oba na tej samej bazie produktów. Grupy klientów plus drugi sklep w tej samej grupie dają wspólny magazyn i zupełnie różne zasady handlowe.

Kilka sklepów niszowych z częściowo wspólnym asortymentem

Sklepy ogrodowy, kuchenny i łazienkowy, które współdzielą część katalogu, ale mają odrębną identyfikację marki. To właśnie pokrywanie się asortymentu uzasadnia Multistore; wspólne produkty zarabiają na siebie za każdym razem, gdy aktualizujesz jeden z nich, a zmiana propaguje się dalej.

Kiedy Multistore jest złym narzędziem

Chcesz tylko więcej języków

To najczęstszy błąd. PrestaShop obsługuje wiele języków w pojedynczym sklepie - każde tłumaczalne pole (nazwa produktu, opis, CMS, meta) jest przechowywane per język w tabelach _lang, a języki dodajesz w Międzynarodowe → Lokalizacja → Języki. Jeśli potrzebujesz tylko treści po angielsku i francusku przy tych samych cenach, Multistore dokłada żonglowanie kontekstem bez żadnej korzyści. Zrób to standardowo - zobacz konfigurację sklepu wielojęzycznego.

Sklepy są naprawdę niepowiązane

Karma dla zwierząt i elektronika, brak wspólnych produktów, brak wspólnych klientów, brak wspólnych procesów. W takim przypadku Multistore daje Ci podatek od złożoności bez żadnej korzyści ze współdzielenia. Dwie osobne instalacje są łatwiejsze do zrozumienia, łatwiejsze do niezależnego tworzenia kopii zapasowych i odporne na skażenie zmianą zapisaną w złym kontekście. Multistore zarabia na siebie dzięki nakładaniu się sklepów; przy zerowym pokryciu jest czystym narzutem.

Jedna osoba, już przeciążona

Każda edycja w Multistore niesie pytanie: "w jakim kontekście jestem?" Osoba prowadząca sklep samodzielnie, która raz zapomni o selektorze, może wypchnąć cenę albo wyłączony status do wszystkich sklepów. Jeśli zespół jest mały i nie ma jeszcze dyscypliny pracy z kontekstem, obciążenie poznawcze może kosztować więcej niż osobne instalacje.

Kontekst sklepu: gdzie Multistore naprawdę potrafi ukąsić

Selektor kontekstu nie jest wygodnym dodatkiem - to aktywny zakres, który zmienia działanie przycisku zapisu:

Na stronach produktów, kategorii i konfiguracji w kontekście pojedynczego sklepu zobaczysz przy wielu polach mały checkbox - to przełącznik nadpisania. Zaznacz go, a pole odłączy się od wartości współdzielonej tylko dla tego sklepu. Zostaw niezaznaczony, a sklep będzie dziedziczył wartość. Praktyczna zasada, której się trzymamy: przeczytaj na głos selektor kontekstu, zanim klikniesz Zapisz. Edycja w trybie "Wszystkie sklepy", gdy chodziło Ci o jeden sklep, to najdroższy błąd w Multistore. Nie wyświetla błędu - po cichu robi dokładnie to, co mu polecono, wszędzie.

Współdzielenie danych: decyzja podejmowana raz

Dla każdego typu danych wybierasz współdzielenie albo rozdzielenie podczas tworzenia sklepu, a późniejsza zmiana zdania oznacza migrację. Uczciwe ustawienia domyślne:

• Produkty - zwykle współdzielone. Jeden katalog, nadpisania per sklep dla ceny, nazwy i widoczności. To podstawowa wygrana efektywności.
• Klienci i koszyki - współdzielone w ramach grupy, gdy ta sama osoba ma logować się na różnych rynkach; rozdzielone (różne grupy) dla naprawdę odrębnych marek, gdzie jedna tożsamość klienta nie ma sensu.
• Zamówienia - zawsze zachowują sklep pochodzenia (każde zamówienie ma swoje id_shop). Jeśli grupa sklepów jest skonfigurowana do współdzielenia zamówień, mogą być widoczne i współdzielone w tej grupie; w przeciwnym razie zamówienie pozostaje w zakresie własnego sklepu. Tak czy inaczej możesz przeglądać i obsługiwać zamówienia wszystkich sklepów z jednej listy Zamówienia, co jest zyskiem z centralnej realizacji.
• Dostępne ilości (stany magazynowe) - mogą być współdzielone w ramach grupy sklepów, gdy włączona jest opcja "współdziel dostępne ilości"; to właśnie umożliwia scenariusze z jednym magazynem. W przeciwnym razie stan pozostaje oddzielny dla każdego sklepu.
• Kategorie i CMS - można je współdzielić, ale często warto je rozdzielić: wspólne drzewo produktów, lecz zlokalizowane strony prawne i strona główna dopasowana do kraju.

Problem zgodności modułów

To największe praktyczne ryzyko i jest ono realne. Świadomość Multistore w module nie pojawia się automatycznie - programista musi ją zaimplementować. Moduł, który ignoruje Multistore, będzie:

• Ignorować kontekst sklepu i stosować każdą zmianę do wszystkich sklepów, bo odczytuje i zapisuje konfigurację przez Configuration::get() / Configuration::updateValue() bez przekazywania identyfikatora sklepu albo respektowania Shop::CONTEXT_SHOP.
• Przechowywać ustawienia globalnie, więc nie nadasz dwóm sklepom różnych wartości - drugi sklep nadpisze pierwszy.
• Tworzyć własne tabele w bazie danych bez kolumny id_shop, więc jego dane są nieuchronnie współdzielone nawet wtedy, gdy powinny być osobne dla każdego sklepu.
• Działać poprawnie w sklepie głównym i psuć się albo po cichu wyciekać danymi w dowolnym innym kontekście sklepu.

Dobrze zbudowany moduł odczytuje ustawienia z identyfikatorem sklepu (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop) przez kontekst sklepu), dodaje id_shop do swoich tabel i rejestruje hooki dla każdego sklepu. Zanim zdecydujesz się na Multistore, przeprowadź audyt każdego modułu, od którego zależysz. Sprawdź dokumentację, zapytaj bezpośrednio programistę i - to nie podlega negocjacji - przetestuj wszystko w środowisku testowym z co najmniej dwoma sklepami zanim zbudujesz właściwe środowisko. Odkrycie po uruchomieniu trzech działających sklepów, że krytyczny moduł nie obsługuje Multistore, to naprawdę zły scenariusz.

Właśnie dlatego budujemy moduły w taki sposób. Nasze pakiety modułów są pisane ze świadomością kontekstu sklepu od warstwy danych w górę, więc ustawienie zmienione w sklepie francuskim zostaje w sklepie francuskim, a tabele modułu mają własne id_shop, zamiast rozmazywać dane po wszystkich sklepach. To różnica między instalacją Multistore, której możesz ufać, a taką, w której każdy zapis konfiguracji jest małym zakładem - niezależnie od tego, czy prowadzisz zarządzanie SEO, fakturowanie czy treści w sklepie w kilku sklepach. Każdy moduł nadal trzeba zweryfikować osobno, ale sens kupowania od programisty testującego tryb wielu sklepów polega na tym, że nie dziedziczysz opisanego wyżej problemu zgodności.

Waluty, flagi i szczegóły witryny sklepowej per sklep

Multistore daje każdemu sklepowi własną domyślną walutę i własny zestaw włączonych języków, ale elementy widoczne dla klienta - przełącznik waluty, flagi językowe, sposób, w jaki powracający odwiedzający trafia do właściwego sklepu - to praca po stronie witryny sklepowej, nadbudowana nad Multistore, a nie część samego Multistore. Dopilnowanie tych drobnych szczegółów sprawia, że odwiedzający z zagranicy nie odbija się od strony; omawiamy je w artykule przełącznik waluty i flagi językowe, a pełną mechanikę prowadzenia cen w kilku walutach w przewodniku po konfiguracji wielu walut.

Praktyczne wskazówki zarządzania

• Czytaj selektor kontekstu przed każdym zapisem. To jeden nawyk, który zapobiega najkosztowniejszemu błędowi w Multistore. Traktuj "Wszystkie sklepy" jak ustawienie o dużej sile rażenia.
• Nazywaj zasoby specyficzne dla sklepu z nazwą sklepu. banner-myshop-de.jpg, nie banner.jpg. Gdy przesyłasz logo i grafiki motywu dla konkretnego sklepu, nazwa pliku jest jedynym przypomnieniem, w którym sklepie jesteś.
• Testuj w kontekście każdego sklepu. Zmiana motywu, która wygląda dobrze w sklepie A, może zepsuć sklep B z innym motywem albo konfiguracją modułu. Po zmianie sprawdzaj działającą widoczną część każdego sklepu, nie tylko głównego.
• Rób kopię zapasową przed zmianami strukturalnymi. Edycja w złym kontekście może rozlać się na wszystkie sklepy naraz; świeży zrzut bazy danych to Twój przycisk cofania.
• Dokumentuj mapę sklepów. Które sklepy są w której grupie, co jest współdzielone, a co nadpisane, które moduły są specyficzne dla sklepu. Gdy coś się psuje albo dołącza nowa osoba, to właśnie ten dokument ratuje sytuację.
• Pilnuj mapowania shop_url. Ustawienia SSL, flaga głównego adresu URL oraz fizyczny/wirtualny URI dla sklepu łatwo skonfigurować źle, co prowadzi do pętli przekierowań albo ładowania niewłaściwego sklepu. Sprawdzisz je w Parametry zaawansowane → Multistore → adres URL danego sklepu.

Kwestie wydajności

Każde zapytanie w Multistore niesie filtr sklepu - PrestaShop łączy dane z tabelami powiązań _shop i filtruje po id_shop przy większości odczytów katalogu i konfiguracji. Dla dwóch lub trzech sklepów ze zwykłymi katalogami ten narzut jest pomijalny. Przy ponad dziesięciu sklepach z dużymi katalogami staje się mierzalny, a rozwiązaniem jest zwykła higiena bazy danych: upewnij się, że na kolumnach id_shop w ciężkich tabelach powiązań istnieją indeksy, trzymaj pod kontrolą liczbę kategorii i produktów oraz korzystaj z pamięci podręcznej pełnych stron, żeby widoczna część sklepu nie uruchamiała zapytań filtrowanych po sklepie przy każdym odsłonięciu. Mierz na własnej instalacji - włącz Multistore, a potem obserwuj czasy zapytań w profilerze debugowania, zanim założysz, że masz problem.

Najczęściej zadawane pytania

Czy Multistore to właściwy sposób na dodanie kolejnych języków?

Nie - to najczęstszy błąd. PrestaShop obsługuje wiele języków wewnątrz pojedynczego sklepu: każde tłumaczalne pole jest przechowywane per język w tabelach _lang, a języki dodajesz w Międzynarodowe → Lokalizacja → Języki. Jeśli potrzebujesz tylko tego samego katalogu w tych samych cenach po angielsku i francusku, Multistore dokłada żonglowanie kontekstem bez żadnej korzyści. Użyj wbudowanych pól wielojęzycznych - zobacz konfigurację sklepu wielojęzycznego. Sięgaj po Multistore dopiero wtedy, gdy rynki potrzebują naprawdę różnych katalogów, struktur cenowych albo odrębnej identyfikacji marki.

Jaki jest najkosztowniejszy błąd w Multistore?

Zapis w kontekście "Wszystkie sklepy", gdy chodziło Ci o jeden sklep. Selektor kontekstu (lewy górny róg) jest aktywnym zakresem: w trybie "Wszystkie sklepy" zapis wpisuje wartość do każdego sklepu naraz i nie wyświetla błędu - po cichu robi dokładnie to, co mu polecono, wszędzie. Nawyk, który temu zapobiega, jest prosty: przeczytaj na głos selektor kontekstu, zanim klikniesz Zapisz, i traktuj "Wszystkie sklepy" jak ustawienie o dużej sile rażenia.

Czy moje sklepy mogą współdzielić klientów i magazyn?

W ramach grupy sklepów - tak. Grupa sklepów wyznacza granicę współdzielenia: klienci, koszyki i dostępne stany magazynowe mogą być współdzielone w ramach grupy, ale nigdy między grupami. Jeśli więc dwa sklepy mają współdzielić logowanie klienta, muszą należeć do tej samej grupy, a wspólny magazyn (gdy w grupie włączona jest opcja "współdziel dostępne ilości") umożliwia scenariusze z jednym magazynem. Zamówienia zawsze zachowują id_shop sklepu pochodzenia, ale możesz obsługiwać zamówienia wszystkich sklepów z jednej listy Zamówienia.

Skąd mam wiedzieć, czy moduł jest bezpieczny do użycia w wielu sklepach?

Musisz to zweryfikować - świadomość Multistore nie jest automatyczna, programista musi ją zaimplementować. Moduł ignorujący kontekst sklepu będzie stosował każdą zmianę do wszystkich sklepów, przechowywał ustawienia globalnie, przez co dwa sklepy nie będą mogły się różnić, albo tworzył tabele bez kolumny id_shop, więc jego dane będą nieuchronnie współdzielone. Dobrze zbudowany moduł odczytuje ustawienia z identyfikatorem sklepu (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop)), dodaje id_shop do swoich tabel i rejestruje hooki dla każdego sklepu. Przetestuj każdą zależność w środowisku testowym z co najmniej dwoma sklepami, zanim zbudujesz właściwe środowisko. Nasze pakiety modułów są pisane ze świadomością kontekstu sklepu od warstwy danych w górę - niezależnie od tego, czy prowadzisz zarządzanie SEO, fakturowanie czy treści w sklepie w kilku sklepach.

Czy Multistore sam obsłuży waluty, podatki i hreflang per kraj?

Nie - Multistore obsługuje witryny sklepowe. Każdy sklep dostaje własną domyślną walutę i zestaw włączonych języków, ale poprawnie zlokalizowane wyświetlanie walut, ceny brutto zależnie od kraju i hreflang między osobnymi domenami to osobne zadania zbudowane na wierzchu. Zobacz sprzedaż w Europie dla walut i podatków oraz tagi hreflang dla międzydomenowych sygnałów SEO, których rdzeń PrestaShop nie złoży samodzielnie między sklepami.

Powiązane artykuły

• Konfiguracja sklepu wielojęzycznego - właściwe narzędzie, gdy potrzebujesz tylko więcej języków, a nie więcej sklepów.
• Sprzedaż w Europie - warstwa walut, podatków i OSS, której Multistore sam nie rozwiązuje.
• Tagi hreflang - wzajemność między domenami to trudny przypadek, gdy każdy rynek ma własny sklep.

Najważniejszy wniosek

Multistore jest właściwą odpowiedzią wtedy, gdy Twoje sklepy naprawdę się pokrywają - współdzielą produkty, klientów i magazyn - a Ty chcesz świadomie różnicować witrynę sklepową, ceny i identyfikację marki na bazie tego wspólnego rdzenia. Jest złą odpowiedzią na "potrzebuję tylko więcej języków" (użyj wbudowanych pól wielojęzycznych) i dla naprawdę oddzielnych biznesów (użyj osobnych instalacji). Podejmij dobrą decyzję o współdzieleniu i rozdzieleniu danych na samym początku, traktuj selektor kontekstu z żelazną dyscypliną, zweryfikuj obsługę kontekstu sklepu w modułach, zanim zaczniesz budowę, a Multistore zamieni administrację wartą trzech instalacji w jedną. Dyscyplina konfiguracji to cena; codzienna prostota operacyjna to to, co kupujesz.

Aby przejść krok po kroku przez tworzenie pierwszej grupy sklepów i sklepu, zobacz nasz przewodnik w bazie wiedzy Jak skonfigurować PrestaShop Multistore.