Installation & Einrichtung

Linux-Dateiberechtigungen verstehen

Jede Datei und jedes Verzeichnis auf einem Linux-Server verfuegt ueber drei Berechtigungssaetze: einen fuer den Eigentuemer, einen fuer die Gruppe und einen fuer Andere (alle uebrigen). Jeder Satz steuert drei Aktionen: Lesen (r), Schreiben (w) und Ausfuehren (x). Diese Berechtigungen werden numerisch in Oktalschreibweise dargestellt, wobei Lesen gleich 4, Schreiben gleich 2 und Ausfuehren gleich 1 ist. Die Werte werden fuer jeden Satz addiert, was eine dreistellige Zahl wie 755 oder 644 ergibt.

Beispielsweise bedeutet eine Berechtigung von 755, dass der Eigentuemer lesen, schreiben und ausfuehren kann (7 = 4+2+1), waehrend die Gruppe und Andere nur lesen und ausfuehren koennen (5 = 4+0+1). Eine Berechtigung von 644 bedeutet, dass der Eigentuemer lesen und schreiben kann (6 = 4+2+0), waehrend die Gruppe und Andere nur lesen koennen (4 = 4+0+0). Das Verstaendnis dieses Systems ist grundlegend fuer den Betrieb eines sicheren und funktionsfaehigen PrestaShop-Shops.

Ueber die numerischen Berechtigungen hinaus hat jede Datei einen Eigentuemer und eine Gruppe. Auf einem Webserver laeuft der Webserver-Prozess (Apache oder Nginx) als ein bestimmter Benutzer, typischerweise www-data auf Debian/Ubuntu oder apache/nobody auf CentOS/RHEL. Der Webserver muss Ihre PrestaShop-Dateien lesen koennen, um sie auszuliefern, und er benoetigt Schreibzugriff auf bestimmte Verzeichnisse fuer Uploads, Caching und Konfiguration.

Korrekte Berechtigungen fuer PrestaShop-Verzeichnisse und -Dateien

Die allgemeine Regel fuer PrestaShop ist unkompliziert: Verzeichnisse sollten 755 und Dateien sollten 644 haben. Dies gibt dem Eigentuemer volle Kontrolle, waehrend die Gruppe und Andere lesen (und im Falle von Verzeichnissen ausfuehren/durchqueren) koennen, aber nichts aendern duerfen. Der Webserver-Benutzer sollte der Eigentuemer aller PrestaShop-Dateien sein oder zumindest der Gruppe angehoeren, der sie gehoeren.

Um diese Berechtigungen fuer Ihre gesamte PrestaShop-Installation festzulegen, verbinden Sie sich per SSH mit Ihrem Server und fuehren Sie aus:

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;

Ersetzen Sie /var/www/html/prestashop durch den tatsaechlichen Pfad zu Ihrer PrestaShop-Installation. Der erste Befehl findet alle Verzeichnisse und setzt sie auf 755. Der zweite findet alle Dateien und setzt sie auf 644.

Bestimmte Verzeichnisse benoetigen jedoch Schreibzugriff durch den Webserver. Diese Verzeichnisse erfordern besondere Aufmerksamkeit, da PrestaShop waehrend des normalen Betriebs in sie schreibt:

/var/cache/ — Smarty-kompilierte Templates und Symfony-Cache
/var/logs/ — Anwendungs-Logdateien
/upload/ — Kunden-Datei-Uploads
/download/ — Virtuelle Produktdateien
/img/ — Produktbilder, Kategoriebilder, CMS-Bilder
/modules/ — Modulinstallation und -updates
/themes/ — Theme-Cache-Dateien
/translations/ — Uebersetzungs-Exportdateien
/config/ — Konfigurationsdateien (parameters.php)
/app/config/ — Symfony-Konfiguration
/app/Resources/translations/ — Symfony-Uebersetzungen

Wenn der Webserver-Benutzer der Eigentuemer dieser Dateien ist (was die empfohlene Einrichtung ist), reichen 755/644-Berechtigungen aus. Wenn der Webserver als ein anderer Benutzer laeuft, muessen Sie moeglicherweise die Gruppenberechtigungen oder den Eigentumer anpassen.

Korrekten Eigentumer mit chown festlegen

Die Eigentuemerzuordnung ist genauso wichtig wie die Berechtigungen. Der Befehl chown aendert den Eigentuemer und die Gruppe von Dateien. Fuer einen typischen Debian/Ubuntu-Server mit Apache oder Nginx ist der Webserver-Benutzer www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

Das Flag -R wendet die Aenderung rekursiv auf alle Dateien und Unterverzeichnisse an. Auf CentOS- oder RHEL-Systemen ersetzen Sie www-data durch apache oder nginx, je nach Ihrem Webserver.

Ein gaengiger alternativer Ansatz ist, den Eigentuemer auf Ihren SSH/FTP-Benutzer und die Gruppe auf den Webserver-Benutzer zu setzen. So koennen Sie Dateien ueber FTP oder SSH bearbeiten, waehrend der Webserver sie weiterhin lesen kann:

sudo chown -R ihrbenutzername:www-data /var/www/html/prestashop

In diesem Fall sollten Verzeichnisse, die Schreibzugriff durch den Webserver benoetigen, auf 775 (Gruppen-Schreibrecht) und beschreibbare Dateien auf 664 gesetzt werden:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/var -type f -exec chmod 664 {} \;
find /var/www/html/prestashop/img -type d -exec chmod 775 {} \;
find /var/www/html/prestashop/img -type f -exec chmod 664 {} \;

Shared Hosting vs. VPS vs. Dedizierter Server

Die Hosting-Umgebung beeinflusst massgeblich, wie Dateiberechtigungen in der Praxis funktionieren. Das Verstaendnis der Unterschiede ist entscheidend fuer die korrekte Einrichtung der Berechtigungen.

Shared Hosting

Beim Shared Hosting greifen Sie typischerweise ueber FTP oder einen Dateimanager in cPanel/Plesk auf Dateien zu. Das PHP-Ausfuehrungsmodell variiert je nach Hoster, aber die meisten modernen Shared-Hoster verwenden PHP-FPM oder suPHP, was bedeutet, dass PHP als Ihr Benutzerkonto und nicht als globaler Webserver-Benutzer laeuft. Dies vereinfacht die Berechtigungen erheblich: Da PHP als Ihr Benutzer laeuft, kann es bereits mit den Standard-Berechtigungen 755/644 Ihre Dateien lesen und schreiben. Sie muessen auf Shared Hosting selten die Eigentuemerzuordnung aendern, da alles bereits Ihrem Konto gehoert.

