PrestaShop-Modul installieren - FAQ zur Einrichtung

Das ist normalerweise ein PHP-Upload-Limit, kein Problem mit der Modul-ZIP. PrestaShop empfängt die ZIP über den normalen PHP-Upload-Ablauf; wenn PHP die Datei zuerst ablehnt, kann das Back Office nur einen Fehler wie "file too large" oder einen unvollständigen Upload anzeigen.

Advanced Parameters > Information mit PHP-Upload- und Speicherlimits — Advanced Parameters > Information - deine PHP-Limits upload_max_filesize, post_max_size und memory_limit hinter der Meldung 'file too large'.

Bitten Sie Ihren Hoster, upload_max_filesize und post_max_size zu erhöhen. Setzen Sie post_max_size höher als upload_max_filesize, weil der gesamte HTTP POST zusätzlichen Overhead hat. Für größere Module oder langsames Shared Hosting erhöhen Sie außerdem max_execution_time, damit PHP genug Zeit hat, das Archiv zu kopieren und zu entpacken.

; php.ini or .user.ini example
upload_max_filesize = 64M
post_max_size = 80M
max_execution_time = 300
memory_limit = 256M

# Apache + mod_php only, not PHP-FPM
php_value upload_max_filesize 64M
php_value post_max_size 80M
php_value max_execution_time 300

Starten Sie nach der Änderung der PHP-Einstellungen PHP-FPM oder Apache neu, falls Ihr Hoster das verlangt, laden Sie dann das PrestaShop Back Office neu und versuchen Sie es erneut. Wenn Sie diese Werte nicht ändern können, laden Sie stattdessen per FTP/SFTP hoch: Entpacken Sie das Modul lokal, kopieren Sie den Modulordner nach /modules/ und installieren Sie ihn dann über Modules > Module Manager. Das installierte Ergebnis ist dasselbe wie bei einem erfolgreichen ZIP-Upload.

Hängen Sie immer noch fest? Kontaktieren Sie unser Support-Team mit ZIP-Name, Dateigröße, PrestaShop-Version, PHP-Version und der exakten Upload-Fehlermeldung.

Wenn Sie FTP/SFTP verwenden, achten Sie darauf, den Ordner hochzuladen, der die Haupt-PHP-Datei des Moduls enthält. Ein Modul, dessen Source $this->name = 'mprinternallinking' deklariert, muss zum Beispiel als /modules/mprinternallinking/ liegen, mit mprinternallinking.php und seinen vendor/-, controllers/-, views/- oder src/-Dateien im selben Ordner. Ein zusätzlicher Wrapper-Ordner ist ein häufiger Grund, warum das Modul im Module Manager nicht erscheint.

Nachdem die Dateien vorhanden sind, hören Sie dort nicht auf. Die Installationsroutine erstellt Modultabellen, registriert Hooks und fügt Admin-Controller hinzu. In den geprüften Modulen kann Installationscode außerdem Opcache zurücksetzen, gemeinsamen Admin-Konfigurationsspeicher installieren und Standardwerte setzen. Wenn Sie nur Dateien kopieren und nie auf Install klicken, fehlen diese Datenbanktabellen und Hooks.

Wenn ein früherer fehlgeschlagener Upload einen halb erstellten Ordner hinterlassen hat, entfernen Sie nur diesen unvollständigen Modulordner, bevor Sie es erneut versuchen, und laden Sie dann eine saubere Kopie hoch. Löschen Sie nicht wahllos PrestaShop-Cache oder andere Modulordner, nur weil der Upload fehlgeschlagen ist; der Fehler ist meistens aufgetreten, bevor der Modul-Installationscode überhaupt lief.

Vollständige Antwort lesen

Um ein PrestaShop-Modul zu installieren, laden Sie die ZIP-Datei im Back Office hoch: Gehen Sie zu Modules → Module Manager → Upload a module, ziehen Sie die heruntergeladene ZIP-Datei hinein, und PrestaShop entpackt und installiert sie für Sie. Für den Standardfall ist kein FTP nötig.

PrestaShop Module Manager mit der Schaltfläche „Modul hochladen“ — PrestaShop-Backoffice - Module Manager, in dem Sie eine Modul-ZIP hochladen.

Ein paar Dinge sollten Sie vor dem Start wissen:

Laden Sie die ZIP unverändert hoch — entpacken Sie sie nicht vorher. PrestaShop liest das Archiv direkt.
Wenn der Upload bei einem größeren Modul fehlschlägt, liegt es meist am Limit Ihres Servers für upload_max_filesize oder post_max_size — erhöhen Sie es in den PHP-Einstellungen oder laden Sie den Ordner per FTP nach /modules/ hoch und installieren Sie ihn aus dem Module Manager.
Öffnen Sie nach der Installation den Bildschirm Configure des Moduls, um es einzurichten — die reine Installation erledigt selten die ganze Arbeit.

Alle unsere Module werden auf diese Weise installiert. Die neueste ZIP für jedes von Ihnen gekaufte Modul finden Sie in Ihrem Konto; anschließend können Sie das komplette Sortiment im mypresta.rocks store durchstöbern.

Das wichtige technische Detail ist: Ein PrestaShop-Modul wird durch seinen internen Ordner- und Klassennamen identifiziert, nicht durch den Dateinamen, den Sie heruntergeladen haben. Im Modulquellcode deklarieren Pakete einen technischen Namen wie mprcanonicalmanager, eine Version, einen Tab, einen Kompatibilitätsbereich und einen Anzeigenamen. Lassen Sie diesen obersten Ordner unverändert; benennen Sie ihn nicht um und laden Sie nicht versehentlich einen verschachtelten Ordner wie module.zip/mprcanonicalmanager/ hoch.

