DataFirefly Staging Pro — Vollständige Anleitung

Staging Pro erstellt eine vollständige Kopie Ihres Shops (Dateien + Datenbank) in einem geschützten Unterordner Ihres aktuellen Hostings — dank der Batch-Copy-Engine ohne jegliches Timeout. Sie testen Module, Themes und Updates sicher und übertragen Ihre Änderungen anschließend Tabelle für Tabelle zurück in die Produktion, mit automatischem Backup und Rollback per Klick. Diese Anleitung behandelt Installation, Erstellung einer Staging-Site, Schutzoptionen, Push in die Produktion und Rollback.

Installation

1. Laden Sie das Archiv dfstagingpro.zip aus Ihrem DataFirefly-Konto herunter.
2. PrestaShop-Backoffice → Module → Modul hochladen → senden Sie die ZIP-Datei.
3. Bei der Installation erstellt das Modul seine Tabellen df_staging_env und df_staging_log, registriert seine Hooks und fügt den Tab Erweiterte Parameter → Staging Pro hinzu.

Wie Staging funktioniert

Eine Staging-Umgebung wird in einem Unterordner im Stammverzeichnis Ihres Shops erstellt (zum Beispiel /staging-v2/) und verwendet ein eigenes Tabellenpräfix (zum Beispiel dfs1_) in derselben Datenbank wie die Produktion. Sie benötigen also weder einen zweiten Server noch einen neuen MySQL-Zugang noch eine DNS-Konfiguration.

Die Copy-Engine arbeitet in Batches von wenigen Sekunden und gibt dann die Kontrolle zurück, wobei sie genau dort fortsetzt, wo sie aufgehört hat: Dateikopie über eine persistente Warteschlange, Datenbank-Klonen in Zeilenpaketen. Ein mehrere Gigabyte großer Shop klont fehlerfrei, selbst auf Shared Hosting mit niedrigem max_execution_time.

Eine Staging-Site erstellen

Gehen Sie zu Erweiterte Parameter → Staging Pro und im Erstellungspanel:

1. Geben Sie einen Namen ein (nur Kleinbuchstaben, Ziffern und Bindestriche, zum Beispiel v2). Die Staging-URL lautet dann ihr-shop.com/staging-v2/.
2. Wählen Sie Ihre Schutz- und Kopieroptionen (siehe unten).
3. Klicken Sie auf Erstellen. Der Fortschritt wird live mit einem Fortschrittsbalken angezeigt.

Am Ende des Vorgangs erscheinen die Staging-URL und gegebenenfalls die htpasswd-Zugangsdaten in der Zeile der Umgebung.

Schutz- und Kopieroptionen

• Mit .htpasswd schützen: fügt eine HTTP-Authentifizierung hinzu (Benutzer staging). Das Passwort kann eingegeben oder automatisch generiert und anschließend im Dashboard angezeigt werden.
• E-Mails deaktivieren: schaltet die ausgehenden E-Mails der Staging-Site ab (PS_MAIL_METHOD = 3). Kein Risiko, einem echten Kunden zu schreiben.
• Zahlungen deaktivieren: deaktiviert und hookt die bekannten Zahlungsmodule auf der Staging-Site aus.
• Statistiken überspringen: schließt große, nicht wesentliche Tabellen von der Kopie aus (Verbindungen, Logs, abgebrochene Warenkörbe…) für eine deutlich schnellere Kopie.
• Ohne Kundendaten: legt die Tabellen für Kunden, Kundenadressen, Bestellungen, Warenkörbe, Nachrichten, Gäste, Newsletter und DSGVO-Logs auf dem Staging leer an. Adressen von Lieferanten, Herstellern und Lagern bleiben erhalten, ebenso die Konfigurationstabellen der Bestellungen (Status, Nachrichtenvorlagen, Rücksendestatus, Warenkorbregeln). Siehe den eigenen Abschnitt weiter unten.
• Symlink des img/-Ordners: erstellt einen symbolischen Link zu den Bildern, statt sie zu kopieren — für enorme Speicherersparnis.
• Wartungsmodus: versetzt die Staging-Site in den Wartungsmodus mit Ihrer Admin-IP auf der Whitelist.

Die Batch-Copy-Engine

Die Erstellung einer Staging-Site verkettet mehrere Schritte, jeder zeitbudgetiert und automatisch wieder aufgenommen: Vorbereiten, Dateien kopieren, Datenbank klonen, URLs umschreiben, konfigurieren und schützen, dann finalisieren. Das URL-Rewriting umfasst shop_url, die Konfiguration (einschließlich serialisierter und JSON-Werte, ohne Beschädigung verarbeitet) sowie CMS-Inhalte, Produkte, Kategorien, Marken, Lieferanten und Shops.

Refresh, Multi-Umgebung und Löschung

