Jak skonfigurować i prowadzić multistore w PrestaShop

Co byśmy zrobili

Najpierw spisalibyśmy, co musi być wspólne, a co różne, a następnie sprawdzili ten plan w obecnym sklepie: jego wersji PrestaShop, niezbędnych modułach, połączeniach z ERP i magazynem, motywie, danych katalogu i klientów, rynkach oraz obowiązkach pracowników. Obowiązkowa integracja, która nie rozróżnia sklepów, może przesądzić o architekturze, zanim utworzysz kolejną witrynę sklepową.

Zbuduj proponowaną strukturę na odizolowanej kopii stagingowej, oddzielając wiadomości do klientów, płatności produkcyjne i eksporty zapasów lub zamówień od systemów produkcyjnych. Uzgodnij kontrole odbioru, przećwicz zmianę i zaplanuj kontrolowane przełączenie z przetestowaną procedurą odtworzenia. Utrzymuj sprzedaż w obecnej witrynie aż do uzgodnionego przełączenia.

Jeśli chcesz ocenić zależności niezbędnych modułów na kopii swojego sklepu, PrestaShop Module Selection & Fit Assessment sprawdza dostępne rozwiązania pod kątem wymaganego rezultatu.

Wybierz multistore lub osobne instalacje

Multistore obsługuje kilka witryn sklepowych z jednego kodu, bazy danych i panelu administracyjnego. Hierarchia obejmuje grupę sklepów, sklep i adresy URL sklepu. Grupa określa obsługiwane współdzielenie klientów, zapasów i koszyków; każdy sklep ma własne powiązania i obsługiwane wartości konfiguracji.

Reguły handlowe, takie jak wyświetlanie podatku, minimalne ilości i dostępność metod płatności, nadal wymagają konfiguracji i testów. Proces dla klientów firmowych opisuje poradnik konfiguracji B2B.

Wszystkie sklepy w jednej instalacji wspólnie odczuwają skutki nieudanego wdrożenia kodu lub zmiany bazy danych. Twórz kopie całej bazy i plików. Zapisz mapę sklepów: grupy, domeny, języki, waluty, powiązania katalogu, własność zapasów i zamierzony zakres modułów.

Ustal trzy ustawienia współdzielenia grupy sklepów

Sklepy używają jednej standardowej tabeli klientów z przypisaniem do sklepu i grupy. Nie ma osobnej tabeli klientów dla każdego sklepu. Oddzielne i wspólne konta klientów wymagają więc świadomej konfiguracji grupy, a nie ręcznego kopiowania między tabelami.

Współdzielenie jest ograniczone do grupy sklepów. Dostępność wspólnego konta nie gwarantuje wspólnego logowania w przeglądarce ani koszyka między niepowiązanymi domenami: cookies przeglądarki są ograniczone do domeny. Testuj wybrane hosty i ścieżki. Zamówienie zachowuje id_shop sklepu, w którym je złożono. Używaj kontekstu panelu administracyjnego i uprawnień pracowników, aby zarządzać zamówieniami zamierzonych sklepów.

Ustal te ustawienia w środowisku testowym, zanim prawdziwi klienci, zamówienia i zapasy utrudnią zmianę. Nie traktuj przełącznika współdzielenia jako bezpiecznej metody łączenia działających niezależnych sklepów.

Przećwicz scenariusz sprzedaży detalicznej i hurtowej

Twój sklep detaliczny i planowany sklep hurtowy sprzedają tę samą złączkę z jednego magazynu. Zapasy mają być wspólne, zgłoszenia klientów hurtowych wymagają akceptacji, a płatność na fakturę powinny widzieć tylko zatwierdzone konta hurtowe. Te wymagania same w sobie nie oznaczają konieczności współdzielenia kont klientów ani koszyków. Zdecyduj o współdzieleniu klientów niezależnie od ilości, a opcję Współdziel zamówienia włącz tylko wtedy, gdy koszyk musi przechodzić między sklepami.

1. Powiąż produkt testowy z oboma sklepami i nadaj mu rozróżnialne ceny detaliczną i hurtową. Zapisz początkową dostępną ilość i oczekiwaną cenę w każdym kontekście.
2. Złóż testowe zamówienie detaliczne i sprawdź pozostałą ilość w obu sklepach oraz sklep źródłowy zapisany w zamówieniu. Powtórz test w sklepie hurtowym i prześledź zmianę zapasów przez integrację magazynową, sprawdzając, czy przetwarzanie się nie powiela.
3. Przetestuj konto tylko detaliczne, niezatwierdzonego kandydata na klienta hurtowego i zatwierdzonego klienta hurtowego. Sprawdź ich rzeczywiste ceny i dostępne płatności. Współdzielenie konta nie może nadawać uprawnień hurtowych tylko dlatego, że kupujący odwiedza adres sklepu hurtowego.