Die Installation führt außerdem Modulcode aus. Je nach Modul kann dieser Code Datenbanktabellen anlegen, Hooks registrieren, Admin-Menüeinträge installieren und Standardeinstellungen setzen. Ein SEO- oder Internal-Linking-Modul kann zum Beispiel eigene Regel-Tabellen anlegen, Ausgabe-Hooks registrieren und während install() seine Konfigurationsseiten hinzufügen. Dateien nach /modules/ zu kopieren ist daher nur die erste Hälfte einer FTP-Installation; das Modul muss weiterhin im Module Manager installiert werden, damit seine Einrichtungsroutine ausgeführt wird.

Eine sichere Checkliste:

Laden Sie die neueste ZIP aus Ihrem Konto herunter.
Laden Sie die ZIP über den Module Manager hoch, wenn Ihr Server das erlaubt.
Wenn PHP-Upload-Limits die ZIP blockieren, entpacken Sie sie lokal und laden Sie den einen Modulordner nach /modules/ hoch.
Suchen Sie das Modul im Module Manager, klicken Sie auf Install, öffnen Sie dann Configure und speichern Sie die erforderlichen Optionen.

Vollständige Antwort lesen

Nein — für die meisten Module müssen Sie PrestaShop FTP überhaupt nicht anfassen. Der Standardweg ist das Back Office: Modules → Module Manager → Upload a module, ZIP hineinziehen, fertig. FTP ist nur ein Fallback für zwei bekannte Fälle.

Upload a module-Bildschirm im PrestaShop Module Manager — PrestaShop Module Manager - der Einstiegspunkt Upload a module.

Die ZIP überschreitet Ihr PHP-Upload-Limit. Shared Hosts begrenzen upload_max_filesize und post_max_size oft auf wenige Megabyte, sodass größere Modul-ZIPs im Browser fehlschlagen. Erhöhen Sie beide PHP-Werte im Hosting-Panel oder laden Sie das Modul per FTP hoch.
Berechtigungs- oder Teil-Upload-Fehler. Wenn das Back Office einen Berechtigungsfehler oder ein halb installiertes Modul meldet, gibt Ihnen FTP einen sauberen Wiederherstellungsweg.

So installieren Sie ein Modul per FTP: Entpacken Sie es lokal, laden Sie den entstandenen Ordner, zum Beispiel mprseorevolution/, in /modules/ im Shop-Root hoch, stellen Sie sicher, dass die Dateien für den Webserver-Benutzer lesbar sind (Ihr Hoster kann das bestätigen), öffnen Sie dann den Module Manager, suchen Sie nach dem Modulnamen und klicken Sie auf Install.

Die meisten unserer Module sind klein genug, um direkt über den Module Manager hochgeladen zu werden. FTP bleibt also ein Backup, keine Voraussetzung. Siehe auch: installing a module on PrestaShop.

Der Ordnername ist wichtig. Modulklassen deklarieren einen technischen Namen wie mprcanonicalmanager, mprinternallinking oder mprcheckoutrevolution. Genau diesen Ordner erwartet PrestaShop unter /modules/. Lassen Sie die Haupt-PHP-Datei des Moduls, den Composer-Autoloader, Controller, Views und Source-Klassen zusammen in diesem Ordner.

FTP umgeht die Moduleinrichtung nicht. Es umgeht nur das Browser-Upload-Limit. Sie müssen weiterhin auf Install klicken, damit das Modul seine Tabellen erstellt, Hooks registriert und seine Back-Office-Bildschirme hinzufügt. Ein Modul kann zum Beispiel Datenbanktabellen für Linkgruppen oder Angebotsstatus deklarieren und diese Tabellen sowie Hooks während seiner Installationsmethode erstellen.

Nutzen Sie FTP als Wiederherstellungswerkzeug, nicht als täglichen Workflow. Wenn der Back-Office-Upload funktioniert, ist er sauberer, weil PrestaShop Archiv, Ordnerplatzierung und Installationsfluss an einer Stelle behandelt. Wenn FTP nötig ist, laden Sie einmal hoch, installieren einmal und konfigurieren das Modul dann über seine Admin-Seite, statt aktive Dateien wiederholt zu überschreiben.

Vollständige Antwort lesen

Um ein Modul auf PrestaShop 9 zu installieren, gehen Sie zu Modules → Module Manager, klicken Sie oben rechts auf Upload a module und ziehen Sie die ZIP hinein, die Sie aus Ihrem Konto heruntergeladen haben. Der Pfad ist derselbe, den Sie bereits aus PrestaShop 8.x kennen.

Zwei Dinge sollten Sie bei PrestaShop 9 vorher prüfen:

Holen Sie sich den neuesten Build. Ältere Modul-ZIPs, die vor PrestaShop 9 entstanden sind, können sich auf Dienste verlassen, die entfernt wurden. Laden Sie vor dem Upload immer die neueste Version aus Ihrem Konto herunter.
Prüfen Sie Ihre PHP-Version. PrestaShop 9 benötigt mindestens PHP 8.1; PHP 8.2 oder 8.3 ist eine vernünftige Wahl, wenn Ihre Module und Ihr Theme es unterstützen.

Wenn der Upload still fehlschlägt oder einen 500-Fehler zurückgibt, löschen Sie auf PrestaShop 9 nicht roh var/cache/prod/ — das kann den Symfony-Container des Back Office entfernen und Sie aussperren. Leeren Sie den Cache stattdessen über Advanced Parameters → Performance oder lassen Sie Ihren Hoster php bin/console cache:clear --env=prod ausführen. Kein FTP? Lesen Sie unseren FTP-free install guide.