Wenn Sie auf Shared Hosting auf Berechtigungsfehler stossen, pruefen Sie bei Ihrem Hoster, ob suPHP oder PHP-FPM verwendet wird. Wenn das aeltere mod_php-Modell verwendet wird, muessen Sie moeglicherweise einige Verzeichnisse voruebergehend auf 777 setzen (was aus Sicherheitsgruenden jedoch nicht empfohlen wird). Die meisten serioeosen Hoster haben mod_php genau wegen dieser Berechtigungskomplikationen abgeschafft.

VPS (Virtual Private Server)

Auf einem VPS haben Sie die volle Kontrolle. Dies ist das gaengigste Setup fuer ernsthafte PrestaShop-Shops. Sie sollten sicherstellen, dass der Webserver-Benutzer die PrestaShop-Dateien besitzt oder zumindest einer Gruppe angehoert, die Lesezugriff hat. Die empfohlene Einrichtung ist:

Eigentuemer auf www-data:www-data setzen (oder Ihren Webserver-Benutzer)
755 fuer Verzeichnisse und 644 fuer Dateien verwenden
SSH mit sudo fuer Aenderungen verwenden oder Ihren SSH-Benutzer zur Gruppe www-data hinzufuegen

Um Ihren SSH-Benutzer zur Webserver-Gruppe hinzuzufuegen:

sudo usermod -a -G www-data ihrbenutzername

Dann setzen Sie das Gruppen-Schreibbit fuer Verzeichnisse, die Sie bearbeiten muessen:

chmod g+w /var/www/html/prestashop/themes/ihr-theme/

Dedizierter Server

Dedizierte Server folgen denselben Prinzipien wie VPS-Setups. Der Hauptunterschied liegt in der Leistung: Sie haben mehr Ressourcen, sodass Sie PHP-FPM mit dedizierten Pools pro Website betreiben koennen. Jeder Pool kann als anderer Benutzer laufen, was eine bessere Isolation bietet, wenn Sie mehrere PrestaShop-Shops auf demselben Server hosten.

PHP-Ausfuehrungsmodelle: suPHP vs. mod_php vs. PHP-FPM

Die Art und Weise, wie PHP auf Ihrem Server ausgefuehrt wird, bestimmt direkt, welcher Benutzer Dateien schreibt und somit welche Berechtigungen benoetigt werden.

mod_php (Apache-Modul)

Dies ist das aelteste und einfachste Modell. PHP laeuft als Teil des Apache-Prozesses, was bedeutet, dass saemtlicher PHP-Code als Apache-Benutzer ausgefuehrt wird (typischerweise www-data oder apache). Das Problem ist, dass von PHP erstellte Dateien (Cache, Uploads usw.) dem Webserver-Benutzer gehoeren und nicht Ihrem Konto. Dies kann die FTP-Verwaltung erschweren und erzeugt auf Shared Hosts Sicherheitsbedenken, da alle Websites als derselbe Benutzer laufen.

Mit mod_php sollten PrestaShop-Dateien dem Apache-Benutzer gehoeren, und Berechtigungen von 755/644 funktionieren korrekt. Allerdings ist dieses Modell auf modernen Servern weitgehend veraltet.

suPHP

suPHP fuehrt PHP als Dateieigentuemer aus, anstatt als Webserver-Benutzer. Das bedeutet: Wenn Ihre Dateien ihrbenutzername gehoeren, laeuft PHP ebenfalls als ihrbenutzername. Dies ist auf Shared Hosting sicherer, da jedes Konto isoliert ist. Standard-Berechtigungen 755/644 funktionieren mit suPHP perfekt, da der PHP-Prozess und der Dateieigentuemer derselbe Benutzer sind.

Ein wichtiger Vorbehalt: suPHP lehnt Dateien mit Berechtigungen von 777 oder Dateien, die anderen Benutzern gehoeren, tatsaechlich ab. Wenn Sie auf einem suPHP-Server 777 setzen, verweigert PHP die Ausfuehrung dieser Dateien und zeigt stattdessen einen 500 Internal Server Error an.

PHP-FPM (FastCGI Process Manager)

PHP-FPM ist der moderne Standard. Es fuehrt PHP als separaten Prozess vom Webserver aus, mit konfigurierbarem Benutzer/Gruppe pro Pool. Auf einem VPS laeuft PHP-FPM typischerweise als www-data. Auf Shared Hosting mit CloudLinux oder aehnlichem erhaelt jedes Konto seinen eigenen PHP-FPM-Pool, der als Benutzer dieses Kontos laeuft.

PHP-FPM in Kombination mit Nginx ist das empfohlene Setup fuer die PrestaShop-Performance. Das Standard-Berechtigungsschema 755/644 funktioniert gut. Stellen Sie sicher, dass der Benutzer des PHP-FPM-Pools mit dem Dateieigentuemer uebereinstimmt oder ueber entsprechenden Gruppenzugriff verfuegt.

Warum 777-Berechtigungen gefaehrlich sind

Berechtigungen auf 777 zu setzen bedeutet, dass jeder auf dem System die Datei lesen, schreiben und ausfuehren kann. Auf Shared Hosting bedeutet dies, dass andere Konten auf demselben Server potenziell Ihre Datenbank-Zugangsdaten aus parameters.php auslesen oder schaedlichen Code in Ihre PHP-Dateien einschleusen koennten.

Selbst auf einem VPS, wo Sie der einzige Benutzer sind, ist 777 unnoetig und deutet auf eine Fehlkonfiguration hin. Wenn der Webserver bei 755-Berechtigungen nicht in ein Verzeichnis schreiben kann, ist die Loesung, die Eigentuemerzuordnung zu korrigieren, nicht die Berechtigungen fuer alle zu oeffnen. Hier ist, was Sie anstelle von 777 tun sollten:

Pruefen, als welcher Benutzer der Webserver laeuft: ps aux | grep -E "apache|nginx|httpd"
Dateieigentum pruefen: ls -la /var/www/html/prestashop/
Eigentum korrigieren: sudo chown -R www-data:www-data /pfad/zum/verzeichnis
Korrekte Berechtigungen setzen: chmod 755 /pfad/zum/verzeichnis