Jeśli integracja nie rozpoznaje sklepu, z którego pochodzi zamówienie, potraktuj to jako nierozwiązaną zależność przed uruchomieniem. Wspólny magazyn nie zwalnia z poprawnego przypisywania faktur, komunikacji z klientami i zwrotów do właściwego sklepu.

Włącz multistore i utwórz strukturę sklepów

1. Wykonaj kopię całej instalacji i przećwicz proces w środowisku testowym.
2. Włącz Multistore w Parametry sklepu → Ogólne.
3. Otwórz Zaawansowane → Multistore i utwórz lub wybierz docelową grupę sklepów.
4. Ustaw wszystkie trzy opcje współdzielenia zgodnie z planem.
5. Utwórz sklep z nazwą, grupą i kategorią główną. Jeśli importujesz dane z innego sklepu, przejrzyj każdą oferowaną kategorię importu i sprawdź wynikowe powiązania.
6. Dodaj URL sklepu i potwierdź domenę, domenę SSL, ścieżkę fizyczną, ścieżkę wirtualną, stan włączenia i flagę głównego adresu.
7. Dokończ routing serwera, a następnie przetestuj witrynę przed importem lub edycją dużej ilości danych.

Skopiowany katalog lub konfiguracja to stan początkowy. Nie zakładaj, że każda skopiowana wartość pozostaje powiązana z późniejszymi zmianami w sklepie źródłowym.

Skonfiguruj DNS, TLS i routing serwera

Osobne domeny i subdomeny muszą wskazywać serwer. Skonfiguruj serwer WWW tak, aby obsługiwał ten sam katalog PrestaShop dla każdego hosta, i zainstaluj certyfikaty obejmujące każdą nazwę hosta HTTPS. Certyfikat wildcard obejmuje tylko nazwy w dozwolonym zakresie; sprawdź rzeczywiste nazwy certyfikatu.

Fizyczny URI to rzeczywista ścieżka WWW instalacji. Wirtualny URI identyfikuje ścieżkę witryny, która nie wymaga osobnego katalogu instalacji. Dla instalacji w katalogu głównym domeny przykładowe układy są następujące:

Apache

Najpierw skonfiguruj hosty wirtualne i TLS. Włącz wymaganą obsługę przepisywania i dopuść reguły przepisywania instalacji. Zapisz ustawienia adresów w Parametry sklepu → Ruch i SEO → SEO i URL, aby wygenerować odpowiednie reguły .htaccess. Sprawdź wynik i przetestuj go. Plik .htaccess nie konfiguruje DNS, certyfikatów ani hostów wirtualnych.

nginx

nginx nie odczytuje .htaccess. Zacznij od konfiguracji nginx dla PrestaShop, obejmującej przepisywanie zasobów, chronione katalogi i obsługę PHP. Każdy host powinien używać tego samego katalogu głównego instalacji.

Dla instalacji w katalogu głównym z wirtualną ścieżką sklepu wholesale/ dodaj przepisywanie prefiksu w bloku server przed zwykłymi regułami PrestaShop:

rewrite ^/wholesale/(.*)$ /$1 last;

Zachowaj standardową regułę zapasową kierującą do kontrolera frontowego sklepu:

location / {
    try_files $uri $uri/ /index.php$is_args$args;
}

Parametry PHP muszą zachowywać pierwotny REQUEST_URI, w tym /wholesale/, aby PrestaShop mógł rozpoznać sklep. Wewnętrzne przepisanie pozwala tym samym regułom zasobów i kontrolera frontowego obsługiwać ścieżkę wirtualną. Dostosuj prefiks do każdego wirtualnego sklepu, zachowaj wszystkie sekcje bezpieczeństwa i sprawdź konfigurację nginx przed przeładowaniem. Przetestuj stronę główną sklepu, przyjazne adresy, obrazy, trasy modułów, koszyk i finalizację zakupu.

Dla obu serwerów potwierdź zgodność HTTPS i zaufanych nagłówków reverse proxy ze skonfigurowanymi adresami. Testuj przekierowania kanoniczne z alternatywnych hostów i ścieżek. Po zmianie konfiguracji URL wyczyść odpowiednie pamięci podręczne.