Warum die neueste ZIP wichtig ist, sieht man im Modulquellcode: Module deklarieren ihren eigenen PrestaShop-Kompatibilitätsbereich. Manche Pakete unterstützen ausdrücklich breite Bereiche bis 9.99 oder 9.99.99, während andere eine Mindestversion wie 1.7.6 setzen. Eine ZIP, die gebaut wurde, bevor PrestaShop-9-Support ergänzt wurde, kann Dateien installieren, die zwar technisch vorhanden sind, aber nicht mit den Diensten, Hooks oder der PHP-Laufzeit kompatibel sind, die Ihr Shop jetzt nutzt.

Öffnen Sie nach dem Upload die Modulkonfigurationsseite und speichern Sie die Einstellungen. PrestaShop 9 kann das Modul als installiert anzeigen, während der nützliche Teil weiterhin von Konfigurationswerten wie API-Keys, SEO-Schaltern, Standardwerten für Angebotsstatus, Sitemap-Optionen, Selektoren, Tracking-IDs oder Cron-Tokens abhängt. Viele Module setzen während der Installation Defaults, aber händlerspezifische Werte gehören weiterhin in den Configure-Bildschirm.

Wenn der ZIP-Upload wegen der Größe fehlschlägt, nutzen Sie denselben FTP-Fallback wie bei PrestaShop 8: lokal entpacken, den einen Modulordner nach /modules/ hochladen und ihn dann aus dem Module Manager installieren. Lassen Sie den Ordnernamen exakt wie ausgeliefert, weil der Modulklassenname und der interne Wert $this->name an dieses Verzeichnis gebunden sind.

Nein — Sie müssen PHP auf Ihrem Server mindestens auf die Version bringen, die das Modul verlangt. Älteres PHP als gefordert verursacht Syntaxfehler oder stille Fehler während der Installation.

PrestaShop-Backoffice, Modules > Module Manager, Warnung zur PHP-Anforderung eines Moduls im Admin-Bereich. — Die Warnung bedeutet, dass das Modul erst ausgeführt werden kann, wenn die PHP-Version Ihres Servers die Anforderung erfüllt.

So beheben Sie es:

Prüfen Sie Ihre aktuelle PHP-Version im PrestaShop Back Office → Advanced Parameters → Information oder mit einer einzeiligen <?php phpinfo(); ?>-Datei.
Wechseln Sie PHP in Ihrem Hosting-Panel. Bei cPanel ist es MultiPHP Manager; bei Plesk Domains → PHP Settings; bei Managed Hosts liegt der Schalter in Ihren Domain- oder Website-Einstellungen.
Wählen Sie die Version, die Ihr PrestaShop und Ihre Module unterstützen. Die Installationsmeldung des Moduls nennt die Mindestversion — erfüllen Sie sie oder gehen Sie höher, innerhalb des Bereichs, auf dem Ihre PrestaShop-Edition läuft.
Leeren Sie den PrestaShop-Cache (Advanced Parameters → Performance) nach dem PHP-Wechsel und versuchen Sie die Installation erneut.

Wenn Ihr Hoster keine ausreichend aktuelle PHP-Version anbietet, ist das der Moment für einen Umzug — PrestaShop auf veraltetem PHP zu betreiben ist auch ein Sicherheitsrisiko. In unserem PrestaShop-Hosting-Guide sehen Sie, worauf Sie achten sollten.

Diese Meldung ist keine Warnung, die Sie sicher ignorieren können. In den geprüften Modulen werden PHP-Anforderungen im Code oder in Paket-Metadaten durchgesetzt. Die Integritätsklasse von Checkout Revolution definiert zum Beispiel eine Mindest-PHP-Version und prüft das laufende PHP_VERSION dagegen. Auch das gemeinsame Internal-Linking-Paket deklariert eine Composer-PHP-Anforderung. Liegt der Server unter der geforderten Version, kann das Modul scheitern, bevor seine Admin-Seite überhaupt gerendert werden kann.

Lösen Sie das nicht, indem Sie die Moduldatei bearbeiten und die Anforderung senken. Das entfernt nur die Schutzprüfung; es bringt älterem PHP nicht bei, neue Syntax, Typdeklarationen oder Bibliothekscode zu verstehen. Die richtige Lösung ist eine PHP-Version, die sowohl vom PrestaShop-Core als auch von den installierten Modulen unterstützt wird.

Prüfen Sie beim PHP-Wechsel den ganzen Shop, nicht nur das neue Modul. Ihr Theme, Zahlungs-, Versandmodule und Overrides laufen alle auf demselben PHP-Interpreter. Leeren Sie nach dem Wechsel den Cache, öffnen Sie Front Office und Back Office, platzieren Sie eine kleine Testbestellung, wenn Checkout-relevante Module beteiligt sind, und prüfen Sie die PHP-Error-Logs auf Fatal Errors, bevor Sie das Update als abgeschlossen betrachten.

Vollständige Antwort lesen

Eine Modulinstallation scheitert meistens, weil PrestaShop das Archiv nicht lesen kann, die Moduldateien nicht schreiben darf oder das Modul auf dem aktuellen Server nicht lauffähig ist.

Advanced Parameters > Logs mit dem Back-Office-Fehlerprotokoll — Advanced Parameters > Logs - dort wird der echte Fehler 'Unable to install' protokolliert, damit du die Ursache lesen kannst.

Prüfen Sie zuerst die ZIP-Struktur. Das Archiv sollte auf oberster Ebene genau einen Modulordner enthalten, in dem die Haupt-PHP-Datei des Moduls liegt, zum Beispiel mymodule/mymodule.php. Ein häufiger Fehler ist der Upload einer GitHub-artigen ZIP mit einem zusätzlichen Wrapper-Ordner, Dokumentationsordner oder verschachtelten Modulordner statt des tatsächlich installierbaren Modulverzeichnisses.

