Schritt-für-Schritt-Anleitungen zur Installation und Konfiguration von mypresta.rocks-Modulen in Ihrem PrestaShop-Shop. Umfasst Modul-Upload, Aktivierung, Ersteinrichtung und Fehlerbehebung häufiger Installationsprobleme auf PrestaShop 1.7, 8.x und 9.x.
Keine Fragen stimmen mit Ihrer Suche überein.
Dies ist eine serverseitige PHP-Einschränkung, kein Modulproblem. Ihr Hosting-Anbieter hat einen niedrigen Wert für upload_max_filesize oder post_max_size in der php.ini festgelegt. Kontaktieren Sie Ihren Hoster und bitten Sie ihn, beide Werte auf mindestens 32MB zu erhöhen. Alternativ können Sie das Modul per FTP hochladen: Entpacken Sie die ZIP-Datei und laden Sie den Modulordner in /modules/ auf Ihrem Server hoch, dann installieren Sie es über das Back Office.
Learn more: contact our support team.
Es gibt zwei Möglichkeiten, unsere Module zu installieren:
- Kostenlose Installation: Eröffnen Sie ein Support-Ticket und wir installieren es für Sie.
- Manuelle Installation: Laden Sie die Modul-ZIP-Datei über Ihr PrestaShop Back Office unter Module > Module Manager > Modul hochladen hoch.
Konfigurieren Sie das Modul nach der Installation über die Einstellungsseite im Admin-Panel.
Learn more: free installation support.
Auf jeden Fall! Wir gestalten jedes Modul mit Einfachheit im Fokus. Die Konfiguration erfolgt über übersichtliche Admin-Panels mit beschreibenden Bezeichnungen und Hilfetexten. Die meisten Module funktionieren sofort mit sinnvollen Standardeinstellungen. Und denken Sie daran — kostenlose Installation ist bei jedem Kauf enthalten, sodass Sie keine Dateien anfassen müssen.
Learn more: our support options.
Nein, die meisten Module können direkt über das PrestaShop Back Office installiert werden (Module → Module Manager → Modul hochladen). FTP wird nur als Ausweichlösung benötigt, wenn Ihr Server restriktive Upload-Größenbeschränkungen hat oder wenn während des Uploads Berechtigungsprobleme auftreten.
Learn more: our support team can help.
Unsere Module werden nach PrestaShop Best Practices entwickelt und verwenden Namespaced Code, um Konflikte zu vermeiden. Wir testen gegen alle wichtigen Modulkategorien (Zahlung, Versand, SEO, Themes). Sollten Sie einen seltenen Konflikt erleben, wird unser Team das Problem ohne zusätzliche Kosten untersuchen und lösen.
Learn more: our module technology.
Der Vorgang ist derselbe wie bei 8.x: Gehen Sie zu Module → Module Manager, klicken Sie oben rechts auf „Modul hochladen" und wählen Sie die ZIP-Datei aus. PrestaShop 9 verwendet den gleichen Modulinstallationsmechanismus. Wenn Sie das Modul gekauft haben, laden Sie die neueste Version aus Ihrem Konto herunter — ältere Versionen sind möglicherweise nicht PS 9 kompatibel.
Learn more: PrestaShop 9 migration guide.
Die meisten Module bieten integrierte Konfigurationsoptionen für Farben, Layout und Anzeigeeinstellungen. Für tiefgreifendere Anpassungen verwenden unsere Module sauberes CSS mit CSS Custom Properties, die Sie leicht in Ihrem Theme überschreiben können. Brauchen Sie etwas Spezielleres? Wir bieten erschwingliche Anpassungsdienstleistungen an.
Learn more: PrestaShop child themes.
Mehrere mögliche Ursachen: (1) Das Modul muss möglicherweise zuerst konfiguriert werden — gehen Sie zur Einstellungsseite des Moduls und schließen Sie die Einrichtung ab. (2) Ihr Theme unterstützt möglicherweise den Hook nicht, den das Modul verwendet — versuchen Sie, das Modul über Design → Positionen in einen anderen Hook zu transplantieren. (3) Das Modul ist möglicherweise nur für bestimmte Seiten oder Produkte aktiv — überprüfen Sie die Einstellungen. (4) Ihr Browser-Cache oder der PrestaShop-Cache zeigt möglicherweise eine alte Seite — leeren Sie beide und prüfen Sie erneut.
Learn more: PrestaShop hooks.
Ja, selbstverständlich. Ihre Lizenz deckt eine Produktions-Domain plus eine Entwicklungs-/Staging-Subdomain ab (z.B. dev.beispiel.de). Eine lokale Umgebung (localhost, Docker, WAMP, MAMP) zählt nicht zu Ihrer Lizenz — installieren Sie frei zum Testen und Entwickeln.
Learn more: PrestaShop local development.
Unsere Module unterstützen PHP 7.2 bis 8.3+ (und PHP 8.4 für die meisten Module). Das genaue Minimum hängt vom Modul und der PrestaShop-Version ab, die Sie verwenden. Als Faustregel gilt: Wenn Ihre PHP-Version mit Ihrer PrestaShop-Version kompatibel ist, funktioniert sie auch mit unseren Modulen. Überprüfen Sie die Produktseite für spezifische Anforderungen.
Learn more: our technical requirements.
Ein weißer Bildschirm (WSOD) bedeutet in der Regel einen fatalen PHP-Fehler. Aktivieren Sie den Debug-Modus in PrestaShop (bearbeiten Sie /config/defines.inc.php und setzen Sie _PS_MODE_DEV_ auf true), um die tatsächliche Fehlermeldung zu sehen. Die häufigsten Ursachen sind: PHP-Versionsinkompatibilität, fehlende PHP-Erweiterung oder ein Konflikt mit einem anderen Modul. Senden Sie uns die Fehlermeldung und wir helfen bei der Lösung.
Learn more: PrestaShop troubleshooting guide.
Laden Sie die neueste Version von Ihrer Mein Konto-Seite herunter. Gehen Sie dann in PrestaShop zu Module → Module Manager → Modul hochladen und laden Sie die neue ZIP-Datei hoch. PrestaShop erkennt, dass das Modul bereits installiert ist, und führt den Upgrade-Prozess durch. Wichtig: Erstellen Sie immer ein Backup Ihrer Datenbank, bevor Sie ein Modul aktualisieren.
Nein. Modul-Updates sind so konzipiert, dass Ihre bestehende Konfiguration erhalten bleibt. Der Update-Prozess führt Upgrade-Skripte aus, die neue Funktionen hinzufügen, ohne Ihre Einstellungen zu verändern. Dennoch empfehlen wir immer, vor jedem Update ein Datenbank-Backup zu erstellen — nicht weil wir Probleme erwarten, sondern weil es eine gute Praxis ist.
Learn more: our support policy.
Ja, wir installieren jedes gekaufte Modul kostenlos für Sie. Kontaktieren Sie uns nach dem Kauf mit Ihrer Shop-URL und Admin-/FTP-Zugangsdaten, und wir installieren und konfigurieren das Modul initial. Die meisten Installationen werden innerhalb eines Werktages abgeschlossen.
Learn more: our free installation service.
Nein, Sie müssen zuerst Ihre PHP-Version upgraden. Eine niedrigere PHP-Version als erforderlich führt zu Fehlern oder stillen Ausfällen. Kontaktieren Sie Ihren Hosting-Anbieter, um PHP zu upgraden. Die meisten modernen Hoster unterstützen PHP 8.1+ und der Wechsel ist in der Regel unkompliziert. Wenn Sie unsicher sind, welche PHP-Version Sie wählen sollen, nehmen Sie die von Ihrer PrestaShop-Version empfohlene.
Learn more: our technical requirements.
In den meisten Fällen ja. Unsere Module verwenden Standard-PrestaShop-Hooks und modifizieren keine Core-Dateien, was das Konfliktpotenzial minimiert. Allerdings können wir keine Kompatibilität mit jedem Drittanbieter-Modul garantieren — insbesondere bei solchen, die die gleichen Hooks überschreiben oder die gleichen Datenbanktabellen modifizieren. Wenn Sie einen Konflikt feststellen, kontaktieren Sie uns mit Details und wir untersuchen das.
Learn more: contact support for compatibility questions.
Dies ist ein generischer PrestaShop-Fehler. Um die wahre Ursache zu finden: (1) Aktivieren Sie den Debug-Modus, um detaillierte Fehler zu sehen. (2) Überprüfen Sie das PHP-Fehlerlog Ihres Servers. (3) Stellen Sie sicher, dass das /modules/-Verzeichnis beschreibbar ist. (4) Überprüfen Sie, dass Sie die richtige Version für Ihre PrestaShop-Version heruntergeladen haben. Wenn Sie es nicht lösen können, senden Sie uns einen Screenshot des Fehlers im Debug-Modus und wir helfen Ihnen.
Learn more: PrestaShop troubleshooting guide.
Ja. Unsere Module sind Standard-PrestaShop-Module — sie funktionieren auf jedem Hosting, das PrestaShop ausführt. Managed-Hosting-Plattformen wie Cloudways, RunCloud oder GridPane übernehmen nur die Serververwaltung für Sie. Installieren Sie Module wie gewohnt über das PrestaShop Back Office. Das einzige potenzielle Problem sind ungewöhnliche PHP-Einschränkungen oder Sicherheitsregeln Ihres Managed-Hosters — kontaktieren Sie in diesem Fall deren Support.
Learn more: PrestaShop hosting recommendations.
Leeren Sie alle Cache-Schichten: (1) PrestaShop-Cache (Erweiterte Einstellungen → Leistung). (2) Wenn Sie CCC (Combine, Compress, Cache) verwenden, deaktivieren Sie es, leeren Sie den Cache und aktivieren Sie es dann erneut. (3) Wenn Sie hinter Cloudflare oder einem anderen CDN sind, leeren Sie den CDN-Cache. (4) Browser-Hard-Refresh (Strg+Umschalt+R). (5) Wenn Ihr Server Varnish verwendet, leeren Sie den Varnish-Cache. Jede Caching-Schicht ist unabhängig — Sie müssen alle leeren, um Änderungen sofort zu sehen.
See also: Performance Revolution — complete performance optimisation for PrestaShop
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/prestashopDas 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/prestashopIn 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-datasetzen (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-datahinzufuegen
Um Ihren SSH-Benutzer zur Webserver-Gruppe hinzuzufuegen:
sudo usermod -a -G www-data ihrbenutzernameDann 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/htmlbeim Containerstart ausfuehrt. Dies ist einfach, kann aber bei grossen Installationen langsam sein. - Gruppenberechtigungen setzen: Fuegen Sie Ihren Host-Benutzer und
www-dataderselben 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.logBerechtigungen 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.phpenthaelt 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 -Indexeszu Ihrer Apache-Konfiguration oderautoindex 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.
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.
mymodulezumymodule_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.
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.gzSchritt 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.sqlSchritt 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 staginguserOption 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.phpmit 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.sqlPhase 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.htmlEin 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_urlund diePS_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.
Andere Kategorien
Haben Sie noch Fragen?
Can't find what you're looking for? Send us your question and we'll get back to you quickly.