Wenn Sie ein Tutorial oder einen Forenbeitrag finden, der 777 fuer PrestaShop empfiehlt, ist dies veralteter und gefaehrlicher Rat. Die einzige legitime Verwendung von 777 ist fuer /tmp-Verzeichnisse, die das Sticky-Bit gesetzt haben (angezeigt als 1777), was eine Konfiguration auf Systemebene ist und nichts, was Sie auf PrestaShop-Dateien anwenden.

Docker-Besonderheiten fuer PrestaShop

PrestaShop in Docker auszufuehren fuehrt zu zusaetzlicher Komplexitaet bei Dateiberechtigungen. Innerhalb des Containers laeuft der Webserver als www-data mit einer bestimmten UID (oft 33 auf Debian-basierten Images). Auf dem Host-System hat Ihr Benutzer eine andere UID. Wenn Sie Docker-Bind-Mounts verwenden, um Ihre PrestaShop-Dateien in den Container einzubinden, wird die Dateizugehoerigkeit durch die numerische UID bestimmt, nicht durch den Benutzernamen.

Das bedeutet, dass Dateien, die auf dem Host als Ihr Benutzer erstellt werden (z.B. UID 1000), innerhalb des Containers als UID 1000 erscheinen, was nicht www-data (UID 33) ist. Der Webserver innerhalb des Containers kann moeglicherweise nicht in diese Dateien schreiben.

Loesungen fuer Docker-Berechtigungsprobleme umfassen:

UIDs abgleichen: Erstellen Sie einen Benutzer innerhalb des Containers mit derselben UID wie Ihr Host-Benutzer, oder aendern Sie den Webserver so, dass er als Ihre UID laeuft.
chown im Entrypoint verwenden: Fuegen Sie einen Startbefehl hinzu, der chown -R www-data:www-data /var/www/html beim Containerstart ausfuehrt. Dies ist einfach, kann aber bei grossen Installationen langsam sein.
Gruppenberechtigungen setzen: Fuegen Sie Ihren Host-Benutzer und www-data derselben Gruppe hinzu (nach GID), dann verwenden Sie 775/664-Berechtigungen.
Named Volumes: Verwenden Sie Docker-Named-Volumes anstelle von Bind Mounts. Docker verwaltet die Berechtigungen automatisch, aber Sie verlieren den direkten Dateisystemzugriff vom Host.

Fuer Entwicklungsumgebungen mit Bind Mounts ist der praktischste Ansatz, nach dem Synchronisieren oder Deployen von Dateien einen chown-Befehl auszufuehren:

docker exec ihr-container chown -R www-data:www-data /var/www/html/modules/ihr-modul/

Beachten Sie, dass Operationen innerhalb des Containers (wie die Installation eines Moduls) Dateien als www-data erstellen koennen, waehrend Operationen auf dem Host Dateien als Ihr Host-Benutzer erstellen. Dieser staendige UID-Mismatch ist die haeufigste Ursache fuer Berechtigungsprobleme in dockerisierten PrestaShop-Umgebungen.

Fehlerbehebung haeufiger Berechtigungsfehler

"Failed to open stream: Permission denied"

Dieser Fehler bedeutet, dass PHP eine Datei nicht lesen oder schreiben kann. Ueberpruefen Sie die Eigentuemerzuordnung und Berechtigungen der in der Fehlermeldung genannten Datei. Die haeufigste Ursache ist, dass der Webserver-Benutzer die Datei oder das Verzeichnis nicht besitzt. Beheben Sie es mit:

sudo chown www-data:www-data /pfad/zur/datei
sudo chmod 644 /pfad/zur/datei

"Unable to write to cache directory"

PrestaShops Smarty-Template-Engine und das Symfony-Framework schreiben beide Cache-Dateien. Wenn das Verzeichnis var/cache/ nicht beschreibbar ist, sehen Sie diesen Fehler. Das Cache-Verzeichnis muss dem Webserver-Benutzer gehoeren:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/
sudo chmod -R 755 /var/www/html/prestashop/var/cache/

