PrestaShop Multishop einrichten und verwalten

So würden wir vorgehen

Wir würden zunächst auflisten, was gemeinsam genutzt werden muss und was sich unterscheiden soll, und diese Zuordnung dann anhand Ihres bestehenden Shops prüfen: PrestaShop-Version, unverzichtbare Module, ERP- und Lageranbindungen, Theme, Katalog- und Kundendaten, Zielmärkte und Mitarbeiterzuständigkeiten. Eine zwingend benötigte Integration, die Shops nicht unterscheiden kann, kann die Architektur bestimmen, bevor Sie ein weiteres Frontoffice anlegen.

Bauen Sie die vorgeschlagene Struktur auf einer isolierten Staging-Kopie auf und halten Sie Kunden-E-Mails, Live-Zahlungen sowie Bestands- oder Bestellexporte von Produktivsystemen fern. Vereinbaren Sie Abnahmeprüfungen, erproben Sie die Änderung und planen Sie eine kontrollierte Umschaltung mit einem getesteten Wiederherstellungsweg. Lassen Sie das aktuelle Frontoffice bis zum vereinbarten Umschaltzeitpunkt weiterverkaufen.

Wenn Sie die wesentlichen Modulabhängigkeiten auf Ihrer Shopkopie bewerten lassen möchten, prüft das PrestaShop Module Selection & Fit Assessment die verfügbaren Wege anhand des benötigten Ergebnisses.

Multishop oder getrennte Installationen wählen

Multishop betreibt mehrere Frontoffices aus einer Codebasis, Datenbank und einem Backoffice. Die Hierarchie lautet Shopgruppe, Shop, dann Shop-URLs. Eine Gruppe definiert die unterstützte gemeinsame Nutzung von Kunden, Bestand und Warenkörben; jeder Shop hat eigene Zuordnungen und unterstützte Konfigurationswerte.

Geschäftsregeln wie Steueranzeige, Mindestmengen und die Berechtigung für Zahlungsmethoden müssen weiterhin konfiguriert und getestet werden. Zum Ablauf für Geschäftskunden siehe den Leitfaden zur B2B-Einrichtung.

Alle Shops einer Installation teilen die Folgen eines fehlgeschlagenen Code-Deployments oder einer Datenbankänderung. Sichern Sie vollständige Datenbank und Dateien. Dokumentieren Sie Ihre Shopübersicht: Gruppen, Domains, Sprachen, Währungen, Katalogzuordnungen, Bestandszuständigkeit und vorgesehenen Modul-Geltungsbereich.

Die drei Einstellungen zur gemeinsamen Nutzung innerhalb der Shopgruppe festlegen

Shops nutzen eine gemeinsame Standard-Kundentabelle mit Shop- und Gruppenzugehörigkeit. Sie haben nicht jeweils eine eigene Kundentabelle. Getrennte und gemeinsam genutzte Kundenkonten benötigen daher gezielte Gruppenkonfiguration statt manuelles Kopieren zwischen Tabellen.

Die gemeinsame Nutzung bleibt auf die Shopgruppe begrenzt. Gemeinsame Kontoverfügbarkeit garantiert keine gemeinsame Browseranmeldung oder Warenkörbe über unabhängige Domains hinweg: Browser-Cookies sind auf ihre Domain begrenzt. Testen Sie Ihre gewählten Hosts und Pfade. Eine Bestellung behält die id_shop des Shops, in dem sie aufgegeben wurde. Nutzen Sie Backoffice-Kontext und Mitarbeiterrechte zur Bestellverwaltung über die vorgesehenen Shops hinweg.

Legen Sie diese Einstellungen im Staging fest, bevor echte Kunden, Bestellungen und Bestände Änderungen erschweren. Behandeln Sie einen Schalter für die gemeinsame Nutzung nicht als sicheren Weg, bestehende unabhängige Shops zusammenzuführen.

Ein Einzel- und Großhandelsszenario durchspielen