• Refresh: baut eine bestehende Staging-Site aus dem aktuellen Produktionsstand neu auf (Ordner und Präfix löschen und neu erstellen), per Klick.
• Multi-Umgebung: erstellen Sie beliebig viele Staging-Sites (v2, Hotfix, Modultest…), jede unabhängig.
• Löschung: löscht Ordner und Tabellen einer Umgebung budgetiert, ohne Timeout.

Push in die Produktion

Sobald Ihre Tests validiert sind, können Sie mit der Schaltfläche Push Ihre Änderungen Tabelle für Tabelle in die Produktion zurückübertragen:

1. Klicken Sie in der Zeile der Umgebung auf Push: Die Liste der Tabellen erscheint, mit der Zeilenanzahl jeder Tabelle.
2. Wählen Sie genau die zu übertragenden Tabellen aus.
3. Bestätigen Sie. Vor jedem Ersetzen wird die entsprechende Produktionstabelle automatisch durch eine Umbenennung mit Zeitstempel auf ein Präfix dfbak{Zeitstempel}_ gesichert.

Die URLs werden während der Übertragung in Richtung Staging → Produktion umgeschrieben. Kritische Tabellen (shop_url, configuration, shop, Sessions und Modultabellen) sind geschützt und können niemals gepusht werden.

Rollback

Die Schaltfläche Rollback stellt die Produktion aus dem letzten Push-Backup wieder her, per Klick. Das Modul benennt die Backup-Tabellen dfbak…_ zurück an ihren ursprünglichen Platz.

Sicherheitsmechanismen und Protokoll

• Alle Aktionen werden blockiert, wenn der aktuelle Shop selbst eine Staging-Site ist, um Kaskadenoperationen zu vermeiden.
• Über die Schaltfläche Logs ist ein detailliertes Protokoll pro Umgebung verfügbar.
• Da eine robots.txt in einem Unterordner von Suchmaschinen nicht beachtet wird, beruht der eigentliche Schutz vor Indexierung auf dem X-Robots-Tag-Header und dem noindex-Meta-Tag; die .htpasswd-Option bleibt der sicherste Schutz.

Kompatibilität und technische Hinweise

• PrestaShop 8.0 bis 9.x, kompatibel mit Shared Hosting und mehrsprachig.
• Legacy-Admin-Controller (kein Symfony-Controller) für PS8/PS9-Kompatibilität.
• Backoffice-AJAX-Endpunkte über das 4. Argument von getAdminLink(); JSON-Rendering über eine dedizierte Methode.
• Staging = Unterordner im Stammverzeichnis + Tabellenpräfix dfs{id}_ in derselben MySQL-Datenbank.
• Push-Backups mit Zeitstempel unter dem Präfix dfbak{YmdHis}_, nach der Validierung zu bereinigen.

Staging ohne Kundendaten

Die Option Ohne Kundendaten, verfügbar seit Version 1.1.0, erstellt das Staging ganz ohne personenbezogene Daten. Die betroffenen Tabellen werden mit ihrer exakten Struktur angelegt, bleiben aber leer. Das ist die empfohlene Wahl, wenn Sie ein Staging an einen externen Dienstleister übergeben, für Theme- oder Modultests ohne Checkout und um die DSGVO-Angriffsfläche Ihrer Testumgebungen zu verkleinern.

Was nicht kopiert wird

• Kunden, Kundengruppen, Support-Threads und -Nachrichten, Kundensessions, Gäste und Verbindungsstatistiken.
• Bestellungen und die gesamte zugehörige Familie: Details, Historie, Rechnungen, Zahlungen, Versanddienstleister, angewendete Warenkorbregeln, Gutschriften und Rücksendungen.
• Warenkörbe, Warenkorbprodukte, Wunschlisten, Nachrichten, Newsletter-Anmeldungen, DSGVO-Logs und Mail-Logs.
• Kundenadressen: Die Tabelle address wird mit einem Filter kopiert, nur die einem Kunden zugeordneten Zeilen entfallen.

Was erhalten bleibt

• Adressen von Lieferanten, Herstellern, Lagern und Filialen.
• Konfigurationstabellen der Bestellungen: Bestellstatus und deren Übersetzungen, Nachrichtenvorlagen, Rücksendestatus, Gutschriftarten.
• Warenkorbregeln, Gutscheine, Versanddienstleister, Steuern und der gesamte Katalog.
• Backoffice-Mitarbeiter: Sie melden sich am Staging mit Ihren gewohnten Zugangsdaten an.

HTTP-Authentifizierung und cPanel-/LiteSpeed-Hostings

Seit Version 1.0.1 wird die Datei .htpasswd im Format APR1-MD5 erzeugt (das Format von htpasswd -m), das Apache, LiteSpeed und nginx gleichermaßen lesen. Version 1.0.0 verwendete bcrypt, das LiteSpeed (sehr verbreitet hinter cPanel) nicht lesen kann: Das Staging antwortete dann auf allen Seiten mit 404.

