Testumgebung für PrestaShop: So richten Sie eine Kopie ein, die niemanden stört

Änderungen auf einer Kopie des Shops zu testen, bevor sie live gehen, gehört zum Vernünftigsten, was Sie tun können. Aber eine Kopie ist per Definition ein vollständiger Shop: Sie hat dieselben Kunden, dieselbe E-Mail-Konfiguration, dieselben Schlüssel der Zahlungsanbieter und dieselben geplanten Aufgaben. Wenn Sie sie nicht sauber abkoppeln, tut sie genau dasselbe wie der echte Shop, und dazu gehört, Ihren Kunden zu schreiben.

Dieser Artikel ist eine Liste dessen, was in einer Testkopie neutralisiert werden muss, in der Reihenfolge, in der es sich empfiehlt.

Wo Sie sie einrichten

Es gibt drei übliche Möglichkeiten mit jeweils eigenen Vorteilen:

• Lokal, auf dem Rechner des Entwicklers oder auf einem internen Server. Das ist die sicherste Variante, weil sie aus dem Internet nicht erreichbar ist, aber schwerer mit denen zu teilen, die prüfen sollen.
• Auf einer Subdomain desselben Hostings. Das ist bequem, aber sie teilt sich den Server mit dem echten Shop: Ein aufwendiger Test (ein Import, eine Neuerzeugung der Bilder) nimmt dem Live-Shop Ressourcen weg.
• Auf einem eigenen Server, mit derselben PHP-Version und derselben Konfiguration wie der Live-Shop. Das ist ideal, um Updates zu proben, weil Unterschiede in der Umgebung Sie nicht in die Irre führen.

Wofür Sie sich auch entscheiden: Die Kopie muss dieselbe PHP-Version haben wie der echte Shop, es sei denn, Sie testen gerade einen PHP-Wechsel.

Schritt 1: zuerst die E-Mails

Noch bevor Sie die Kopie im Browser öffnen, unterbinden Sie den E-Mail-Versand. Eine frisch importierte Kopie hat die SMTP-Konfiguration des Live-Shops und die Datenbank mit echten Kunden. Eine Statusänderung einer Bestellung, ein abgebrochener Warenkorb, an den ein Modul erinnern will, oder eine geplante Aufgabe, die Newsletter verschickt, reichen aus, um aus Ihrer Testumgebung einem echten Menschen zu schreiben.

Möglichkeiten, von der empfehlenswertesten zur am wenigsten empfehlenswerten:

• E-Mails abfangen mit einem Test-SMTP-Server, der alle Nachrichten entgegennimmt und in einem Web-Postfach anzeigt, ohne sie zuzustellen. So können Sie das Aussehen der E-Mails ohne Risiko prüfen.
• Den Versand deaktivieren unter Erweiterte Einstellungen → E-Mail, mit der Option, nie E-Mails zu senden. Das geht schnell, aber Sie sehen die E-Mails dann nicht.

Schritt 2: personenbezogene Daten anonymisieren

Eine Testkopie braucht nicht die echten Namen, E-Mail-Adressen, Telefonnummern und Anschriften Ihrer Kunden. Und sie in einer weniger geschützten Umgebung als dem Live-Shop vorzuhalten, ist ein Datenschutzrisiko. Ersetzen Sie mindestens:

• Kunden-E-Mails durch fiktive Adressen einer Domain, die nicht existiert oder die Sie selbst kontrollieren.
• Vor- und Nachnamen, Telefonnummern und Anschriften von Kunden und Lieferadressen.
• Kundennachrichten, interne Notizen und Firmendaten wie die Steuernummer.
• Newsletter-Abonnenten und jede Modultabelle, die personenbezogene Daten speichert: Formulare, Bewertungen, Wunschlisten.

Behalten Sie Bestellungen, Beträge und Produkte: Die brauchen Sie zum Testen. Und ändern Sie die Passwörter der Mitarbeiter in andere als die des Live-Shops.

Schritt 3: Zahlungen im Testmodus

Jeder Zahlungsanbieter hat einen Testmodus mit eigenen Schlüsseln. Stellen Sie auf der Kopie alle auf diesen Modus um, bevor Sie die erste Bestellung aufgeben. Prüfen Sie insbesondere:

• Live-Schlüssel des Zahlungsanbieters: Ersetzen Sie sie durch die Testschlüssel und setzen Sie nicht nur ein Häkchen, wenn das Modul die gespeicherten Schlüssel verwendet.
• Webhooks und Benachrichtigungen: Der echte Anbieter sendet seine Meldungen weiterhin an die URL des Live-Shops, und das ist richtig so. Was nicht passieren darf, ist, dass die Kopie im echten Konto einen neuen Webhook registriert, der auf sie selbst zeigt.
• Überweisung und Nachnahme: Sie buchen nichts ab, erzeugen aber E-Mails mit Anweisungen an den Kunden. Die sind bereits abgedeckt, wenn die E-Mails abgefangen werden.