Ihr Endkundenshop und der geplante Geschäftskundenshop verkaufen dieselbe Armatur aus einem Lager. Der Bestand soll gemeinsam genutzt werden, Geschäftskundenanträge benötigen eine Freigabe und nur freigegebene Geschäftskonten sollen den Rechnungskauf sehen. Diese Anforderungen setzen für sich genommen keine gemeinsamen Kundenkonten oder Warenkörbe voraus. Entscheiden Sie über gemeinsame Kunden getrennt von gemeinsamen Bestandsmengen und aktivieren Sie „Bestellungen gemeinsam nutzen“ nur, wenn ein Warenkorb shopübergreifend verfügbar sein muss.

1. Ordnen Sie das Testprodukt beiden Shops zu und geben Sie ihm unterscheidbare Endkunden- und Geschäftskundenpreise. Dokumentieren Sie die anfänglich verfügbare Menge und den erwarteten Preis in jedem Kontext.
2. Geben Sie eine Testbestellung im Endkundenshop auf und prüfen Sie die verbleibende Menge in beiden Shops sowie den in der Bestellung gespeicherten Herkunftsshop. Wiederholen Sie dies im Geschäftskundenshop und verfolgen Sie die Bestandsbewegung über die Lageranbindung auf doppelte Verarbeitung.
3. Testen Sie ein reines Endkundenkonto, einen noch nicht freigegebenen Geschäftskundenantrag und einen freigegebenen Geschäftskunden. Prüfen Sie deren tatsächliche Preise und Zahlungsoptionen. Ein gemeinsam genutztes Konto darf nicht allein durch den Aufruf der Geschäftskunden-URL Geschäftskundenrechte erhalten.

Kann die Anbindung nicht erkennen, aus welchem Shop eine Bestellung stammt, behandeln Sie dies vor dem Start als ungelöste Abhängigkeit. Ein gemeinsames Lager hebt die Notwendigkeit nicht auf, shopbezogene Rechnungen, Kundenmitteilungen und Retouren korrekt zuzuordnen.

Multishop aktivieren und die Shopstruktur erstellen

1. Sichern Sie die vollständige Installation und proben Sie im Staging.
2. Aktivieren Sie Multishop unter Shop-Einstellungen → Allgemein.
3. Öffnen Sie Erweiterte Einstellungen → Multishop und erstellen oder wählen Sie die vorgesehene Shopgruppe.
4. Legen Sie alle drei Optionen zur gemeinsamen Nutzung gemäß Ihrem Plan fest.
5. Erstellen Sie den Shop mit Namen, Gruppe und Hauptkategorie. Prüfen Sie beim Datenimport aus einem anderen Shop jede angebotene Importkategorie und die resultierenden Zuordnungen.
6. Fügen Sie die Shop-URL hinzu und bestätigen Sie Domain, SSL-Domain, physischen Pfad, virtuellen Pfad, Aktivierungsstatus und Haupt-URL-Kennzeichen.
7. Vervollständigen Sie das Server-Routing und testen Sie das Frontoffice, bevor Sie große Datenmengen importieren oder bearbeiten.

Ein kopierter Katalog oder eine kopierte Konfiguration ist ein Ausgangszustand. Nehmen Sie nicht an, dass jeder kopierte Wert mit späteren Änderungen im ursprünglichen Shop verbunden bleibt.

DNS, TLS und Server-Routing konfigurieren

Separate Domains und Subdomains müssen zum Server auflösen. Konfigurieren Sie den Webserver so, dass er für jeden Host dasselbe PrestaShop-Verzeichnis ausliefert, und installieren Sie Zertifikate für jeden HTTPS-Hostnamen. Ein Wildcard-Zertifikat deckt nur Namen innerhalb seines erlaubten Bereichs ab; prüfen Sie die tatsächlichen Zertifikatsnamen.

Die physische URI ist der reale Webpfad der Installation. Die virtuelle URI kennzeichnet einen Frontoffice-Pfad, der kein eigenes Installationsverzeichnis benötigt. Für eine Installation im Domainstamm sind dies Beispielmodelle:

Apache

Konfigurieren Sie zuerst virtuelle Hosts und TLS. Aktivieren Sie die erforderliche Rewrite-Unterstützung und erlauben Sie die Rewrite-Regeln der Installation. Speichern Sie die URL-Einstellungen unter Shop-Einstellungen → Traffic & SEO → SEO & URLs, um die passenden .htaccess-Regeln zu erzeugen. Prüfen und testen Sie das Ergebnis. Die Datei .htaccess konfiguriert weder DNS noch Zertifikate oder virtuelle Hosts.