Poznaj kontekst sklepu i różne zakresy danych

Przed każdym zapisem sprawdź selektor sklepu. Wybierz Wszystkie sklepy, grupę sklepów lub jeden sklep zgodnie z zamierzoną zmianą. Obsługiwany zakres formularza określa skutki zapisu; nie zakładaj, że każda strona akceptuje każdy kontekst.

Pola wyboru mogą oznaczać użycie odziedziczonej konfiguracji, wybór pól do aktualizacji lub wybór sklepów objętych działaniem. Czytaj etykietę i pomoc dla danego formularza i wydania. Pole wyboru aktualizacji produktu nie obiecuje ciągłego dziedziczenia.

Przypisuj produkty i kategorie tylko do zamierzonych sklepów. Przed potwierdzeniem wyłączenia, usunięcia powiązania lub usunięcia sprawdzaj pokazany zakres działania. Usunięcie powiązania i usunięcie współdzielonej encji mają różne skutki.

Konfiguruj motywy, logotypy, włączone języki, waluty, przewoźników, metody płatności i podatki w obsługiwanym kontekście. Po zapisaniu przeładuj stronę i odwiedź każdą witrynę. Jasno nazywaj zasoby właściwe dla sklepu, np. banner-de.jpg, i dokumentuj zasoby wspólne.

Przetestuj przełączanie języka i waluty na stronie produktu: odwiedzający powinien trafić do odpowiadającego produktu, a wybrana waluta powinna pozostać w koszyku i podczas realizacji zamówienia. Zanim skopiujesz treść lub konfigurację między markami, zapisz, do którego sklepu należy każda strona prawna i tożsamość nadawcy. Konfigurację rynków opisuje poradnik tłumaczeń i sprzedaży międzynarodowej.

Testuj moduły w dwóch kontekstach sklepu

1. Ustal, które ustawienia modułu są z założenia globalne, a które powinny różnić się między sklepami.
2. W środowisku testowym zapisz różne wartości w dwóch sklepach. Przeładuj obie strony konfiguracji i sprawdź obie witryny.
3. Sprawdź wynik hooków, importy, zadania cron, zadania wiersza poleceń i trafienia cache. Mogą działać w innym kontekście niż sesja przeglądarki pracownika.
4. Sprawdź przypisanie danych niestandardowych przez kolumny sklepu, tabele powiązań lub encje nadrzędne z określonym zakresem. Tabela nie potrzebuje kolumny id_shop, jeśli zakres zapewnia inny poprawny model własności.
5. Sprawdź, czy klucze cache obejmują każdy wymiar kontekstu wpływający na wynik, w tym sklep i odpowiedni język lub walutę.

Dla integracji ERP, magazynu, platform sprzedażowych, księgowości i poczty zapisz, jak każdy import, eksport i powiadomienie zwrotne identyfikuje sklep docelowy. Uruchom zaplanowane zadania w ich rzeczywistym kontekście wykonania i sprawdź wynikowe zapisy oraz wysyłane dane. Integracja zakładająca sklep domyślny wymaga obsługiwanej zmiany lub wymiany, jeśli ma obsługiwać inne sklepy; samo dodanie kolumny sklepu nie naprawia pozostałej części procesu.

Gdy wymagana integracja potrzebuje własnej obsługi zakresu sklepów, PrestaShop Custom Module Development Service zapewnia wykonanie według uzgodnionej specyfikacji.

Configuration::get() i Configuration::updateValue() ustalają bieżący sklep lub grupę, gdy pominięto argumenty zakresu. Jawne ID są przydatne, gdy kontekst wykonania różni się od celu. Zapisy globalne, niewłaściwy kontekst, zapytania bez zakresu i kolizje cache wymagają osobnej diagnozy.

Wiersz konfiguracji sklepu może działać z id_shop_group ustawionym na NULL. Pojedynczy wiersz globalny może być dziedziczoną wartością domyślną. Testuj zamierzone odczyty i zapisy, zanim uznasz którykolwiek stan za błąd, i naprawiaj ścieżkę aplikacji, zamiast ręcznie wstawiać wiersze konfiguracji.

Zgodność zależy od funkcji. Na przykład zwykłe ustawienia SEO Revolution i warstwa konfiguracji Financial Revolution korzystają z globalnych ścieżek konfiguracji. Potwierdź zakres każdej funkcji, zanim zaczniesz oczekiwać niezależnych ustawień sklepów.