Der Schutzblock enthält außerdem eine Inline-401-Fehlerseite. Unter cPanel wird der Fehler 401 global auf /401.shtml umgeleitet, eine Seite, die in PrestaShop nicht existiert: Die Unteranfrage landet im Dispatcher der Produktion und liefert deren 404-Seite, sodass der Browser den Anmeldedialog nie anzeigt. Die Inline-Seite umgeht diese Umleitung.

Schließlich wird die Zeile ErrorDocument 404 der kopierten .htaccess auf den Staging-Unterordner umgeschrieben: Ein Fehler im Staging zeigt die 404-Seite des Stagings, nicht die der Produktion.

Selbsttest bei der Erstellung

Am Ende der Konfiguration sendet das Modul eine HEAD-Anfrage an die robots.txt des Stagings, mit den Zugangsdaten, falls der Schutz aktiv ist, und anschließend ohne Zugangsdaten, um zu prüfen, ob der Server mit 401 antwortet. Das Ergebnis wird im Protokoll der Umgebung festgehalten:

• 200 mit Zugangsdaten und 401 ohne: alles in Ordnung.
• Der Server lehnt den Authentifizierungsblock ab: Das Modul entfernt den Block und die .htpasswd, deaktiviert die Option und zeigt „Ready with warning“ in der Zeile der Umgebung. Das Staging ist dann ohne Passwort erreichbar; aktivieren Sie den Wartungsmodus.
• Code 0: Der Server kann sich nicht selbst aufrufen (ausgehende Anfragen blockiert). Öffnen Sie die Staging-URL manuell.

FAQ und Fehlerbehebung

Funktioniert das Modul auf Shared Hosting? Ja. Die Batch-Copy-Engine mit automatischer Wiederaufnahme vermeidet jedes Timeout, unabhängig vom max_execution_time des Servers.

Die Erstellung wurde unterbrochen, was tun? Öffnen Sie das Staging-Pro-Dashboard erneut: Die Umgebung nimmt die Kopie automatisch dort wieder auf, wo sie aufgehört hat.

Kann die Staging-Site E-Mails an meine Kunden senden? Nicht, wenn die Option „E-Mails deaktivieren“ aktiv ist (empfohlen): Die ausgehenden E-Mails sind auf der Staging-Site abgeschaltet.

Wie mache ich einen Push rückgängig? Verwenden Sie die Schaltfläche Rollback, die das letzte automatische Backup wiederherstellt. Bereinigen Sie anschließend die veralteten dfbak*-Tabellen.

Kann ich mehrere Staging-Sites gleichzeitig erstellen? Ja, die Anzahl der Umgebungen ist unbegrenzt und jede ist vollständig unabhängig.

Das Staging antwortet überall mit 404, oder der Anmeldedialog erscheint nicht? Das ist das in 1.0.1 behobene Symptom auf cPanel-/LiteSpeed-Hostings. Aktualisieren Sie das Modul und starten Sie einen Refresh der Umgebung; siehe den Abschnitt „HTTP-Authentifizierung und cPanel-/LiteSpeed-Hostings“ oben.

Kann ich ein Staging ohne die Daten meiner Kunden erstellen? Ja, aktivieren Sie bei der Erstellung „Ohne Kundendaten“. Siehe den Abschnitt „Staging ohne Kundendaten“ oben.

Versionsverlauf

1.1.0 (4. September 2026)

• Neue Option „Ohne Kundendaten“: Kunden, Kundenadressen, Bestellungen, Warenkörbe, Nachrichten, Gäste, Newsletter und DSGVO-Logs werden auf dem Staging leer angelegt.
• Adressen von Lieferanten, Herstellern und Lagern bleiben erhalten, ebenso die Konfigurationstabellen der Bestellungen.
• Push-Schutz: Diese Tabellen werden aus der Liste entfernt und serverseitig abgelehnt, wenn das Staging ohne Kundendaten erstellt wurde.

1.0.1 (3. September 2026)

• htpasswd-Schutz: Hash wird als APR1-MD5 erzeugt, kompatibel mit Apache und LiteSpeed (bcrypt wurde auf manchen cPanel-Hostings abgelehnt, das Staging war dann nicht erreichbar).
• HTTP-Login-Dialog: Inline-401-Seite für Hostings, die 401-Fehler auf eine nicht vorhandene Seite umleiten.
• ErrorDocument-Zeile der .htaccess auf den Staging-Unterordner umgeschrieben.
• Selbsttest am Ende der Erstellung: HTTP-Prüfung des Stagings, automatisches Entfernen des Schutzes, wenn der Server ihn ablehnt, Warnhinweis im Dashboard.

1.0.0 (11. Juni 2026)

Erste öffentliche Version.