nginx

nginx liest keine .htaccess. Beginnen Sie mit der PrestaShop-nginx-Konfiguration, einschließlich Asset-Rewrites, geschützter Verzeichnisse und PHP-Verarbeitung. Konfigurieren Sie jeden Host für dasselbe Installationsstammverzeichnis.

Ergänzen Sie bei einer Root-Installation mit virtuellem Shop-Pfad wholesale/ im Serverblock vor den normalen PrestaShop-Rewrites eine Präfix-Umschreibung:

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

Behalten Sie den normalen Front-Controller-Fallback des Frontoffice bei:

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

Die PHP-Parameter müssen die ursprüngliche REQUEST_URI einschließlich /wholesale/ erhalten, damit PrestaShop den Shop identifizieren kann. Die interne Umschreibung lässt dieselben Asset- und Front-Controller-Regeln den virtuellen Pfad bedienen. Passen Sie das Präfix je virtuellem Shop an, behalten Sie alle Sicherheits-Locations bei und prüfen Sie die nginx-Konfiguration vor dem Neuladen. Testen Sie Shopstartseite, benutzerfreundliche URLs, Bilder, Modulrouten, Warenkorb und Checkout.

Bestätigen Sie bei beiden Servern, dass HTTPS und vertrauenswürdige Reverse-Proxy-Header zu den konfigurierten URLs passen. Testen Sie kanonische Weiterleitungen von alternativen Hosts und Pfaden. Leeren Sie relevante Caches nach Änderungen der URL-Konfiguration.

Shop-Kontext und unterschiedliche Datenbereiche verstehen

Lesen Sie vor jedem Speichern die Shop-Auswahl. Wählen Sie je nach geplanter Änderung Alle Shops, eine Shopgruppe oder einen Shop. Der unterstützte Geltungsbereich eines Formulars bestimmt die Wirkung des Speicherns; nehmen Sie nicht an, dass jede Seite jeden Kontext akzeptiert.

Kontrollkästchen können bedeuten, den geerbten Konfigurationswert zu verwenden, zu aktualisierende Felder auszuwählen oder betroffene Shops einer Aktion zu bestimmen. Lesen Sie Beschriftung und Hilfe für dieses Formular und diese Version. Ein Produktaktualisierungs-Kontrollkästchen verspricht keine fortlaufende Vererbung.

Ordnen Sie Produkte und Kategorien nur den vorgesehenen Shops zu. Prüfen Sie vor der Bestätigung den bei Deaktivieren, Zuordnung entfernen und Löschen angezeigten Geltungsbereich. Das Entfernen einer Zuordnung und das Löschen der gemeinsamen Entität haben unterschiedliche Folgen.

Konfigurieren Sie Themes, Logos, aktivierte Sprachen, Währungen, Versanddienstleister, Zahlungsmethoden und Steuern in ihrem unterstützten Kontext. Laden Sie nach dem Speichern die Seite neu und besuchen Sie jedes Frontoffice. Benennen Sie shopspezifische Assets eindeutig, beispielsweise banner-de.jpg, und dokumentieren Sie gemeinsame Assets.

Testen Sie Sprach- und Währungswechsel auf einer Produktseite: Der Besucher sollte beim entsprechenden Produkt ankommen, und die gewählte Währung sollte im Warenkorb und Checkout erhalten bleiben. Dokumentieren Sie vor dem Kopieren von Inhalten oder Konfigurationen zwischen Marken, welchem Shop jede rechtliche Seite und Absenderidentität zugeordnet ist. Zur Markteinrichtung siehe den Leitfaden zu Übersetzungen und internationalem Verkauf.

Module in zwei Shop-Kontexten testen