Sprawdzaj SEO i wydajność każdej witryny

Dla stron, które mają być indeksowane osobno, świadomie ustawiaj adresy kanoniczne w odpowiednim sklepie. Używaj adresu kanonicznego między domenami tylko wtedy, gdy chcesz konsolidacji. Ogranicz mapę witryny każdego sklepu do zamierzonych adresów i zweryfikuj właściwe usługi Search Console.

Wbudowane alternatywy językowe dotyczą języków w bieżącym sklepie. Odpowiadające sobie strony osobnych sklepów potrzebują własnego mapowania między sklepami. Zalecane jest hreflang dla alternatyw językowych i regionalnych, z odwołaniem do siebie, pełnymi adresami i wzajemnymi linkami między równoważnymi stronami. Opcjonalny x-default może wskazywać odpowiednią wersję zastępczą.

Jeśli potrzebujesz generowanych zestawów językowych, Hreflang Tags Manager zapewnia podgląd audytowy i zestawy dla aktywnych języków, osobne dla sklepów i domen. Nie emituje tagów dla sklepów z tylko jednym aktywnym językiem. Przed wyborem przetestuj na stagingu wymagane wzajemne linki między odpowiadającymi sobie stronami w różnych sklepach, obsługiwane typy stron i wynik mapy witryny. Osobne zestawy językowe dla sklepów nie potwierdzają istnienia wymaganego mapowania między sklepami.

Brak linków zwrotnych może spowodować zignorowanie tych oznaczeń, podczas gdy poprawne wzajemne relacje nadal działają. Hreflang nie jest warunkiem indeksowania ani gwarancją pozycji. Stosuj wytyczne Google dotyczące stron lokalizowanych i sprawdzaj wyrenderowany zestaw powiązań.

Mierz zapytania katalogu, złączenia powiązań, ładowanie konfiguracji i użycie cache przy swoim obciążeniu. Rdzeń buforuje załadowaną konfigurację w procesie; wywołanie Configuration::get() nie oznacza za każdym razem nowego zapytania do bazy. Globalne wartości domyślne oznaczają też, że nie musi istnieć jeden wiersz konfiguracji na sklep.

Używaj EXPLAIN dla wolnych zapytań i sprawdzaj istniejące indeksy złożone przed dodaniem indeksu id_shop. Przestrzeń cache zależy od kluczy, kontekstów i unieważniania, więc planowanie pojemności wymaga pomiarów, a nie mnożnika liczby sklepów. Zobacz poradnik wydajności.

Rozwiązuj problemy zakresu i utrzymuj każdy sklep

Produkt pojawia się w niewłaściwym sklepie

Sprawdź powiązania w edytorze produktu i zweryfikuj zestaw wierszy. Oba przykłady SQL używają prefiksu tabel ps_; zastąp go prefiksem swojej instalacji. Ten przykład tylko do odczytu dotyczy produktu 123; podstaw rzeczywisty identyfikator produktu:

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

Popraw powiązania w obsługiwanym edytorze, a następnie sprawdź przynależność do kategorii, widoczność i listy z cache.

Zapis wpływa na oba sklepy

Ponownie sprawdź aktywny kontekst, zakres pola, dziedziczone wartości domyślne i sposób przechowywania danych przez moduł. Porównaj wartości przed i po w dwóch kontekstach. Funkcja wyłącznie globalna może działać zgodnie z projektem.

Koszyk pojawia się w różnych sklepach

Najpierw sprawdź ustawienie grupy Współdziel zamówienia. Sprawdź w przeglądarce rzeczywistą nazwę, domenę i ścieżkę cookie, a potem adresy sklepów. Zamierzone współdzielenie koszyka w grupie i wada izolacji potrzebują różnych napraw. Rdzeń wyznacza zakres cookies; w Parametry sklepu → Ogólne nie ma ogólnego pola domeny cookie.

Import lub URL trafia do niewłaściwego sklepu

Wybierz sklep docelowy przed otwarciem narzędzia importu. Wykonaj próbny mały import i sprawdź powiązania. Przy przekierowaniach sprawdź DNS, hosty wirtualne, certyfikaty, nagłówki proxy, ustawienia kanoniczne i te wiersze adresów:

SELECT s.id_shop, s.name, su.domain, su.domain_ssl,
       su.physical_uri, su.virtual_uri, su.main, su.active