Schritt 4: dass niemand sie findet

Eine aus dem Internet erreichbare Kopie wird indexiert, wenn Sie es nicht verhindern, und konkurriert dann bei Google mit Ihrem eigenen Shop um denselben Inhalt.

• Passwortschutz auf dem Webserver (Basic-Authentifizierung). Das ist am wirksamsten: Weder Suchmaschinen noch Neugierige kommen über die erste Seite hinaus.
• Header noindex in allen Antworten, als zweite Schicht.
• Wartungsmodus von PrestaShop mit freigegebener eigener IP, wenn Sie kein Passwort setzen können.

Verlassen Sie sich nicht allein auf die robots.txt: Sie bittet Suchmaschinen, nicht zu crawlen, verhindert aber nicht, dass eine irgendwo verlinkte URL in den Ergebnissen erscheint.

Schritt 5: die Verbindungen nach außen

Hier gibt es die meisten Überraschungen, denn jeder Shop hat seine eigenen:

• Geplante Aufgaben. Wenn Sie auch die Crontab kopieren, führt die Kopie dieselben Aufgaben aus: Exporte ins ERP, Synchronisierungen mit Marktplätzen, Newsletter-Versand. Deaktivieren Sie sie und aktivieren Sie sie nur einzeln, wenn Sie sie testen wollen.
• ERP und Lager. Ein Konnektor, der im echten ERP Bestellungen anlegt oder den Bestand aktualisiert, ist von einer Kopie aus gefährlich: Er kann Bestellungen doppelt anlegen oder den Bestand mit Testdaten überschreiben.
• Marktplätze und Feeds. Ein Modul, das Produkte veröffentlicht oder den Bestand mit einem Marktplatz synchronisiert, nutzt die echten Zugangsdaten.
• Tracking-Pixel und Analytics. Die Besuche auf der Kopie verfälschen die Statistiken des echten Shops und können falsche Conversions an Werbeplattformen senden.
• Versanddienstleister. Manche Module erzeugen Etiketten oder beauftragen Abholungen über die API des Versanddienstleisters.

Schritt 6: die Domain

PrestaShop speichert die Domain des Shops in der Datenbank (in der Tabelle der Shop-URLs und in der Konfiguration). Wenn Sie sie nicht ändern, leitet die Kopie beim ersten Aufruf auf den echten Shop weiter. Leeren Sie nach der Änderung den Cache und erzeugen Sie die Datei für suchmaschinenfreundliche URLs neu. Suchen Sie die alte Domain auch in der Konfiguration der Module und in CMS-Inhalten: Ein absoluter Link auf den Live-Shop innerhalb der Kopie kann Sie glauben lassen, Sie testen das eine, während Sie etwas anderes vor sich haben.

Prüfung vor der Arbeit

1. Geben Sie eine Testbestellung auf und prüfen Sie, dass die E-Mail abgefangen wird und nicht hinausgeht.
2. Suchen Sie in der Datenbank nach einer echten Kunden-E-Mail: Es sollte keine mehr übrig sein.
3. Öffnen Sie die Kopie ohne Sitzung in einem anderen Browser: Sie muss ein Passwort verlangen oder den Wartungsmodus zeigen.
4. Prüfen Sie, welche geplanten Aufgaben aktiv sind und welche Module Zugangsdaten zu externen Diensten haben.

Eine solche Kopie ist ein Werkzeug, das Sie bedenkenlos für jedes Update, jedes neue Modul und jede Änderung am Theme einsetzen können, und die Grundlage dafür, den Shop aktuell zu halten, ohne dass Ihre Kunden die Tester sind.

So lösen Sie es in PrestaShop

Bei Rekire arbeiten wir immer auf Kopien dieser Art: E-Mails abgefangen, Daten anonymisiert, Zahlungsanbieter im Testmodus und externe Verbindungen gekappt. Mit einem Support-Stundenpaket richten wir die Kopie Ihres Shops ein und machen sie bereit, um Updates und Änderungen zu proben, oder wir nehmen diese Änderungen selbst auf der Kopie vor, bevor sie live gehen. Wenn Sie außerdem ein auf PrestaShop ausgelegtes Hosting suchen, ist der Hosting plan profesional von Rekire unser Angebot für Shops, die sich nicht mehr um den Server kümmern wollen.