1. Ermitteln Sie, welche Moduleinstellungen absichtlich global sind und welche je Shop variieren sollten.
2. Speichern Sie im Staging unterschiedliche Werte in zwei Shops. Laden Sie beide Konfigurationsseiten neu und prüfen Sie beide Frontoffices.
3. Testen Sie Hook-Ausgabe, Importe, Cronjobs, Kommandozeilenaufgaben und Cache-Treffer. Diese können in einem anderen Kontext als die Browsersitzung eines Mitarbeiters laufen.
4. Prüfen Sie die Zugehörigkeit eigener Daten über Shopspalten, Zuordnungstabellen oder kontextgebundene übergeordnete Entitäten. Eine Tabelle benötigt keine Spalte id_shop, wenn ein anderes schlüssiges Zugehörigkeitsmodell den Geltungsbereich liefert.
5. Prüfen Sie Cache-Schlüssel auf jede ergebnisrelevante Kontextdimension, einschließlich Shop und relevanter Sprache oder Währung.

Dokumentieren Sie bei ERP-, Lager-, Marktplatz-, Buchhaltungs- und E-Mail-Anbindungen, wie jeder Import, Export und Callback seinen Zielshop bestimmt. Führen Sie geplante Jobs in ihrem tatsächlichen Ausführungskontext aus und prüfen Sie die entstehenden Datensätze und ausgehenden Nutzdaten. Eine Anbindung, die vom Standardshop ausgeht, benötigt eine unterstützte Anpassung oder einen Ersatz, wenn ihr Ablauf weitere Shops bedienen muss; allein eine zusätzliche Shopspalte korrigiert den übrigen Ablauf nicht.

Wenn eine erforderliche Integration eine individuelle Eingrenzung auf Shops benötigt, bietet der PrestaShop Custom Module Development Service eine Umsetzung nach vereinbarter Spezifikation.

Configuration::get() und Configuration::updateValue() leiten bei fehlenden Geltungsbereichsargumenten den aktuellen Shop oder die aktuelle Gruppe ab. Explizite IDs sind nützlich, wenn der Ausführungskontext vom Ziel abweicht. Globale Schreibvorgänge, falscher Kontext, Abfragen ohne Kontextbegrenzung und Cache-Kollisionen benötigen getrennte Diagnosen.

Eine shopspezifische Konfigurationszeile kann mit id_shop_group auf NULL funktionieren. Eine einzelne globale Zeile kann ein geerbter Standard sein. Testen Sie beabsichtigte Lese- und Schreibvorgänge, bevor Sie einen dieser Zustände als Fehler einstufen, und korrigieren Sie den Anwendungspfad, statt Konfigurationszeilen manuell einzufügen.

Kompatibilität ist funktionsspezifisch. Beispielsweise nutzen gewöhnliche Einstellungen von SEO Revolution und der Konfigurations-Wrapper von Financial Revolution globale Konfigurationspfade. Bestätigen Sie den Geltungsbereich jeder Funktion, bevor Sie unabhängige Shopeinstellungen erwarten.

SEO und Leistung je Frontoffice prüfen

Nutzen Sie für separat zu indexierende Seiten bewusst gewählte kanonische URLs innerhalb des jeweiligen Shops. Verwenden Sie ein domainübergreifendes Canonical nur bei beabsichtigter Zusammenführung. Beschränken Sie jede Shop-Sitemap auf ihre vorgesehenen URLs und verifizieren Sie die relevanten Search-Console-Properties.

Native Sprachalternativen betreffen Sprachen im aktuellen Shop. Entsprechende Seiten in getrennten Shops benötigen eine eigene shopübergreifende Zuordnung. Empfehlen Sie hreflang für sprachliche und regionale Alternativen mit Selbstreferenzen, vollständigen URLs und gegenseitigen Links zwischen entsprechenden Seiten. Ein optionales x-default kann auf ein passendes Ausweichziel verweisen.

Wenn Sie generierte Sprachgruppen benötigen, bietet Hreflang Tags Manager eine Prüfvorschau und Gruppen für aktive Sprachen, mit separaten Gruppen über Shops und Domains hinweg. Für Shops mit nur einer aktiven Sprache gibt es keine Tags aus. Testen Sie vor der Auswahl auf Staging die benötigten wechselseitigen Links zwischen gleichwertigen Seiten verschiedener Shops, unterstützte Seitentypen und die Sitemap-Ausgabe. Separate Sprachgruppen pro Shop belegen nicht, dass die erforderliche shopübergreifende Zuordnung vorhanden ist.