Nach dem Korrigieren der Berechtigungen leeren Sie den vorhandenen Cache, indem Sie den Inhalt der Cache-Verzeichnisse loeschen:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*
sudo rm -rf /var/www/html/prestashop/var/cache/dev/*

"Cannot upload image" oder "Cannot install module"

Bild-Uploads gehen in das Verzeichnis img/, und Modulinstallationen schreiben in das Verzeichnis modules/. Beide muessen vom Webserver-Benutzer beschreibbar sein. Ueberpruefen Sie zusaetzlich, ob die PHP-Einstellungen upload_max_filesize und post_max_size gross genug fuer Ihre Dateien sind, da diese aehnlich klingende Fehler verursachen koennen.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/
sudo chown -R www-data:www-data /var/www/html/prestashop/modules/

"index.php is not writable" waehrend Updates

PrestaShops Auto-Updater benoetigt Schreibzugriff auf nahezu jede Datei in der Installation. Bevor Sie ein Update ausfuehren, setzen Sie die Eigentuemerzuordnung der gesamten Installation auf den Webserver-Benutzer. Nach Abschluss des Updates koennen Sie bei Bedarf restriktivere Eigentuemerzuordnungen wiederherstellen.

Weisse Seite nach Aenderung der Berechtigungen

Wenn Sie nach dem Aendern der Berechtigungen eine leere weisse Seite sehen, haben Sie moeglicherweise versehentlich die Ausfuehrungsberechtigung von Verzeichnissen entfernt. Verzeichnisse benoetigen das Execute-Bit, um durchquert werden zu koennen. Ein Verzeichnis mit Berechtigung 644 (kein Execute) ist effektiv unzugaenglich. Verwenden Sie immer 755 fuer Verzeichnisse, niemals 644.

Sie koennen auch das PHP-Fehlerprotokoll fuer weitere Details pruefen:

sudo tail -50 /var/log/apache2/error.log
# oder fuer Nginx:
sudo tail -50 /var/log/nginx/error.log

Berechtigungen werden nach FTP-Upload zurueckgesetzt

Einige FTP-Clients setzen beim Hochladen von Dateien ihre eigenen Standardberechtigungen. Ueberpruefen Sie die Einstellungen Ihres FTP-Clients auf eine Option "Standardberechtigungen" oder "umask". Stellen Sie sie so ein, dass Dateien mit 644 und Verzeichnisse mit 755 erstellt werden. Alternativ fuehren Sie die Befehle zur Berechtigungskorrektur nach jedem FTP-Upload aus.

Sicherheits-Best-Practices ueber Berechtigungen hinaus

Korrekte Dateiberechtigungen sind nur eine Sicherheitsebene. Beruecksichtigen Sie diese zusaetzlichen Massnahmen:

Zugriff auf Konfigurationsdateien einschraenken: Die Datei app/config/parameters.php enthaelt Ihre Datenbank-Zugangsdaten. Stellen Sie sicher, dass sie nur vom Webserver-Benutzer lesbar ist (Berechtigung 640), nicht von der gesamten Welt.
Verzeichnisauflistung deaktivieren: Fuegen Sie Options -Indexes zu Ihrer Apache-Konfiguration oder autoindex off; zu Nginx hinzu, um zu verhindern, dass Besucher Verzeichnisinhalte durchsuchen koennen.
.htaccess-Dateien schuetzen: PrestaShop platziert .htaccess-Dateien in sensiblen Verzeichnissen. Loeschen Sie diese nicht.
Installationsverzeichnis entfernen: Loeschen Sie nach der Installation das Verzeichnis /install/ vollstaendig. PrestaShop warnt Sie davor, aber es ist eine Betonung wert.
Korrekten umask setzen: Konfigurieren Sie Ihren Webserver und PHP-FPM mit einem umask von 0022, damit neue Dateien standardmaessig mit 644/755-Berechtigungen erstellt werden.

Durch das Verstaendnis von Linux-Berechtigungen, deren Anpassung an Ihre Hosting-Umgebung und die Befolgung der Richtlinien in diesem Artikel werden Sie die haeufigsten PrestaShop-Berechtigungsprobleme vermeiden und gleichzeitig eine sichere Serverkonfiguration aufrechterhalten.

Vollständige Antwort lesen

Wenn Modul-Updates schiefgehen

Sie haben ein PrestaShop-Modul aktualisiert und jetzt funktioniert etwas nicht mehr. Vielleicht hat der Checkout aufgehört zu funktionieren, die Startseite wirft Fehler, oder das Admin-Panel reagiert nicht mehr. Modul-Updates können aus vielen Gründen fehlschlagen - inkompatible PHP-Versionen, Konflikte mit anderen Modulen, Datenbankmigrationsfehler oder einfach Bugs in der neuen Version. Unabhängig von der Ursache müssen Sie schnell zurückrollen, um die Funktionalität Ihres Shops wiederherzustellen.

Leider enthält PrestaShop keine eingebaute "Rückgängig"-Schaltfläche für Modul-Updates. Es gibt keinen nativen Versionsverlauf oder automatischen Rollback-Mechanismus für einzelne Module. Das bedeutet, Sie müssen das Downgrade manuell durchführen. Dieser Leitfaden behandelt jede verfügbare Methode, von der einfachsten bis zur komplexesten.

Bevor Sie beginnen - Sicherheit zuerst

Schalten Sie Ihren Shop in den Wartungsmodus - Gehen Sie zu Shopparameter > Allgemein > Wartung und aktivieren Sie ihn.
Erstellen Sie ein Datenbank-Backup - Die neue Modulversion hat möglicherweise Datenbankänderungen vorgenommen.
Dokumentieren Sie den aktuellen Fehler - Notieren Sie exakte Fehlermeldungen und betroffene Seiten.

Methode 1 - Vorherige Version über das Back Office neu installieren

Dies ist die einfachste Methode und funktioniert, wenn Sie noch Zugang zum PrestaShop-Admin-Panel haben und die ZIP-Datei der vorherigen Version besitzen.

Schritt-für-Schritt-Anleitung

Navigieren Sie zu Module > Modulmanager
Finden Sie das problematische Modul und klicken Sie auf Deinstallieren (NICHT "Löschen" - Deinstallieren bewahrt die Moduldaten in der Datenbank)
Bestätigen Sie die Deinstallation
Klicken Sie oben auf der Seite auf Modul hochladen
Laden Sie die ZIP-Datei der vorherigen funktionierenden Version hoch
Installieren und konfigurieren Sie das Modul

Wo Sie die vorherige Version bekommen

Ihre E-Mail - Die meisten Modulverkäufer senden Download-Links mit jedem Kauf
Marktplatz-Konto - Bei PrestaShop Addons und Drittanbieter-Marktplätzen wie mypresta.rocks können Sie vorherige Versionen aus Ihrer Bestellhistorie herunterladen
Ihre Backups - Aus regelmäßigen Backups können Sie den Modulordner extrahieren
Entwickler kontaktieren - Modulentwickler können in der Regel ältere Versionen bereitstellen

Methode 2 - FTP/SFTP Dateiersetzung

Wenn das Admin-Panel nicht erreichbar ist (weißer Bildschirm, 500-Fehler), müssen Sie direkt mit Dateien über FTP oder SFTP arbeiten.

Schritt-für-Schritt-Anleitung

Verbinden Sie sich mit Ihrem Server über FTP/SFTP mit einem Client wie FileZilla
Navigieren Sie zu /modules/ in Ihrem PrestaShop-Installationsverzeichnis
Finden Sie den Modulordner (z.B. /modules/mymodule/)
Benennen Sie den aktuellen Ordner um - z.B. mymodule zu mymodule_kaputt
Laden Sie die Dateien der vorherigen Version in einen neuen mymodule-Ordner hoch
Setzen Sie korrekte Dateiberechtigungen - Verzeichnisse auf 755, Dateien auf 644
Leeren Sie den PrestaShop-Cache durch Löschen der Inhalte von /var/cache/prod/ und /var/cache/dev/

Methode 3 - Über die Kommandozeile

Wenn Sie SSH-Zugang zu Ihrem Server haben, können Sie das Rollback effizienter über die Kommandozeile durchführen.

# Per SSH verbinden
ssh user@ihrserver.com

# Zum PrestaShop-Stammverzeichnis navigieren
cd /var/www/html/prestashop

# Defektes Modul sichern
mv modules/mymodule modules/mymodule_kaputt_$(date +%Y%m%d)

# Vorherige Version entpacken
unzip /pfad/zu/mymodule_v1.2.3.zip -d modules/

# Korrekte Berechtigungen setzen
find modules/mymodule -type d -exec chmod 755 {} \;
find modules/mymodule -type f -exec chmod 644 {} \;
chown -R www-data:www-data modules/mymodule

# PrestaShop-Cache leeren
rm -rf var/cache/prod/* var/cache/dev/*

Methode 4 - Vollständiges Datenbank-Rollback

Wenn das Modul-Update Datenbankmigrationen enthielt, die rückgängig gemacht werden müssen, müssen Sie ein Datenbank-Backup von vor dem Update wiederherstellen.

Wann Sie ein Datenbank-Rollback brauchen

Das Modul hat neue Datenbanktabellen erstellt
Das Modul hat bestehende Tabellenstrukturen geändert
Das Modul hat Konfigurationswerte eingefügt oder geändert
Der alte Modulcode wirft Fehler über fehlende oder unerwartete Datenbankspalten

Warnung - Eine vollständige Datenbankwiederherstellung setzt ALLE Änderungen seit dem Backup zurück, einschließlich neuer Bestellungen, Kundenregistrierungen und Produktänderungen. Wenn möglich, stellen Sie nur die Tabellen wieder her, die das Modul speziell geändert hat.

Methode 5 - Manuelle Datenbankbereinigung

Wenn Sie kein Datenbank-Backup von vor dem Update haben, können Sie die Datenbankänderungen des Moduls manuell rückgängig machen.

Prüfen, was sich geändert hat

Öffnen Sie die Haupt-PHP-Datei des Moduls und suchen Sie nach Upgrade-Methoden -

// Suchen Sie nach Dateien wie:
// modules/mymodule/upgrade/upgrade-2.0.0.php

public function upgrade($version)
{
    if (version_compare($version, '2.0.0', '<')) {
        Db::getInstance()->execute('ALTER TABLE `' . _DB_PREFIX_ . 'mymodule` 
            ADD COLUMN `new_field` VARCHAR(255)');
    }
}

Nach dem Downgrade - Wichtige Aufräumarbeiten

Alle Caches leeren

Smarty-Cache - Inhalte von /var/cache/prod/ und /var/cache/dev/ löschen
OPcache - PHP-FPM oder Apache neu starten
CDN-Cache - Bei Cloudflare oder anderem CDN den Cache leeren
Browser-Cache - Im Inkognito-Fenster testen

Modulversion verifizieren

Überprüfen Sie nach dem Downgrade, ob PrestaShop die korrekte Version erkennt.

Gründlich testen

Die spezifische Funktionalität des Moduls
Den Checkout-Prozess von Anfang bis Ende
Die Admin-Seiten, auf denen das Modul Inhalte hinzufügt
Mobile und Desktop-Ansichten
Performance

Zukünftige Update-Probleme verhindern

Immer vor dem Update sichern
Updates in einer Staging-Umgebung testen
Das Changelog lesen
Frühere Versionen aufbewahren
Kompatibilität prüfen

Wann den Modulentwickler kontaktieren

Wenn keine der obigen Methoden das Problem löst, kontaktieren Sie den Modulentwickler mit Ihrer PrestaShop-Version, PHP-Version, den betroffenen Modulversionen, exakten Fehlermeldungen und einer Liste anderer installierter Module.

Vollständige Antwort lesen

Wie man ein PrestaShop-Modul auf einer Staging-Umgebung testet

Die Installation eines ungetesteten Moduls in einem aktiven PrestaShop-Shop ist eine der häufigsten Ursachen für Ausfallzeiten, fehlerhafte Checkout-Abläufe und Umsatzeinbußen. Eine Staging-Umgebung bietet Ihnen eine sichere Sandbox, um jedes Modul zu validieren, bevor es Ihren Produktionsshop berührt. Dieser Leitfaden führt Sie durch den gesamten Prozess - von der Erstellung einer Staging-Kopie Ihres Shops bis hin zur gründlichen Modultestung und sicheren Bereitstellung in der Produktion.

Warum Sie eine Staging-Umgebung brauchen

Eine Staging-Umgebung ist eine exakte Kopie Ihres Live-Shops, die nicht öffentlich zugänglich ist. Sie spiegelt Ihre Produktionsdatenbank, Dateien, Theme, Konfiguration und installierten Module wider. Tests auf Staging ermöglichen es Ihnen, Probleme zu erkennen, die sonst Ihre Kunden treffen würden.

Folgendes kann schiefgehen, wenn Sie das Staging überspringen:

Modulkonflikte - Das neue Modul kann mit einem bestehenden Modul in Konflikt geraten und weiße Bildschirme, JavaScript-Fehler oder fehlerhafte Funktionalität auf bestimmten Seiten verursachen.
Theme-Inkompatibilität - Die Templates des Moduls werden möglicherweise nicht korrekt mit Ihrem Theme dargestellt, insbesondere wenn Sie ein benutzerdefiniertes oder stark modifiziertes Theme verwenden.
Leistungseinbußen - Einige Module fügen schwere Datenbankabfragen, zusätzliche CSS/JS-Dateien oder externe API-Aufrufe hinzu, die die Seitenladezeiten verlangsamen.
Datenbankbeschädigung - Schlecht geschriebene Module können Kerntabellen modifizieren, Spalten ohne ordnungsgemäße Migrationshandhabung hinzufügen oder Trigger erstellen, die bestehende Daten beeinträchtigen.
Zahlungsunterbrechung - Wenn ein Modul den Checkout-Prozess stört oder Ihr Zahlungsgateway beeinträchtigt, verlieren Sie Umsätze vom Moment der Installation bis Sie das Problem entdecken und beheben.

Option 1 - Manuelle Staging-Einrichtung (Subdomain)

Dies ist der häufigste Ansatz und funktioniert mit jedem Hosting-Anbieter. Sie erstellen eine Subdomain wie staging.ihrshop.com und kopieren Ihre Produktionsdateien und -datenbank dorthin.

Schritt 1 - Subdomain erstellen

Erstellen Sie in Ihrem Hosting-Control-Panel (cPanel, Plesk oder DirectAdmin) eine neue Subdomain. Verweisen Sie sie auf ein neues Verzeichnis, zum Beispiel /home/ihruser/staging.ihrshop.com.

Schritt 2 - Produktionsdateien kopieren

Verbinden Sie sich per SSH oder FTP mit Ihrem Server und kopieren Sie alle Produktionsdateien in das Staging-Verzeichnis:

# Via SSH (schnellste Methode)
cp -r /home/ihruser/public_html/* /home/ihruser/staging.ihrshop.com/

# Oder erstellen Sie zuerst ein komprimiertes Archiv
cd /home/ihruser/public_html
tar czf /tmp/prestashop-backup.tar.gz --exclude='var/cache' --exclude='var/logs' .
cd /home/ihruser/staging.ihrshop.com
tar xzf /tmp/prestashop-backup.tar.gz

Schritt 3 - Datenbank exportieren und importieren

Erstellen Sie eine neue Datenbank für Staging und kopieren Sie die Produktionsdaten:

# Produktionsdatenbank exportieren
mysqldump -u dbuser -p production_db > /tmp/production_dump.sql

# Staging-Datenbank erstellen
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p -e "GRANT ALL ON staging_db.* TO 'dbuser'@'localhost';"

# In Staging importieren
mysql -u dbuser -p staging_db < /tmp/production_dump.sql

Schritt 4 - PrestaShop-Konfiguration aktualisieren

Bearbeiten Sie die Konfigurationsdateien, um auf die Staging-Datenbank und -Domain zu verweisen:

# Edit app/config/parameters.php (PrestaShop 1.7+/8.x)
# Ändern Sie diese Werte:
'database_name' => 'staging_db',

# Shop-URL in der Datenbank aktualisieren
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url 
  SET domain = 'staging.ihrshop.com', 
      domain_ssl = 'staging.ihrshop.com' 
  WHERE id_shop_url = 1;"

# Konfigurationswerte aktualisieren
mysql -u dbuser -p staging_db -e "
  UPDATE ps_configuration 
  SET value = 'staging.ihrshop.com' 
  WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');"

Schritt 5 - Caches leeren

rm -rf var/cache/prod/* var/cache/dev/*
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

Schritt 6 - Zugriff einschränken

Verhindern Sie, dass Suchmaschinen und unbefugte Benutzer auf Ihre Staging-Site zugreifen. Fügen Sie zur .htaccess im Stammverzeichnis Ihres Staging-Verzeichnisses hinzu:

# Staging passwortschützen
AuthType Basic
AuthName "Staging-Zugriff"
AuthUserFile /home/ihruser/.htpasswd
Require valid-user

# Suchmaschinen blockieren
Header set X-Robots-Tag "noindex, nofollow"

Erstellen Sie die Passwortdatei:

htpasswd -c /home/ihruser/.htpasswd staginguser

Option 2 - Docker-basiertes Staging (Empfohlen für Entwickler)

Docker bietet die zuverlässigste Staging-Umgebung, da Sie Ihre Produktions-PHP-Version, MySQL-Version und Serverkonfiguration exakt nachbilden können.

Grundlegendes Docker-Compose-Setup

# docker-compose.yml
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.1
    ports:
      - "8080:80"
    volumes:
      - ./html:/var/www/html
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=prestashop
      - DB_PASSWD=ihr_passwort
    depends_on:
      - db
      
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=root_passwort
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=ihr_passwort
    volumes:
      - db_data:/var/lib/mysql
      
volumes:
  db_data:

Produktionsdaten in Docker importieren

# Produktionsdateien in ./html kopieren
rsync -avz --exclude='var/cache' production:/var/www/html/ ./html/

# Datenbank-Dump importieren
docker exec -i ihr-db-container mysql -u root -proot_passwort prestashop < production_dump.sql

# URLs für lokalen Zugriff aktualisieren
docker exec ihr-db-container mysql -u root -proot_passwort -e "
  USE prestashop;
  UPDATE ps_shop_url SET domain='localhost:8080', domain_ssl='localhost:8080';
  UPDATE ps_configuration SET value='localhost:8080' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
  UPDATE ps_configuration SET value='0' WHERE name='PS_SSL_ENABLED';"

Option 3 - Lokales Staging mit XAMPP/MAMP

Für schnelle Modultests können Sie PrestaShop lokal auf Ihrem Entwicklungsrechner ausführen. Dies ist die schnellste Option für einen einzelnen Entwickler, bildet aber Ihre Produktionsserverkonfiguration nicht exakt nach.

Installieren Sie XAMPP (Windows/Linux) oder MAMP (macOS)
Stellen Sie die PHP-Version auf die Ihres Produktionsservers ein
Kopieren Sie Ihre PrestaShop-Dateien in das Web-Root (htdocs/ für XAMPP)
Erstellen Sie eine lokale Datenbank und importieren Sie Ihren Produktions-Dump
Aktualisieren Sie parameters.php mit lokalen Datenbankzugangsdaten
Aktualisieren Sie die Shop-URLs auf localhost/ihrshop
Leeren Sie alle Caches

Testcheckliste für neue Module

Sobald Ihre Staging-Umgebung bereit ist, folgen Sie diesem systematischen Testprozess für jedes neue Modul.

Phase 1 - Vorab-Installationsprüfungen

Moduldokumentation lesen - Verstehen Sie, was das Modul tut, welche Hooks es verwendet und welche Anforderungen es hat (PHP-Version, PrestaShop-Version, erforderliche PHP-Erweiterungen).
Dateiinhalte prüfen - Entpacken Sie das Modul vor der Installation und überprüfen Sie den Code. Suchen Sie nach verdächtigen Mustern wie eval(), base64_decode() oder externen URL-Aufrufen zu unbekannten Domains.
Datenbank-Backup erstellen - Auch auf Staging erstellen Sie ein Backup vor der Installation. So können Sie schnell wiederherstellen, falls das Modul irreversible Datenbankänderungen vornimmt.

# Schnelles Staging-Datenbank-Backup
mysqldump -u dbuser -p staging_db > /tmp/staging_vor_modul.sql

Phase 2 - Installationstest

Modul installieren über das Back Office (Module > Modulmanager > Modul hochladen). Installieren Sie NICHT per FTP und klicken dann auf "Installieren" - die Upload-Methode bietet bessere Fehlerberichterstattung.
Auf Installationsfehler prüfen - Nach der Installation prüfen Sie:
- Das Modul erscheint in der Liste der installierten Module
- Keine Fehlermeldungen in der Erfolgsbenachrichtigung
- Das PHP-Fehlerprotokoll hat keine neuen Einträge: tail -f /var/log/php-errors.log

Datenbankänderungen überprüfen - Vergleichen Sie die Datenbanktabellen vor und nach der Installation:

# Vom Modul erstellte Tabellen auflisten
mysql -u dbuser -p staging_db -e "SHOW TABLES LIKE '%modulname%';"

Phase 3 - Funktionale Tests

Testen Sie jeden Aspekt der Modulfunktionalität:

Konfigurationsseite - Können Sie alle Einstellungen fehlerfrei aufrufen und speichern?
Front-Office-Anzeige - Wird das Modul auf allen relevanten Seiten korrekt dargestellt (Startseite, Kategorie, Produkt, Warenkorb, Checkout)?
Mobile Responsivität - Testen Sie auf mobilen Viewports. Viele Module sehen auf dem Desktop gut aus, brechen aber auf Mobilgeräten.
Mehrsprachige Unterstützung - Wenn Ihr Shop mehrere Sprachen verwendet, überprüfen Sie, ob der Inhalt des Moduls in jeder Sprache korrekt angezeigt wird.
Multishop-Kompatibilität - Wenn Sie PrestaShops Multistore-Funktion nutzen, testen Sie das Verhalten des Moduls über verschiedene Shops hinweg.

Phase 4 - Konflikttest

Dies ist die kritischste Phase. Testen Sie auf Konflikte mit Ihrem bestehenden Setup:

Browser-Konsole prüfen - Öffnen Sie die Entwicklertools (F12) und suchen Sie auf jeder Seite, auf der das Modul aktiv ist, nach JavaScript-Fehlern.
Checkout-Ablauf testen - Fügen Sie ein Produkt zum Warenkorb hinzu, durchlaufen Sie jeden Checkout-Schritt und schließen Sie eine Testbestellung ab. Dies ist der sensibelste Bereich.
Zahlungsverarbeitung testen - Wenn das Modul eine Interaktion mit dem Checkout- oder Bestellprozess hat, geben Sie Testbestellungen mit jeder angebotenen Zahlungsmethode auf.
Bestehende Modulfunktionalität prüfen - Überprüfen Sie, ob Ihre kritischen Module (SEO, Analytics, Versand, Zahlung) weiterhin korrekt funktionieren.

Phase 5 - Leistungstest

Messen Sie die Auswirkungen des Moduls auf die Seitenladezeiten:

# Vor der Modulinstallation, Baseline messen
curl -o /dev/null -s -w "Zeit: %{time_total}s\n" https://staging.ihrshop.com/
curl -o /dev/null -s -w "Zeit: %{time_total}s\n" https://staging.ihrshop.com/de/2-kategorie.html
curl -o /dev/null -s -w "Zeit: %{time_total}s\n" https://staging.ihrshop.com/de/produkt-1.html

# Nach der Installation erneut messen und vergleichen
curl -o /dev/null -s -w "Zeit: %{time_total}s\n" https://staging.ihrshop.com/
curl -o /dev/null -s -w "Zeit: %{time_total}s\n" https://staging.ihrshop.com/de/2-kategorie.html
curl -o /dev/null -s -w "Zeit: %{time_total}s\n" https://staging.ihrshop.com/de/produkt-1.html

Ein gut geschriebenes Modul sollte weniger als 100ms zur Seitenladezeit hinzufügen. Wenn Sie einen Anstieg von 500ms oder mehr feststellen, untersuchen Sie die Datenbankabfragen und das Asset-Loading des Moduls.

Phase 6 - Deinstallationstest

Testen Sie, ob das Modul sauber entfernt werden kann:

Deinstallieren Sie das Modul über das Back Office
Überprüfen Sie, dass alle modulspezifischen Datenbanktabellen entfernt werden
Prüfen Sie, dass keine verwaisten Hooks, CSS- oder JavaScript-Dateien zurückbleiben
Überprüfen Sie, dass das Front Office des Shops in seinen Zustand vor dem Modul zurückkehrt

Ein getestetes Modul in die Produktion überführen

Nach erfolgreichen Staging-Tests folgen Sie diesem Bereitstellungsprozess:

Schritt 1 - Bereitstellung planen

Wählen Sie einen Zeitraum mit geringem Traffic. Prüfen Sie Ihre Google Analytics, um festzustellen, wann Ihr Shop die wenigsten Besucher hat - normalerweise am frühen Morgen oder späten Abend.

Schritt 2 - Produktions-Backup erstellen

# Vollständiges Datenbank-Backup
mysqldump -u dbuser -p production_db > /tmp/production_backup_$(date +%Y%m%d_%H%M%S).sql

# Datei-Backup (optional, aber für wichtige Module empfohlen)
tar czf /tmp/files_backup_$(date +%Y%m%d_%H%M%S).tar.gz /home/ihruser/public_html/modules/

Schritt 3 - Auf Produktion installieren

Laden Sie die exakt gleiche Modul-ZIP-Datei hoch, die Sie auf Staging getestet haben. Laden Sie keine neue Version herunter und verwenden Sie keine andere Datei - nutzen Sie die exakte Datei, die Ihre Tests bestanden hat.

Schritt 4 - Gleiche Konfiguration anwenden

Konfigurieren Sie das Modul mit exakt den gleichen Einstellungen wie auf Staging. Machen Sie Screenshots Ihrer Staging-Konfiguration, bevor Sie beginnen, damit Sie sie präzise replizieren können.

Schritt 5 - In Produktion verifizieren

Durchlaufen Sie eine verkürzte Version Ihrer Testcheckliste:

Front-Office-Seiten laden korrekt
Keine JavaScript-Fehler in der Browser-Konsole
Checkout-Prozess wird erfolgreich abgeschlossen
Modul-Konfigurationsseite ist erreichbar

Schritt 6 - 24-48 Stunden überwachen

Nach der Bereitstellung aktiv überwachen:

PHP-Fehlerprotokolle auf neue Fehler
Google Analytics auf ungewöhnliche Traffic-Muster oder Absprungrate-Spitzen
Bestellkonversionsrate im Vergleich zum vorherigen Zeitraum
Kundensupport-Anfragen zu neuen Problemen

Staging mit der Produktion synchron halten

Ihre Staging-Umgebung ist nur nützlich, wenn sie Ihren Produktionsshop genau widerspiegelt. Aktualisieren Sie Ihre Staging-Datenbank regelmäßig - mindestens vor dem Testen jedes neuen Moduls.

# Automatisierte Staging-Aktualisierung
#!/bin/bash
mysqldump -u dbuser -p production_db > /tmp/prod_dump.sql
mysql -u dbuser -p staging_db < /tmp/prod_dump.sql

mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url SET domain='staging.ihrshop.com', domain_ssl='staging.ihrshop.com';
  UPDATE ps_configuration SET value='staging.ihrshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');"

rsync -avz --exclude='var/cache' --exclude='var/logs' \
  /home/ihruser/public_html/ /home/ihruser/staging.ihrshop.com/

rm -rf /home/ihruser/staging.ihrshop.com/var/cache/prod/*
rm -rf /home/ihruser/staging.ihrshop.com/var/cache/smarty/compile/*

echo "Staging aktualisiert am $(date)"

Häufige Staging-Fallstricke

URLs nicht aktualisiert - Wenn Sie die Datenbank kopieren, aber vergessen, ps_shop_url und die PS_SHOP_DOMAIN-Konfigurationswerte zu aktualisieren, leitet Ihre Staging-Site zur Produktion weiter.
Zahlungsgateways im Live-Modus - Schalten Sie Zahlungsgateways auf Staging immer in den Sandbox-/Testmodus. Sie möchten nicht, dass Staging-Testbestellungen echte Zahlungen verarbeiten.
E-Mail-Benachrichtigungen an Kunden - Deaktivieren Sie den E-Mail-Versand auf Staging oder leiten Sie alle E-Mails an eine Testadresse um.
Suchmaschinenindizierung - Blockieren Sie Staging immer für Suchmaschinen mit robots.txt, Meta-Noindex-Tags und idealerweise HTTP-Authentifizierung.
Cron-Jobs auf Staging - Deaktivieren Sie alle Cron-Jobs, die von der Produktion kopiert wurden, insbesondere solche, die E-Mails senden, Zahlungen verarbeiten oder sich mit externen Diensten synchronisieren.

Vollständige Antwort lesen

Cookie	Anbieter	Zweck	Dauer
PrestaShop-*	PrestaShop	Sitzungsverwaltung und Warenkorb-Funktionalität	Sitzung
PHPSESSID	PHP	PHP-Sitzungskennung	Sitzung
mprcr_consent	MPR Cookies Revolution	Speichert Cookie-Einwilligungseinstellungen	365 Tag(e)
mprcr_version	MPR Cookies Revolution	Verfolgt die Version der Einwilligungskonfiguration	365 Tag(e)

Cookie	Anbieter	Zweck	Dauer
TawkConnectionTime	Tawk.to	Verfolgt die Verbindungszeit der Chat-Sitzung	Sitzung
__tawkuuid	Tawk.to	Identifiziert wiederkehrende Chat-Besucher	6 Monat(e)

Cookie	Anbieter	Zweck	Dauer
_ga	Google Analytics	Unterscheidet eindeutige Benutzer durch eine zufällig generierte Nummer	2 Jahr(e)
_ga_*	Google Analytics	Wird verwendet, um den Sitzungsstatus über Seitenaufrufe hinweg beizubehalten	2 Jahr(e)
_gid	Google Analytics	Unterscheidet eindeutige Benutzer für 24 Stunden	24 Stunde(n)

Installation & Einrichtung

Linux-Dateiberechtigungen verstehen

Korrekte Berechtigungen fuer PrestaShop-Verzeichnisse und -Dateien

Korrekten Eigentumer mit chown festlegen

Shared Hosting vs. VPS vs. Dedizierter Server

Shared Hosting

VPS (Virtual Private Server)

Dedizierter Server

PHP-Ausfuehrungsmodelle: suPHP vs. mod_php vs. PHP-FPM

mod_php (Apache-Modul)

suPHP

PHP-FPM (FastCGI Process Manager)

Warum 777-Berechtigungen gefaehrlich sind

Docker-Besonderheiten fuer PrestaShop

Fehlerbehebung haeufiger Berechtigungsfehler

"Failed to open stream: Permission denied"

"Unable to write to cache directory"

"Cannot upload image" oder "Cannot install module"

"index.php is not writable" waehrend Updates

Weisse Seite nach Aenderung der Berechtigungen

Berechtigungen werden nach FTP-Upload zurueckgesetzt

Sicherheits-Best-Practices ueber Berechtigungen hinaus

Wenn Modul-Updates schiefgehen

Bevor Sie beginnen - Sicherheit zuerst

Methode 1 - Vorherige Version über das Back Office neu installieren

Schritt-für-Schritt-Anleitung

Wo Sie die vorherige Version bekommen

Methode 2 - FTP/SFTP Dateiersetzung

Schritt-für-Schritt-Anleitung

Methode 3 - Über die Kommandozeile

Methode 4 - Vollständiges Datenbank-Rollback

Wann Sie ein Datenbank-Rollback brauchen

Methode 5 - Manuelle Datenbankbereinigung

Prüfen, was sich geändert hat

Nach dem Downgrade - Wichtige Aufräumarbeiten

Alle Caches leeren

Modulversion verifizieren

Gründlich testen

Zukünftige Update-Probleme verhindern

Wann den Modulentwickler kontaktieren

Wie man ein PrestaShop-Modul auf einer Staging-Umgebung testet

Warum Sie eine Staging-Umgebung brauchen

Option 1 - Manuelle Staging-Einrichtung (Subdomain)

Schritt 1 - Subdomain erstellen

Schritt 2 - Produktionsdateien kopieren

Schritt 3 - Datenbank exportieren und importieren

Schritt 4 - PrestaShop-Konfiguration aktualisieren

Schritt 5 - Caches leeren

Schritt 6 - Zugriff einschränken

Option 2 - Docker-basiertes Staging (Empfohlen für Entwickler)

Grundlegendes Docker-Compose-Setup

Produktionsdaten in Docker importieren

Option 3 - Lokales Staging mit XAMPP/MAMP

Testcheckliste für neue Module

Phase 1 - Vorab-Installationsprüfungen

Phase 2 - Installationstest

Phase 3 - Funktionale Tests

Phase 4 - Konflikttest

Phase 5 - Leistungstest

Phase 6 - Deinstallationstest

Ein getestetes Modul in die Produktion überführen

Schritt 1 - Bereitstellung planen

Schritt 2 - Produktions-Backup erstellen

Schritt 3 - Auf Produktion installieren

Schritt 4 - Gleiche Konfiguration anwenden

Schritt 5 - In Produktion verifizieren

Schritt 6 - 24-48 Stunden überwachen

Staging mit der Produktion synchron halten

Häufige Staging-Fallstricke

Andere Kategorien

Haben Sie noch Fragen?