zip=module.zip
unzip -Z1 "$zip" | sed -n '1,20p'
unzip -Z1 "$zip" | awk -F/ 'NF{print $1}' | sort -u
find modules -maxdepth 0 -writable -print
php -v
php -m | grep -Ei '^(zip|curl|dom|fileinfo|json|mbstring|openssl|intl)$'
ls -lt var/logs/* 2>/dev/null | head

Upload-Limits prüfen: Das effektive Limit wird durch upload_max_filesize und post_max_size bestimmt. Wenn die ZIP größer als einer dieser Werte ist, kann der Back-Office-Upload fehlschlagen, bevor PrestaShop das Modul überhaupt installiert.
Berechtigungen prüfen: Das Verzeichnis modules/ muss für den Webserver-Benutzer beschreibbar sein, ebenso Cache- und Log-Verzeichnisse.
PHP-Kompatibilität prüfen: Eine falsche PHP-Version oder fehlende PHP-Erweiterungen wie zip, curl, dom, fileinfo, json, mbstring, openssl oder intl können Installation oder Konfigurationsseiten beschädigen.
PrestaShop-Logs prüfen: Suchen Sie in var/logs/, auf der Back-Office-Fehlerseite und im Webserver-/PHP-FPM-Error-Log nach der eigentlichen Exception.
Cache nach einer fehlgeschlagenen Installation leeren, weil PrestaShop eventuell eine teilweise geladene Modulklasse zwischengespeichert hat.

Wenn das Modul in der Modulliste erscheint, sich aber nicht installieren lässt, wurde das Archiv wahrscheinlich erfolgreich entpackt und der Fehler liegt in der Installationsroutine des Moduls. Wenn es gar nicht erscheint, konzentrieren Sie sich zuerst auf ZIP-Struktur, Upload-Limits und Dateisystemberechtigungen.

Wenn die Installationsroutine fehlschlägt, nachdem der Ordner bereits entpackt wurde, entfernen Sie zuerst das halb installierte Modul im Module Manager, sofern es sichtbar ist, und leeren Sie anschließend var/cache/, bevor Sie es erneut versuchen. Wenn der Moduleintrag in der Datenbank existiert, das Backoffice die Modulseite aber nicht laden kann, wiederholen Sie den Vorgang nicht blind; stellen Sie das Datei-/Datenbank-Backup wieder her oder bitten Sie den Support, den fehlgeschlagenen install()-Schritt zu prüfen.

Wenn Sie den Support kontaktieren, senden Sie den Namen und die Version der Modul-ZIP, Ihre PrestaShop-Version, die PHP-Version, den genauen Fehlertext, die letzten Zeilen aus var/logs/prod.log oder var/logs/dev.log sowie die Information, ob der Modulordner nun unter modules/ existiert. So kann der Support erkennen, ob der Fehler beim Upload/Entpacken oder im eigenen Installer des Moduls aufgetreten ist.

Vollständige Antwort lesen

Linux-Dateiberechtigungen verstehen

Jede Datei und jedes Verzeichnis auf einem Linux-Server verfügt über drei Berechtigungssätze: einen für den Eigentümer, einen für die Gruppe und einen für Andere (alle übrigen). Jeder Satz steuert drei Aktionen: Lesen (r), Schreiben (w) und Ausführen (x). Diese Berechtigungen werden numerisch in Oktalschreibweise dargestellt, wobei Lesen gleich 4, Schreiben gleich 2 und Ausführen gleich 1 ist. Die Werte werden für jeden Satz addiert, was eine dreistellige Zahl wie 755 oder 644 ergibt.

Beispielsweise bedeutet eine Berechtigung von 755, dass der Eigentümer lesen, schreiben und ausführen kann (7 = 4+2+1), während die Gruppe und Andere nur lesen und ausführen können (5 = 4+0+1). Eine Berechtigung von 644 bedeutet, dass der Eigentümer lesen und schreiben kann (6 = 4+2+0), während die Gruppe und Andere nur lesen können (4 = 4+0+0). Das Verständnis dieses Systems ist grundlegend für den Betrieb eines sicheren und funktionsfähigen PrestaShop-Shops.

Über die numerischen Berechtigungen hinaus hat jede Datei einen Eigentümer und eine Gruppe. Auf einem Webserver läuft 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 können, um sie auszuliefern, und er benötigt Schreibzugriff auf bestimmte Verzeichnisse für Uploads, Caching und Konfiguration.

Korrekte Berechtigungen für PrestaShop-Verzeichnisse und -Dateien

Die allgemeine Regel für PrestaShop ist unkompliziert: Verzeichnisse sollten 755 und Dateien sollten 644 haben. Dies gibt dem Eigentümer volle Kontrolle, während die Gruppe und Andere lesen (und im Falle von Verzeichnissen ausführen/durchqüren) können, aber nichts ändern dürfen. Der Webserver-Benutzer sollte der Eigentümer aller PrestaShop-Dateien sein oder zumindest der Gruppe angehören, der sie gehören.

Um diese Berechtigungen für Ihre gesamte PrestaShop-Installation festzulegen, verbinden Sie sich per SSH mit Ihrem Server und führen 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 tatsächlichen 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 benötigen jedoch Schreibzugriff durch den Webserver. Diese Verzeichnisse erfordern besondere Aufmerksamkeit, da PrestaShop während des normalen Betriebs in sie schreibt:

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

Wenn der Webserver-Benutzer der Eigentümer dieser Dateien ist (was die empfohlene Einrichtung ist), reichen 755/644-Berechtigungen aus. Wenn der Webserver als ein anderer Benutzer läuft, müssen Sie möglicherweise die Gruppenberechtigungen oder den Eigentümer anpassen.

Korrekten Eigentümer mit chown festlegen

Die Eigentümerzuordnung ist genauso wichtig wie die Berechtigungen. Der Befehl chown ändert den Eigentümer und die Gruppe von Dateien. Für 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 Änderung 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 gängiger alternativer Ansatz ist, den Eigentümer auf Ihren SSH/FTP-Benutzer und die Gruppe auf den Webserver-Benutzer zu setzen. So können Sie Dateien über FTP oder SSH bearbeiten, während 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 benötigen, 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 maßgeblich, wie Dateiberechtigungen in der Praxis funktionieren. Das Verständnis der Unterschiede ist entscheidend für die korrekte Einrichtung der Berechtigungen.

Shared Hosting

Beim Shared Hosting greifen Sie typischerweise über FTP oder einen Dateimanager in cPanel/Plesk auf Dateien zu. Das PHP-Ausführungsmodell 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 läuft. Dies vereinfacht die Berechtigungen erheblich: Da PHP als Ihr Benutzer läuft, kann es bereits mit den Standard-Berechtigungen 755/644 Ihre Dateien lesen und schreiben. Sie müssen auf Shared Hosting selten die Eigentümerzuordnung ändern, da alles bereits Ihrem Konto gehört.

Wenn Sie auf Shared Hosting auf Berechtigungsfehler stoßen, prüfen Sie bei Ihrem Hoster, ob suPHP oder PHP-FPM verwendet wird. Wenn das ältere mod_php-Modell verwendet wird, müssen Sie möglicherweise einige Verzeichnisse vorübergehend auf 777 setzen (was aus Sicherheitsgründen jedoch nicht empfohlen wird). Die meisten seriöosen Hoster haben mod_php genau wegen dieser Berechtigungskomplikationen abgeschafft.

VPS (Virtual Private Server)

Auf einem VPS haben Sie die volle Kontrolle. Dies ist das gängigste Setup für ernsthafte PrestaShop-Shops. Sie sollten sicherstellen, dass der Webserver-Benutzer die PrestaShop-Dateien besitzt oder zumindest einer Gruppe angehört, die Lesezugriff hat. Die empfohlene Einrichtung ist:

Eigentümer auf www-data:www-data setzen (oder Ihren Webserver-Benutzer)
755 für Verzeichnisse und 644 für Dateien verwenden
SSH mit sudo für Änderungen verwenden oder Ihren SSH-Benutzer zur Gruppe www-data hinzufügen

Um Ihren SSH-Benutzer zur Webserver-Gruppe hinzuzufügen:

sudo usermod -a -G www-data ihrbenutzername

Dann setzen Sie das Gruppen-Schreibbit für Verzeichnisse, die Sie bearbeiten müssen:

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 können. Jeder Pool kann als anderer Benutzer laufen, was eine bessere Isolation bietet, wenn Sie mehrere PrestaShop-Shops auf demselben Server hosten.

PHP-Ausführungsmodelle: suPHP vs. mod_php vs. PHP-FPM

Die Art und Weise, wie PHP auf Ihrem Server ausgeführt wird, bestimmt direkt, welcher Benutzer Dateien schreibt und somit welche Berechtigungen benötigt werden.

mod_php (Apache-Modul)

Dies ist das älteste und einfachste Modell. PHP läuft als Teil des Apache-Prozesses, was bedeutet, dass sämtlicher PHP-Code als Apache-Benutzer ausgeführt wird (typischerweise www-data oder apache). Das Problem ist, dass von PHP erstellte Dateien (Cache, Uploads usw.) dem Webserver-Benutzer gehören 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 gehören, und Berechtigungen von 755/644 funktionieren korrekt. Allerdings ist dieses Modell auf modernen Servern weitgehend veraltet.

suPHP

suPHP führt PHP als Dateieigentümer aus, anstatt als Webserver-Benutzer. Das bedeutet: Wenn Ihre Dateien ihrbenutzername gehören, läuft 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 Dateieigentümer derselbe Benutzer sind.

Ein wichtiger Vorbehalt: suPHP lehnt Dateien mit Berechtigungen von 777 oder Dateien, die anderen Benutzern gehören, tatsächlich ab. Wenn Sie auf einem suPHP-Server 777 setzen, verweigert PHP die Ausführung dieser Dateien und zeigt stattdessen einen 500 Internal Server Error an.

PHP-FPM (FastCGI Process Manager)

PHP-FPM ist der moderne Standard. Es führt PHP als separaten Prozess vom Webserver aus, mit konfigurierbarem Benutzer/Gruppe pro Pool. Auf einem VPS läuft PHP-FPM typischerweise als www-data. Auf Shared Hosting mit CloudLinux oder ähnlichem erhält jedes Konto seinen eigenen PHP-FPM-Pool, der als Benutzer dieses Kontos läuft.

PHP-FPM in Kombination mit Nginx ist das empfohlene Setup für die PrestaShop-Performance. Das Standard-Berechtigungsschema 755/644 funktioniert gut. Stellen Sie sicher, dass der Benutzer des PHP-FPM-Pools mit dem Dateieigentümer übereinstimmt oder über entsprechenden Gruppenzugriff verfügt.

Warum 777-Berechtigungen gefährlich sind

Berechtigungen auf 777 zu setzen bedeutet, dass jeder auf dem System die Datei lesen, schreiben und ausführen kann. Auf Shared Hosting bedeutet dies, dass andere Konten auf demselben Server potenziell Ihre Datenbank-Zugangsdaten aus parameters.php auslesen oder schädlichen Code in Ihre PHP-Dateien einschleusen könnten.

Selbst auf einem VPS, wo Sie der einzige Benutzer sind, ist 777 unnötig und deutet auf eine Fehlkonfiguration hin. Wenn der Webserver bei 755-Berechtigungen nicht in ein Verzeichnis schreiben kann, ist die Lösung, die Eigentümerzuordnung zu korrigieren, nicht die Berechtigungen für alle zu öffnen. Hier ist, was Sie anstelle von 777 tun sollten:

Prüfen, als welcher Benutzer der Webserver läuft: ps aux | grep -E "apache|nginx|httpd"
Dateieigentum prüfen: 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 für PrestaShop empfiehlt, ist dies veralteter und gefährlicher Rat. Die einzige legitime Verwendung von 777 ist für /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 für PrestaShop

PrestaShop in Docker auszuführen führt zu zusätzlicher Komplexität bei Dateiberechtigungen. Innerhalb des Containers läuft 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 Dateizugehörigkeit 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 möglicherweise nicht in diese Dateien schreiben.

Lösungen für Docker-Berechtigungsprobleme umfassen:

UIDs abgleichen: Erstellen Sie einen Benutzer innerhalb des Containers mit derselben UID wie Ihr Host-Benutzer, oder ändern Sie den Webserver so, dass er als Ihre UID läuft.
chown im Entrypoint verwenden: Fügen Sie einen Startbefehl hinzu, der chown -R www-data:www-data /var/www/html beim Containerstart ausführt. Dies ist einfach, kann aber bei großen Installationen langsam sein.
Gruppenberechtigungen setzen: Fügen 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.

Für Entwicklungsumgebungen mit Bind Mounts ist der praktischste Ansatz, nach dem Synchronisieren oder Deployen von Dateien einen chown-Befehl auszuführen:

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 können, während Operationen auf dem Host Dateien als Ihr Host-Benutzer erstellen. Dieser ständige UID-Mismatch ist die häufigste Ursache für Berechtigungsprobleme in dockerisierten PrestaShop-Umgebungen.

Fehlerbehebung häufiger Berechtigungsfehler

"Failed to open stream: Permission denied"

Dieser Fehler bedeutet, dass PHP eine Datei nicht lesen oder schreiben kann. Überprüfen Sie die Eigentümerzuordnung und Berechtigungen der in der Fehlermeldung genannten Datei. Die häufigste 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 gehören:

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 löschen:

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 müssen vom Webserver-Benutzer beschreibbar sein. Überprüfen Sie zusätzlich, ob die PHP-Einstellungen upload_max_filesize und post_max_size groß genug für Ihre Dateien sind, da diese ähnlich klingende Fehler verursachen können.

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" während Updates

PrestaShops Auto-Updater benötigt Schreibzugriff auf nahezu jede Datei in der Installation. Bevor Sie ein Update ausführen, setzen Sie die Eigentümerzuordnung der gesamten Installation auf den Webserver-Benutzer. Nach Abschluss des Updates können Sie bei Bedarf restriktivere Eigentümerzuordnungen wiederherstellen.

Weiße Seite nach Änderung der Berechtigungen

Wenn Sie nach dem Ändern der Berechtigungen eine leere weiße Seite sehen, haben Sie möglicherweise versehentlich die Ausführungsberechtigung von Verzeichnissen entfernt. Verzeichnisse benötigen das Execute-Bit, um durchqürt werden zu können. Ein Verzeichnis mit Berechtigung 644 (kein Execute) ist effektiv unzugänglich. Verwenden Sie immer 755 für Verzeichnisse, niemals 644.

Sie können auch das PHP-Fehlerprotokoll für weitere Details prüfen:

sudo tail -50 /var/log/apache2/error.log
# oder für Nginx:
sudo tail -50 /var/log/nginx/error.log

Berechtigungen werden nach FTP-Upload zurückgesetzt

Einige FTP-Clients setzen beim Hochladen von Dateien ihre eigenen Standardberechtigungen. Überprüfen 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 führen Sie die Befehle zur Berechtigungskorrektur nach jedem FTP-Upload aus.

Sicherheits-Best-Practices über Berechtigungen hinaus

Korrekte Dateiberechtigungen sind nur eine Sicherheitsebene. Berücksichtigen Sie diese zusätzlichen Maßnahmen:

Zugriff auf Konfigurationsdateien einschränken: Die Datei app/config/parameters.php enthält Ihre Datenbank-Zugangsdaten. Stellen Sie sicher, dass sie nur vom Webserver-Benutzer lesbar ist (Berechtigung 640), nicht von der gesamten Welt.
Verzeichnisauflistung deaktivieren: Fügen Sie Options -Indexes zu Ihrer Apache-Konfiguration oder autoindex off; zu Nginx hinzu, um zu verhindern, dass Besucher Verzeichnisinhalte durchsuchen können.
.htaccess-Dateien schützen: PrestaShop platziert .htaccess-Dateien in sensiblen Verzeichnissen. Löschen Sie diese nicht.
Installationsverzeichnis entfernen: Löschen Sie nach der Installation das Verzeichnis /install/ vollständig. 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 standardmäßig mit 644/755-Berechtigungen erstellt werden.

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

Schritt-für-Schritt-Lösungen zu Berechtigungs- und Serverfehlern finden Sie in unserer PrestaShop-Fehlerbehebungs-Anleitung.

PrestaShop hat keinen eingebauten Undo-Button für ein Modulupdate, daher ist ein Downgrade ein kontrollierter Rollback von Dateien, Datenbankzustand und Cache. Gehen Sie langsam vor; ein schlechter Rollback kann schlimmer sein als das schlechte Update.

Shop in den Wartungsmodus versetzen über Shop-Einstellungen > Allgemein > Wartung, besonders wenn das Modul Checkout, Zahlung, Lagerbestand, Preise, URLs oder Tracking betrifft.
Zuerst ein vollständiges Backup erstellen. Sichern Sie den gesamten PrestaShop-Dateibaum, die Datenbank und den aktuellen Ordner /modules/module_name/. Behalten Sie auch die defekte Version; der Support kann sie zum Vergleich des Upgrades benötigen.
Aktuellen Zustand dokumentieren. Notieren Sie Modulname, neue Version, vorherige funktionierende Version, exakten Fehler, betroffene Seiten und aktuelle Bestell-IDs, falls der Checkout betroffen war.
Die exakt vorherige ZIP beschaffen. Nutzen Sie Bestellhistorie, Release-Archiv oder Support. Mischen Sie keine Dateien aus zwei Versionen.

Der sicherste Datei-Rollback ist normalerweise, den aktuellen Ordner umzubenennen, die alte ZIP sauber zu entpacken und den alten Modulordner wieder unter /modules/ abzulegen. Beispiel: /modules/examplemodule in /modules/examplemodule.bad-update umbenennen, den älteren Ordner examplemodule hochladen und dann die Modulversion im Module Manager prüfen. Klicken Sie nicht auf Delete. Seien Sie auch mit Uninstall vorsichtig: Viele Module behalten ihre Daten, aber manche Uninstall-Routinen entfernen Konfiguration oder eigene Tabellen absichtlich.

Wenn das Update Datenbanktabellen geändert hat, reichen Dateien allein eventuell nicht. Stellen Sie die betroffenen Tabellen und Konfigurationsschlüssel des Moduls aus dem Pre-Update-Backup wieder her oder fragen Sie den Support nach dem exakten Downgrade-SQL. Raten Sie niemals Schemaänderungen auf einem Live-Shop.

Nach Datei- und Datenbank-Rollback leeren Sie den PrestaShop-Cache unter var/cache/prod und var/cache/dev, leeren Smarty-Cache, wo zutreffend, setzen OPcache durch Reload von PHP-FPM oder Apache zurück und leeren CDN-/Varnish-/Full-Page-Cache, falls verwendet. Testen Sie anschließend die Modulfunktion selbst, die relevanten Front-Office-Seiten, das Speichern der Back-Office-Konfiguration und den Checkout end-to-end.

Bei Modulen, die bei uns gekauft wurden, ist die vorherige ZIP normalerweise in der Bestellhistorie verfügbar, und der Support kann bei Bedarf einen älteren Build bereitstellen. Zur Backup-Vorbereitung siehe unseren PrestaShop-Backup-Guide.

Ein ungetestetes Modul im Live-Shop zu installieren ist eine häufige Ursache für Ausfälle, kaputten Checkout und Umsatzverluste. Eine Staging-Umgebung — eine private Kopie Ihres Shops — lässt Sie jedes Modul prüfen, bevor es die Produktion berührt. Hier der vollständige Ablauf.

Warum Staging wichtig ist

Staging spiegelt Datenbank, Dateien, Theme und Module der Produktion, ist aber nicht öffentlich. Es fängt Probleme ab, die sonst Ihre Kunden treffen würden: Modulkonflikte (weiße Seiten, JavaScript-Fehler), Theme-Inkompatibilität, Leistungseinbußen, Datenbankschäden durch schlecht geschriebene Module und Checkout-/Zahlungsstörungen.

Option 1 — Subdomain-Staging (auf jedem Host)

Erstellen Sie eine Subdomain wie staging.ihrshop.de, die auf ein neues Verzeichnis zeigt, dann:

# Produktionsdateien kopieren
cp -r /home/ihruser/public_html/* /home/ihruser/staging.ihrshop.de/

# Datenbank exportieren und importieren
mysqldump -u dbuser -p production_db > /tmp/dump.sql
mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u dbuser -p staging_db < /tmp/dump.sql

# Staging-Kopie auf Staging-DB und -Domain zeigen lassen
mysql -u dbuser -p staging_db -e "
  UPDATE ps_shop_url SET domain='staging.ihrshop.de', domain_ssl='staging.ihrshop.de';
  UPDATE ps_configuration SET value='staging.ihrshop.de' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');"

# Caches leeren
rm -rf var/cache/prod/* var/cache/dev/* var/cache/smarty/compile/*

Anschließend Zugriff sperren: HTTP-Basic-Auth und einen Header X-Robots-Tag: noindex, nofollow in der .htaccess hinzufügen, damit die Staging-Site privat und aus den Suchergebnissen bleibt.

Option 2 — Docker-Staging (am nächsten an der Produktion)

Mit Docker bilden Sie Ihre PHP- und MySQL-Versionen exakt nach:

# docker-compose.yml (Image-Tag auf Ihre PrestaShop-Version setzen)
services:
  prestashop:
    image: prestashop/prestashop
    ports: ["8080:80"]
    volumes: ["./html:/var/www/html"]
    depends_on: [db]
  db:
    image: mysql
    environment:
      - MYSQL_DATABASE=prestashop
      - MYSQL_USER=prestashop
      - MYSQL_PASSWORD=ihr_passwort
      - MYSQL_ROOT_PASSWORD=root_passwort

Importieren Sie den Produktions-Dump in den Container und setzen Sie ps_shop_url und PS_SHOP_DOMAIN auf localhost:8080, SSL für den lokalen Zugriff deaktivieren.

Testcheckliste für ein neues Modul

Vor der Installation: Doku lesen, entpacken und Code auf verdächtige Aufrufe prüfen (eval(), base64_decode(), unbekannte externe URLs), DB-Backup anlegen.
Installieren über das Back Office (Modulmanager > Hochladen), Liste der installierten Module und das PHP-Fehlerprotokoll prüfen, neu angelegte Tabellen notieren.
Funktional: Konfigurationsseite öffnen und speichern; Front Office auf Startseite, Kategorie, Produkt, Warenkorb und Checkout prüfen; Mobilgeräte, jede Sprache und ggf. Multishop testen.
Konflikte: Browser-Konsole auf JavaScript-Fehler beobachten, eine volle Testbestellung mit jeder Zahlungsart durchführen und prüfen, ob Ihre kritischen Module weiterhin laufen.
Leistung: einige Schlüsselseiten vor und nach der Installation mit curl -o /dev/null -s -w "%{time_total}" messen — ein gut geschriebenes Modul fügt wenig hinzu.
Deinstallieren: entfernen und prüfen, dass Tabellen, Hooks und Assets sauber entfernt sind.

In die Produktion überführen

In traffic-armer Zeit ausrollen, zuerst ein frisches Produktions-Backup ziehen, exakt dieselbe getestete ZIP hochladen, dieselbe Konfiguration setzen, eine verkürzte Checkliste durchgehen und danach ein bis zwei Tage Fehlerprotokolle und Conversion beobachten.

Häufige Fallstricke

ps_shop_url / PS_SHOP_DOMAIN nicht aktualisiert — Staging leitet dann zur Produktion.
Zahlungsgateways im Live-Modus — auf Sandbox umstellen.
E-Mails an echte Kunden — Versand deaktivieren oder auf ein Test-Postfach umleiten.
Staging von Suchmaschinen indexiert — blockieren.
Von der Produktion kopierte Cron-Jobs — alle deaktivieren, die E-Mails senden oder externe Dienste ansprechen.

Zur Diagnose entdeckter Probleme hilft unser PrestaShop-Fehlersuche-Leitfaden.

Nein. Instant Redis installiert den Redis-Server nicht. Redis muss auf Ihrem Hosting bereits existieren - von Ihrem Provider, VPS, Docker-Stack oder einem Managed-Cache-Service - und die PHP-Extension redis muss geladen sein. Wenn die Extension fehlt, sagt das Modul es Ihnen, und das Dashboard zeigt eine Warnung, statt still zu scheitern.

Was es tut: Es verbindet PrestaShop mit diesem vorhandenen Redis und lässt Sie es aus dem Back Office verwalten. Sie setzen Host, Port, Passwort, Datenbanknummer und einen Key Prefix, nützlich wenn mehrere Shops eine Redis-Instanz teilen, und aktivieren dann Redis-basierten Object Cache und Session Storage, sehen Live Monitoring und browsen Keys - ohne Konfigurationsdateien per SSH anzufassen.

Die Standard-Verbindungswerte sind bewusst konservativ:

REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_DB=0
REDIS_PREFIX=ps_

Das Modul testet die Verbindung mit konfiguriertem Host, Port, optionalem Passwort und ausgewählter Datenbank und liest dann Redis-Serverinfo wie Version, Uptime, Memory Usage, Connected Clients und Total Key Count. Schalter für Object Cache, Session Cache und Full-page Cache sind vorhanden, aber standardmäßig aus. Die Installation verschiebt also nicht plötzlich jede Cache-Schicht, bis Sie es aktiv entscheiden.

Der Key Prefix ist wichtig, wenn mehrere Shops einen Redis-Server teilen. Key Browser und Prefix Flush Tools arbeiten innerhalb dieses Prefix, und der Prefix Flush kehrt absichtlich zurück, ohne etwas zu löschen, wenn der Prefix leer ist. Ein normales Speichern der Konfiguration kann außerdem den konfigurierten Prefix leeren, wenn Flush on save aktiviert ist, was hilft, veraltete Cachedaten nach Änderungen an Verbindung oder Cache-Einstellungen zu vermeiden.

Die ehrliche Trennung: Ihr Hoster oder Sie stellen den Redis-Dienst bereit; Instant Redis übernimmt die PrestaShop-Seite sicher aus dem Admin. Ein häufiger Fehler ist, es zu kaufen und eine One-Click-Redis-Installation zu erwarten - bestätigen Sie zuerst, dass Redis und die PHP-Extension verfügbar sind, dann verwaltet dieses Modul den Rest.

Installation & Einrichtung

Installation & Einrichtung

Fragen

Linux-Dateiberechtigungen verstehen

Korrekte Berechtigungen für PrestaShop-Verzeichnisse und -Dateien

Korrekten Eigentümer mit chown festlegen

Shared Hosting vs. VPS vs. Dedizierter Server

Shared Hosting

VPS (Virtual Private Server)

Dedizierter Server

PHP-Ausführungsmodelle: suPHP vs. mod_php vs. PHP-FPM

mod_php (Apache-Modul)

suPHP

PHP-FPM (FastCGI Process Manager)

Warum 777-Berechtigungen gefährlich sind

Docker-Besonderheiten für PrestaShop

Fehlerbehebung häufiger 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" während Updates

Weiße Seite nach Änderung der Berechtigungen

Berechtigungen werden nach FTP-Upload zurückgesetzt

Sicherheits-Best-Practices über Berechtigungen hinaus

Warum Staging wichtig ist

Option 1 — Subdomain-Staging (auf jedem Host)

Option 2 — Docker-Staging (am nächsten an der Produktion)

Testcheckliste für ein neues Modul

In die Produktion überführen

Häufige Fallstricke

Andere Kategorien

Noch Fragen?

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)