Fehlende Rückverweise können dazu führen, dass diese Angaben ignoriert werden, während gültige gegenseitige Beziehungen weiterhin funktionieren. Hreflang ist weder Indexierungsvoraussetzung noch Ranking-Garantie. Befolgen Sie Googles Hinweise zu lokalisierten Seiten und prüfen Sie den gerenderten Verbund.

Messen Sie Katalogabfragen, Zuordnungs-Joins, Konfigurationsladen und Cache-Nutzung unter Ihrer Last. Der Core speichert geladene Konfiguration im Prozess zwischen; nicht jeder Aufruf von Configuration::get() ist eine neue Datenbankabfrage. Globale Standards bedeuten außerdem, dass nicht für jeden Shop eine Konfigurationszeile erforderlich ist.

Nutzen Sie EXPLAIN für langsame Abfragen und prüfen Sie bestehende zusammengesetzte Indizes, bevor Sie einen id_shop-Index ergänzen. Cache-Speicher hängt von Schlüsseln, Kontexten und Invalidierung ab; die Kapazitätsplanung benötigt daher Messungen statt eines Shopanzahl-Multiplikators. Siehe Performance-Leitfaden.

Kontextprobleme beheben und jeden Shop warten

Ein Produkt erscheint im falschen Shop

Prüfen Sie die Zuordnungen im Produkteditor und kontrollieren Sie die Ergebniszeilen. Beide SQL-Beispiele verwenden das Tabellenpräfix ps_; ersetzen Sie es durch das Präfix Ihrer Installation. Dieses schreibgeschützte Beispiel verwendet Produkt 123; setzen Sie eine tatsächliche Produkt-ID ein:

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

Korrigieren Sie Zuordnungen über den unterstützten Editor und prüfen Sie dann Kategoriezugehörigkeit, Sichtbarkeit und zwischengespeicherte Listen.

Speichern wirkt auf beide Shops

Prüfen Sie aktiven Kontext, Feldgeltungsbereich, geerbte Standards und Modulspeicherung erneut. Vergleichen Sie Vorher-/Nachher-Werte in zwei Kontexten. Eine ausschließlich globale Funktion kann wie vorgesehen arbeiten.

Ein Warenkorb erscheint über Shopgrenzen hinweg

Prüfen Sie zuerst die Gruppeneinstellung „Bestellungen gemeinsam nutzen“. Prüfen Sie tatsächlichen Cookie-Namen, Domain und Pfad im Browser, danach die Shop-URLs. Beabsichtigte gemeinsame Gruppennutzung von Warenkörben und ein Isolationsfehler benötigen unterschiedliche Korrekturen. Der Core leitet den Cookie-Geltungsbereich ab; es gibt kein allgemeines Cookie-Domain-Feld unter Shop-Einstellungen → Allgemein.

Ein Import oder eine URL landet im falschen Shop

Wählen Sie den Zielshop vor dem Öffnen des Importwerkzeugs. Erproben Sie einen kleinen Import und prüfen Sie Zuordnungen. Prüfen Sie bei Weiterleitungen DNS, virtuelle Hosts, Zertifikate, Proxy-Header, kanonische Einstellungen und diese URL-Zeilen:

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;

Regelmäßige Prüfungen

• Laden Sie jedes Frontoffice und prüfen Sie Theme, Produkte, Sprache, Preise und Weiterleitungen.
• Testen Sie Checkout, Zahlungsmethoden, Bestandswirkungen und den in Bestellungen gespeicherten Shop.
• Prüfen Sie shopbezogene Moduleinstellungen, Protokolle, Absenderdomains und Test-E-Mails.
• Prüfen Sie Sitemap-Antworten und Produktzuordnungen nach Importen.
• Wiederholen Sie nach Modul- oder Core-Updates die Prüfungen in jedem Shop, prüfen Sie URLs und invalidieren Sie betroffene Caches.

Umschaltung und Betriebsübergabe planen

