Anleitungen Anleitung

So erstellen Sie eine PrestaShop-Staging-Seite

Anleitung zur PrestaShop Staging-Umgebung: Docker, Shared Hosting und lokale Entwicklung. Updates scheitern im Staging, nicht im Live-Shop.

Warum wir für jedes Projekt, das wir anfassen, Staging-Shops betreiben

Bei mypresta.rocks betreiben wir mehrere Staging-Umgebungen nebeneinander, darunter ps9-dev, ps8-dev, ps178-dev und ps176-dev, dazu kundenspezifische Shops, wenn ein Projekt seinen eigenen Klon braucht. Sie sind kein Luxus. Sie sind die Art und Weise, wie wir jedes Modul-Update, jedes PrestaShop-Upgrade und jede Theme-Änderung testen, bevor ein Kunde sie zu Gesicht bekommt. Nach einem Jahrzehnt der Modul-Auslieferung haben wir noch nie einen Händler getroffen, der es bereut hätte, einen einzurichten, und viele, die es bereut haben, darauf zu verzichten.

Das Muster ist immer dasselbe: Ein Modul-Update geht ungetestet in die Produktion, um 9 Uhr morgens bricht die Startseite zusammen, um 9:05 Uhr trifft das Support-Ticket ein, und die nächste Stunde wird mit Fehlersuche vor echten Kunden verbracht. Ein Staging-Shop kostet eine Stunde Aufbau und verwandelt dieses Szenario in eine 20-Minuten-Korrektur auf einer URL, die niemand sehen kann.

Die Kosten einer einzigen Stunde Ausfallzeit während eines Verkaufs übersteigen die Kosten für den Betrieb einer Testumgebung um zwei Größenordnungen. Wenn Sie im Internet Ihren Lebensunterhalt verdienen, brauchen Sie einen Staging-Shop.

Was ein Staging-Shop tatsächlich ist

Es ist ein vollständiger Klon Ihres Produktiv-Shops (dieselben Dateien, dieselbe Datenbank, derselbe Modulsatz), ausgeliefert über eine URL, die nur Sie und Ihr Team erreichen können. Dieselben Codepfade, die Ihre Kunden treffen, dieselbe Geschäftslogik, dieselben Grenzfälle. Die einzigen Unterschiede sind der Hostname, die Zugangsdaten und (wenn Sie es ordentlich eingerichtet haben) die Tatsache, dass keine echten E-Mails verschickt und keine echten Karten belastet werden.

Es ist keine Entwicklungsumgebung für Arbeiten auf der grünen Wiese, und es ist kein Backup. Wir haben erlebt, dass beide Missverständnisse Händler echtes Geld gekostet haben: Staging wird in dem Moment überschrieben, in dem Sie es aktualisieren, sodass alles, was Sie dort gebaut und nicht in die Produktion übertragen haben, verloren ist.

Was Staging ist

  • Eine Live-Kopie Ihrer Produktivdateien und -datenbank
  • Auf einer separaten Domain oder Subdomain (wir verwenden staging.yourshop.com oder dev.yourshop.com)
  • Hinter einer IP-Whitelist oder Basic Auth gesperrt, sodass nur Ihr Team hineinkommt
  • Wo Modul-Updates, Theme-Änderungen und PHP-Upgrades geprobt werden

Was es nicht ist

  • Eine Entwicklungs-Sandbox, um neuen Code von Grund auf zu bauen. Das ist ein separater Dev-Shop
  • Ein Backup. Backups sind unveränderlich. Staging wird bei jeder Aktualisierung überschrieben.
  • Einrichten und vergessen. Ein Staging-Shop, der sechs Monate nicht mit der Produktion synchronisiert ist, fängt nichts ab.

Option 1: Docker-basiertes Staging (was wir verwenden)

Alle unsere Staging-Shops laufen auf Docker auf einer einzigen TrueNAS-Box. Jeder Shop ist ein docker-compose-Stack in einem gemeinsamen Docker-Netzwerk, PrestaShop-Container, MySQL-Container, gemeinsames Redis, ein Bind-Mount für das html-Verzeichnis, eines für die MySQL-Daten. Wir können eine neue PS-Version in unter fünf Minuten hochfahren und sie wieder abbauen, um RAM freizugeben, wenn wir damit fertig sind. Wenn Sie das einmal gemacht haben, kehren Sie nie wieder zu „Ich installiere es einfach in einem Unterordner von cPanel“ zurück.