FROM ps_shop s
JOIN ps_shop_url su ON su.id_shop = s.id_shop
ORDER BY s.id_shop, su.main DESC;

Kontrole rutynowe

• Otwórz każdą witrynę i sprawdź motyw, produkty, język, ceny i przekierowania.
• Testuj proces zakupowy, metody płatności, skutki dla zapasów i sklep zapisany w zamówieniach.
• Przeglądaj ustawienia modułów według sklepu, logi, domeny nadawców i e-maile testowe.
• Po importach sprawdzaj odpowiedzi map witryn i powiązania produktów.
• Po aktualizacji modułu lub rdzenia powtórz kontrole w każdym sklepie, przejrzyj adresy i unieważnij odpowiednie cache.

Zaplanuj przełączenie i przekaż obsługę

1. Zapisz zmiany katalogu, klientów i zamówień od momentu utworzenia kopii stagingowej. Uzgodnij sposób przeniesienia przetestowanej konfiguracji na produkcję bez nadpisywania tych zmian starą bazą danych.
2. Wybierz termin przełączenia i wyznacz osobę kontrolującą importy oraz zapisy. Zdecyduj, czy część zapisów trzeba wstrzymać i jak uzgodnić płatności w toku, zamówienia i aktualizacje magazynowe.
3. Przećwicz odtworzenie pełnej kopii zapasowej i określ warunki awarii uruchamiające wycofanie zmian. Jeśli po przełączeniu wpłyną nowe zamówienia, zachowaj je i uzgodnij przed odtworzeniem; kopia sprzed uruchomienia ich nie zawiera.
4. Użyj powyższych rutynowych kontroli jako kryteriów odbioru wdrożenia dla każdego sklepu. Przypisz każdej kontroli odpowiedzialną osobę i zapisz wynik przed przekazaniem nowej witryny pracownikom.

O co zapytać programistę lub agencję

• Które wymagane funkcje modułów przetestowano w osobnych kontekstach sklepów i które z założenia pozostają globalne?
• Jak każda integracja zachowuje przypisanie do sklepu w zaplanowanych zadaniach, powiadomieniach zwrotnych i identyfikatorach zewnętrznych?
• Czy możesz zademonstrować wycofanie zmian i rozliczyć zamówienia przyjęte po przełączeniu?
• Którzy pracownicy mogą wprowadzać zmiany dla całej grupy lub globalne i gdzie znajdują się mapa sklepów oraz instrukcje obsługi?

Zanim zaczną się rutynowe edycje, poproś pracowników o przećwiczenie zmiany ceny dla konkretnego sklepu i potwierdzenie wyniku w drugiej witrynie. Zapisz, kto zatwierdza zmiany wspólnych pól, aby nowy członek zespołu wiedział, kiedy pozornie lokalna edycja wymaga szerszej oceny.

Pytania właścicieli sklepów

Czy klienci zachowają hasła po połączeniu osobnych sklepów?

Wymagaj, aby próba migracji wykazała działanie logowania na istniejące konta, i uzgodnij obsługę powtarzających się adresów e-mail. Nie obiecuj ciągłości kont na podstawie samego włączenia multistore ani nie łącz tożsamości tylko dlatego, że adresy e-mail są zgodne.

Czy jeden panel oznacza, że każdy pracownik widzi wszystkie sklepy?

Sprawdź uprawnienia pracowników i powiązania ze sklepami, a następnie zaloguj się jako pracownik z ograniczonym dostępem i przetestuj dostęp do zamówień, klientów i ekranów modułów. Sprawdź też eksporty: ograniczenie ekranu nie wystarczy, jeśli eksport zawiera zapisy innego sklepu.

Czy później możemy przekazać lub sprzedać jedną markę?

Zaplanuj wydzielenie, zanim zdecydujesz się na współdzielenie encji. Poproś o eksport o określonym zakresie i próbę obejmującą zamówienia, klientów, powiązania katalogu, multimedia oraz identyfikatory zewnętrzne danego sklepu, z uzgodnioną obsługą zapisów używanych przez inne sklepy.

Czy potrzebujemy konta płatniczego dla każdego sklepu?

Sprawdź podmioty sprzedające i umowę z dostawcą, a następnie przetestuj dane dostępowe integracji dla poszczególnych sklepów i kierowanie powiadomień. Centralna administracja nie rozstrzyga, która firma otrzymuje środki; uzgodnij każdą płatność testową z właściwym kontem i zamówieniem.