1. Dokumentieren Sie, welche Katalog-, Kunden- und Bestelländerungen seit dem Erstellen der Staging-Kopie erfolgt sind. Vereinbaren Sie, wie die getestete Konfiguration ins Produktivsystem gelangt, ohne diese Änderungen mit einer alten Datenbank zu überschreiben.
2. Wählen Sie das Umschaltfenster und benennen Sie die Person, die Importe und Schreibzugriffe kontrolliert. Entscheiden Sie, ob Schreibvorgänge pausieren müssen und wie laufende Zahlungen, Bestellungen und Lageraktualisierungen abgeglichen werden.
3. Erproben Sie die Wiederherstellung des vollständigen Backups und definieren Sie die Fehlerbedingungen, die einen Rollback auslösen. Gehen nach der Umschaltung neue Bestellungen ein, sichern und prüfen Sie diese vor der Wiederherstellung; ein Backup vor dem Start enthält diese Bestellungen nicht.
4. Nutzen Sie die oben genannten regelmäßigen Prüfungen als Freigabekriterien für jeden Shop. Weisen Sie jeder Prüfung eine zuständige Person zu und dokumentieren Sie das Ergebnis, bevor Sie das neue Frontoffice an die Mitarbeiter übergeben.

Fragen an Ihren Entwickler oder Ihre Agentur

• Welche benötigten Modulfunktionen wurden in getrennten Shopkontexten getestet, und welche bleiben konzeptbedingt global?
• Wie bewahrt jede Anbindung die Shopzuordnung über geplante Aufgaben, Callbacks und externe Referenzen hinweg?
• Können Sie einen Rollback demonstrieren und nach der Umschaltung eingegangene Bestellungen berücksichtigen?
• Welche Mitarbeiter dürfen gruppenweite oder globale Änderungen vornehmen, und wo befinden sich die Shopübersicht und Betriebsanweisungen?

Lassen Sie Mitarbeiter eine shopbezogene Preisänderung erproben und das Ergebnis im anderen Frontoffice prüfen, bevor die reguläre Bearbeitung beginnt. Halten Sie fest, wer Änderungen an gemeinsam genutzten Feldern freigibt, damit neue Teammitglieder wissen, wann eine scheinbar lokale Änderung eine umfassendere Prüfung erfordert.

Häufige Fragen von Shopbetreibern

Behalten Kunden ihre Passwörter, wenn wir getrennte Shops zusammenführen?

Verlangen Sie bei der Migrationsprobe einen Nachweis der Anmeldung mit bestehenden Konten und vereinbaren Sie den Umgang mit doppelten E-Mail-Adressen. Versprechen Sie die Weiterverwendung von Konten nicht allein aufgrund der Multishop-Aktivierung und führen Sie Identitäten nicht bloß wegen übereinstimmender E-Mail-Adressen zusammen.

Sieht bei einem Backoffice jeder Mitarbeiter alle Shops?

Prüfen Sie Mitarbeiterberechtigungen und Shopzuordnungen. Melden Sie sich anschließend als eingeschränkter Mitarbeiter an und testen Sie den Zugriff auf Bestellungen, Kunden und Moduloberflächen. Prüfen Sie auch Exporte: Eine eingeschränkte Ansicht reicht nicht aus, wenn ihr Export Datensätze eines anderen Shops enthält.

Können wir später eine Marke übergeben oder verkaufen?

Planen Sie eine Herauslösung, bevor Sie sich für gemeinsam genutzte Entitäten entscheiden. Verlangen Sie einen abgegrenzten Export und einen Probelauf für Bestellungen, Kunden, Katalogzuordnungen, Medien und externe Referenzen dieses Shops, mit vereinbartem Umgang mit Datensätzen, die auch andere Shops nutzen.

Brauchen wir für jeden Shop ein Zahlungskonto?

Prüfen Sie die beteiligten Händlerunternehmen und den Anbietervertrag und testen Sie anschließend die shopbezogenen Zugangsdaten und die Benachrichtigungszuordnung der Anbindung. Eine zentrale Verwaltung entscheidet nicht, welches Unternehmen das Geld erhält; gleichen Sie jede Testzahlung mit dem vorgesehenen Konto und der Bestellung ab.