Voraussetzungen

  • Ein Linux-Host mit mindestens 2 GB RAM pro Staging-Shop (4 GB, wenn sich der Administrationsbereich flott anfühlen soll)
  • Docker und Docker Compose installiert und funktionsfähig
  • SSH-Zugang sowohl zur Produktion als auch zum Staging
  • Sie fühlen sich beim Kopieren und Einfügen von Shell-Befehlen wohl

Schritt 1: die Compose-Datei

Legen Sie ein Verzeichnis und eine docker-compose.yml an:

mkdir ~/your-shop-staging && cd ~/your-shop-staging

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: <your-shop>
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=root
      - DB_PASSWD=your_secure_password
    volumes:
      - ./html:/var/www/html
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mysql:5.7
    container_name: <your-shop>-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Stimmen Sie das PrestaShop-Image-Tag exakt auf Ihre Produktivversion ab. Wenn die Produktion 1.7.8.11 ist, verwenden Sie prestashop/prestashop:1.7.8.11, nicht 1.7. Wir haben Händlern dabei zugesehen, wie sie stundenlang Phantom-Bugs hinterherjagten, weil Staging auf 1.7.8.10 und die Produktion auf 1.7.8.11 lief, klein genug, um identisch auszusehen, groß genug, um sich anders zu verhalten.

Schritt 2: Produktion dumpen

Per SSH auf die Produktion verbinden und mysqldump ausführen. Verwenden Sie --single-transaction bei einem laufenden Shop, damit Sie die Bestelltabelle nicht sperren, während Kunden gerade an der Kasse sind:

# Auf Ihrem Produktivserver
mysqldump -u root -p prestashop > ~/prestashop_backup.sql

# Auf den lokalen Rechner / Staging-Server herunterladen
scp user@production-server:~/prestashop_backup.sql ./

Schritt 3: in das Staging importieren

# Die Container starten
docker compose up -d

# Etwa 30 Sekunden warten, bis MySQL initialisiert ist, dann importieren
docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Falls sich MySQL beim Import über den Zeichensatz beschwert, setzen Sie SET NAMES utf8mb4; an den Anfang der SQL-Datei. Wir haben mehr Zeit als uns lieb ist mit dem Debuggen von doppelt kodiertem UTF-8 im Staging verbracht, das auf der Produktion nicht existierte.

Schritt 4: Produktivdateien kopieren

# Ihre Produktivdateien in das Staging-html-Verzeichnis synchronisieren
rsync -avz --delete \\
  user@production-server:/var/www/html/ \\
  ./html/ \\
  --exclude='var/cache/*' \\
  --exclude='var/logs/*' \\
  --exclude='app/config/parameters.php'

Schließen Sie parameters.php immer von rsync aus. Die DB-Zugangsdaten darin gehören zur Produktion, wenn Sie zulassen, dass rsync sie überschreibt, versucht Ihr Staging-Shop, sich mit Ihrer Produktivdatenbank zu verbinden, was das denkbar schlechteste Ergebnis von „Staging einrichten“ ist. Wir haben das 2017 bei einem Kundenprojekt auf die harte Tour gelernt und seitdem das Exclude-Flag automatisch gesetzt.

Schließen Sie außerdem alle Laufzeitverzeichnisse aus, in die der Shop in der Produktion schreibt. Sitemaps, generierte Bilder, die Sie nicht brauchen, Backup-Ordner, Lizenzschlüssel. rsync --delete löscht die Zielseite, und übereifrige rsyncs haben schon mehr als einmal generierte Sitemaps gelöscht und die Google Search Console zerschossen, während wir zusahen.

Schritt 5: URLs umschreiben und Cache leeren

Die mit Abstand häufigste Ursache für „Warum funktioniert mein Staging-Shop nicht“: ps_shop_url zeigt immer noch auf die Produktion. Korrigieren Sie es:

docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

Aktualisieren Sie html/app/config/parameters.php mit den Staging-DB-Zugangsdaten aus Ihrer Compose-Datei. Dann leeren Sie den Cache gründlich:

docker exec <your-shop> rm -rf /var/www/html/var/cache/*

Wenn Sie das Leeren des Caches überspringen, betten Smartys kompilierte Templates weiterhin die Produktiv-URL ein, und Sie erhalten Weiterleitungsschleifen zurück zum Live-Shop. Bei jedem Shop, der OPcache verwendet (was in der Produktion auf alles zutrifft), starten Sie auch PHP-FPM neu oder rufen Sie den OPcache-Reset-Endpunkt auf.

Option 2: Subdomain auf Shared Hosting

Docker ist auf cPanel, Plesk oder DirectAdmin nicht verfügbar. Dasselbe Ergebnis erzielen Sie mit einer Subdomain, einer zweiten Datenbank und einer Dateikopie.

Die Subdomain anlegen

  1. Im Hosting-Panel zu Subdomains oder Domains wechseln
  2. staging.yourshop.com hinzufügen
  3. Sie auf ein neues Verzeichnis wie /home/user/staging.yourshop.com zeigen lassen

Eine separate Datenbank anlegen

  1. MySQL-Datenbanken öffnen
  2. Etwas wie user_staging erstellen
  3. Einen Benutzer mit vollen Rechten darauf erstellen oder zuweisen

Dateien kopieren und den Dump importieren

Über SSH:

cp -r /home/user/public_html/* /home/user/staging.yourshop.com/
# Produktion exportieren
mysqldump -u user -p production_db > ~/staging_import.sql

# In das Staging importieren
mysql -u user -p staging_db < ~/staging_import.sql

Bearbeiten Sie app/config/parameters.php (oder config/settings.inc.php bei 1.6), damit es auf die neue Datenbank zeigt, und führen Sie dann dasselbe URL-Umschreibe-SQL aus Option 1, Schritt 5 aus. Vergessen Sie nicht, danach var/cache/ zu löschen.

Option 3: lokale Entwicklung mit XAMPP/MAMP

Geeignet für Arbeiten der Art „Lassen Sie mich zehn Minuten den Admin-Bildschirm dieses Moduls prüfen“, nutzlos für alles andere. Die PHP-Version, die MySQL-Version, das Dateirechte-Modell und die Erweiterungen auf Betriebssystemebene werden sich alle von Ihrem Produktivserver unterscheiden. Wir verwenden selbst lokale Stacks, aber nie als letzten Test vor dem Deployment. Alles, was kurz davor ist, die Produktion zu berühren, wird auf einem serverbasierten Staging erneut getestet, das die Produktivumgebung spiegelt.

Nach der Einrichtung: die Dinge, die Sie beißen, wenn Sie sie vergessen

Ausgehende E-Mails sofort abschalten

Ihre Staging-Datenbank enthält jede echte Kunden-E-Mail-Adresse. Lösen Sie ein Passwort-Reset, eine Bestellbestätigung oder einen Bestandsbenachrichtigungs-Cron aus, und diese E-Mails gehen an echte Kunden. Wir haben Händler erlebt, die sich öffentlich entschuldigen mussten, weil ihr Staging-Cron „Ihre Bestellung wurde versendet“ an tausend echte Kunden geschickt hatte, deren Bestellungen tatsächlich nicht versendet worden waren.

Gehen Sie zu Erweiterte Parameter → E-Mail und wählen Sie entweder:

  • Setzen Sie die Methode auf „E-Mails niemals versenden“: die einzige vollständig sichere Option
  • Leiten Sie alles über Mailtrap, sodass Sie die gerenderten E-Mails weiterhin prüfen können, ohne sie zuzustellen

Zahlungsmodule deaktivieren

Stripe, PayPal, Klarna, Adyen. Alles, was mit einem echten Händlerkonto verbunden ist. Deaktivieren Sie die Module im Staging entweder vollständig oder schalten Sie jedes einzelne in den Sandbox-/Testmodus. Dasselbe gilt für Versand-APIs (UPS, DHL, GLS-Labels) und jedes Modul, das einen externen Dienst mit abrechenbaren Nebeneffekten aufruft.

Suchmaschinen aussperren

Ein von Google indexierter Staging-Shop ist eine Duplicate-Content-Katastrophe. Drei Dinge sollten Sie tun, doppelt abgesichert:

  • Deaktivieren Sie die XML-Sitemap unter Shop-Parameter → Traffic & SEO
  • Legen Sie eine robots.txt mit User-agent: * und Disallow: / im Stammverzeichnis ab
  • Besser noch: Sperren Sie den öffentlichen Zugang vollständig (nächster Abschnitt), damit Google es gar nicht erst erreicht

Hinter einer IP-Whitelist sperren

Der zuverlässigste Ansatz ist eine IP-Beschränkung auf Apache- oder Nginx-Ebene. Der Wartungsmodus kann umgangen werden, wenn die Einstellung der IP-Whitelist einen Fehler hat, und HTTP Basic Auth bricht manchmal AJAX-lastige Module (wir haben erlebt, wie es unsere eigenen Admin-Panels lahmgelegt hat, als der Browser den Auth-Header nicht durch XHR tragen konnte). Eine IP-Whitelist auf Webserver-Ebene fängt alles ab, bevor PrestaShop überhaupt läuft.

PrestaShop-Wartungseinstellungen mit Shop-Schalter, Wartungs-IP-Feld und individueller Meldung

Staging mit der Produktion synchron halten

Ein Staging-Shop, der drei Monate veraltet ist, ist schlimmer als gar kein Staging-Shop. Er gibt Ihnen falsches Vertrauen. Wir aktualisieren unsere nach einem Zeitplan und vor jedem bedeutenden Deployment.

Wann aktualisieren

  • Vor jeder relevanten Änderung: Modul-Update, Core-Upgrade, PHP-Versionssprung, Theme-Überarbeitung
  • Mindestens monatlich, wenn Sie aktiv entwickeln
  • Nach jeder großen Katalogänderung in der Produktion, neue Kategoriebäume, strukturelle Produktänderungen, Umstellungen von Eigenschaften/Attributen

Aktualisierungsskript (Docker)

#!/bin/bash
# refresh-staging.sh: Neueste Produktivdaten in das Staging ziehen

# 1. Produktiv-DB dumpen
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. In das Staging importieren
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. URLs korrigieren
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

# 4. Dateien synchronisieren
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Cache leeren
docker exec <your-shop> rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Die Fehler, die wir Händler immer noch machen sehen

Produktiv-API-Schlüssel verbleiben am Platz

Die Anzahl der Staging-Shops, die wir auditiert haben und die heimlich echte Stripe-Belastungen auslösten, echte Versand-APIs für Live-Tracking-Labels ansprachen oder Live-API-Rate-Limits aufbrauchten, weil die Schlüssel mit der Datenbank mitkamen, zu viele, um sie zu zählen. Rotieren Sie jeden externen Zugangsschlüssel im Staging auf einen Sandbox-Schlüssel in dem Moment, in dem die Datenbank landet, bevor Sie überhaupt den Administrationsbereich öffnen.

Crons feuern weiterhin

Wenn Sie auf der Produktion Cron-Jobs eingerichtet haben (Erinnerungen an abgebrochene Warenkörbe, Bestandsabgleich, Feed-Generierung, Lizenzverlängerungen), prüfen Sie, dass Ihr Hosting-Panel oder Ihre systemd-Timer nicht dieselben Jobs auf dem Staging-Hostnamen ausführen. Wir hatten einen Kunden, dessen Staging-Shop zwei Wochen lang fröhlich echte Allegro-Bestandsupdates verschickte, bevor es jemandem auffiel.

Beide Administrationsbereiche im selben Browser geöffnet

PrestaShops Admin-Cookies sind auf die Domain beschränkt, aber Sitzungskonflikte treten trotzdem auf, wenn Sie beide Shops im selben Browser angemeldet haben. Verwenden Sie für das Staging einen separaten Browser, ein separates Profil oder ein Inkognito-Fenster. Jedes Mitglied unseres Teams hat ein dediziertes Firefox-Profil für Kunden-Staging-Shops.

Wann auf dem Staging testen vs. wann die Produktion in Ordnung ist

Immer zuerst stagenDirekt auf der Produktion sicher
PrestaShop-Core-Upgrades (1.7 → 8, 8 → 9)Inhaltsbearbeitungen, CMS-Seiten, Produkttexte
Modulinstallationen oder größere VersionssprüngePreisänderungen
Theme-Upgrades oder Child-Theme-ArbeitenBereits getestete Module ein-/ausschalten
PHP-VersionssprüngeNeue Produkte, Kategorien, Tags hinzufügen
Eigener Code, Overrides, Service-DecoratorsVersand- oder Steuerregel-Bearbeitungen
Datenbankmigrationen oder strukturelles SQLÜbersetzungsanpassungen

Die Stunde wert

Die erste Staging-Einrichtung dauert etwa eine Stunde. Eine Aktualisierung dauert, sobald das Skript steht, fünf Minuten. Das erste Mal, dass das Staging ein Modul-Update abfängt, das Ihre Kasse zerschossen hätte, haben Sie die Investition zehnmal wieder hereingeholt, und wir haben es auf echten Shops, die wir betreiben, geschehen sehen. Docker ist das, wozu wir greifen würden, wenn Sie einen VPS oder eine dedizierte Box haben; das Klonen per Subdomain ist die richtige Wahl bei Shared Hosting. So oder so ist das Ziel dasselbe: Nichts Ungetestetes berührt Ihre Kunden.

Wenn Sie Staging speziell einrichten, um unsere Module zu testen, gibt Ihnen unser Vor dem Kauf testen-Programm eine volle 30-tägige Demo jedes Moduls, installieren Sie es im Staging, nehmen Sie es genau unter die Lupe, entscheiden Sie sich, bevor Sie zahlen.

Weiterführende Lektüre

Verwandte Module

Passende Fragen

Nach oben