Social Revolution

OPcache ist eine PHP-Erweiterung, die kompilierten PHP-Code im Arbeitsspeicher zwischenspeichert, sodass PHP ihn nicht bei jeder Anfrage neu kompilieren muss. Sie sollten es unbedingt aktivieren — es kann die PrestaShop-Performance um 30-50% verbessern, ohne Nachteile für die Produktion. Die meisten Hosting-Anbieter haben es standardmäßig aktiviert. Die wichtige Einstellung ist opcache.validate_timestamps: Auf 1 setzen in der Entwicklung, aber viele Produktionsserver setzen es auf 0 für maximale Performance (was bedeutet, dass Sie OPcache nach Code-Änderungen manuell zurücksetzen müssen).

See our full guide on PHP optimization

Wie PrestaShop E-Mail-Vorlagen funktionieren

PrestaShop versendet transaktionale E-Mails an jedem wichtigen Punkt der Customer Journey: Kontoerstellung, Bestellbestätigung, Versandbenachrichtigung, Passwort-Zurücksetzung und mehr. Diese E-Mails werden aus Vorlagendateien generiert, die auf Ihrem Server gespeichert sind und vollständig anpassbar sind. Das Verständnis der Funktionsweise des Vorlagensystems ist der erste Schritt zur Erstellung professioneller, markengerechter Bestellbestätigungs-E-Mails, die die Identität Ihres Shops stärken.

Jede PrestaShop-E-Mail besteht aus zwei Vorlagendateien: einer HTML-Version für E-Mail-Clients, die Rich-Formatierung unterstützen, und einer Klartext-Version (TXT) für E-Mail-Clients, die dies nicht tun. Beide Dateien müssen vorhanden sein, damit eine E-Mail korrekt versendet wird. Die HTML-Version ist das, was die überwiegende Mehrheit Ihrer Kunden sehen wird. Die TXT-Version dient als Fallback und wird auch von Barrierefreiheits-Tools und einigen Unternehmens-E-Mail-Filtern verwendet.

E-Mail-Vorlagen befinden sich in der mails/-Verzeichnisstruktur. Der genaue Speicherort hängt davon ab, ob Sie Core-E-Mails, vom Theme überschriebene E-Mails oder modulspezifische E-Mails verwenden. Das Verständnis dieser Hierarchie ist entscheidend, da PrestaShop mehrere Speicherorte für jede Vorlage überprüft und die erste gefundene verwendet.

Die Verzeichnisstruktur der E-Mail-Vorlagen

PrestaShop organisiert E-Mail-Vorlagen in einer bestimmten Verzeichnishierarchie. Wenn eine E-Mail versendet werden muss, durchsucht das System diese Speicherorte in der Reihenfolge ihrer Priorität:

Theme-Level-Überschreibungen (Höchste Priorität)

Vorlagen in /themes/ihr-theme/mails/de/ (wobei de der Sprach-ISO-Code ist) haben Vorrang vor allen anderen Speicherorten. Wenn Sie eine E-Mail-Vorlage anpassen möchten, ohne Core-Dateien zu ändern, sollten Ihre benutzerdefinierten Vorlagen hier abgelegt werden. Dieser Ansatz überlebt PrestaShop-Updates, da Theme-Dateien bei Core-Updates nicht überschrieben werden.

Core-Vorlagen (Standard)

Die Standardvorlagen befinden sich in /mails/de/ in Ihrem PrestaShop-Stammverzeichnis. Dies sind die Vorlagen, die mit PrestaShop ausgeliefert werden und verwendet werden, wenn keine Theme-Überschreibung existiert. Das direkte Bearbeiten dieser Dateien funktioniert, wird aber nicht empfohlen, da Ihre Änderungen bei einem PrestaShop-Update verloren gehen.

Modulspezifische Vorlagen

Module, die eigene E-Mails versenden, speichern Vorlagen in /modules/modulname/mails/de/. Beispielsweise werden die Bestellbenachrichtigungs-E-Mails der Core-Zahlungsmodule in ihren jeweiligen Modulverzeichnissen gespeichert. Sie können diese überschreiben, indem Sie modifizierte Kopien im mails/-Verzeichnis Ihres Themes mit demselben Dateinamen ablegen.

Sprachunterverzeichnisse

Jedes mails/-Verzeichnis enthält Unterverzeichnisse für jede installierte Sprache unter Verwendung des Sprach-ISO-Codes: en für Englisch, fr für Französisch, de für Deutsch und so weiter. Wenn PrestaShop eine E-Mail versendet, verwendet es die Vorlage aus dem Verzeichnis, das der Sprachpräferenz des Kunden entspricht. Falls eine Vorlage in der Sprache des Kunden nicht existiert, greift PrestaShop auf die Standardsprache zurück.

Aufbau einer Bestellbestätigungs-Vorlage

Die Bestellbestätigungs-E-Mail ist die wichtigste transaktionale E-Mail, die Ihr Shop versendet. Es handelt sich um die Datei order_conf.html (und deren Begleitdatei order_conf.txt) in Ihrem Mails-Verzeichnis. Lassen Sie uns ihre Struktur im Detail betrachten.

HTML-Vorlagenstruktur

PrestaShop E-Mail-Vorlagen sind eigenständige HTML-Dokumente. Sie verwenden keine externen CSS-Dateien, da die meisten E-Mail-Clients externe Stylesheets entfernen. Sämtliches Styling muss als Inline-CSS erfolgen. Eine typische Bestellbestätigungs-Vorlage umfasst folgende Abschnitte:

Das Dokument beginnt mit einem Standard-HTML-Doctype und Head-Bereich. Der Body enthält ein tabellenbasiertes Layout (da E-Mail-Clients nur mangelhafte Unterstützung für moderne CSS-Layoutmethoden wie Flexbox und Grid bieten). Innerhalb dieses Layouts finden Sie einen Header-Bereich mit Ihrem Shop-Logo, den Hauptinhaltsbereich mit Bestelldetails, eine Produkttabelle mit jedem bestellten Artikel, eine Preisübersicht mit Zwischensummen und Gesamtbeträgen, Versandinformationen, Zahlungsmethodendetails und einen Footer mit Shop-Kontaktinformationen und rechtlichen Hinweisen.

Das Variablensystem

PrestaShop verwendet ein einfaches Variablen-Ersetzungssystem in E-Mail-Vorlagen. Variablen werden in geschweifte Klammern eingeschlossen: {variablenname}. Wenn die E-Mail generiert wird, ersetzt PrestaShop jede Variable durch ihren tatsächlichen Wert. Die Bestellbestätigungs-Vorlage verwendet diese wichtigen Variablen:

{firstname} und {lastname} enthalten den Namen des Kunden. {order_name} ist die Bestellreferenznummer (wie ABCDEF123). {shop_name} ist der Name Ihres Shops, wie er im Back-Office konfiguriert ist. {shop_url} ist die URL Ihres Shops. {shop_logo} ist der Pfad zum Logo-Bild Ihres Shops. {date} ist das Bestelldatum. {payment} ist die verwendete Zahlungsmethode. {total_paid} ist der insgesamt gezahlte Betrag. {delivery_company} und {delivery_address} enthalten Informationen zum Versanddienstleister und zur Lieferadresse.

Für die Produktliste verwendet PrestaShop eine spezielle Block-Syntax. Der Bereich mit den Produktartikeln ist in eine Schleife eingebettet, die sich für jedes Produkt in der Bestellung wiederholt: {items} enthält das vorformatierte HTML für die gesamte Produktlistentabelle, einschließlich Produktnamen, Mengen, Preisen und eventuellen Individualisierungsdetails.

Verfügbare Variablen — Referenz

Um alle verfügbaren Variablen für eine bestimmte E-Mail-Vorlage zu sehen, schauen Sie sich den PHP-Code an, der die E-Mail versendet. Für die Bestellbestätigung prüfen Sie die Klasse PaymentModule (in /classes/PaymentModule.php). Die Methode validateOrder() erstellt das Array der Vorlagenvariablen. Jeder Schlüssel im Array entspricht einem Variablennamen, den Sie in der Vorlage verwenden können.

Häufig verfügbare Variablen in Bestellbestätigungs-E-Mails umfassen: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} und {total_products}.

Die Bestellbestätigungs-Vorlage anpassen

Schritt 1: Eine Theme-Überschreibung erstellen

Bearbeiten Sie niemals die Core-Vorlagendateien direkt. Kopieren Sie stattdessen die Vorlage in das Mails-Verzeichnis Ihres Themes:

Kopieren Sie /mails/de/order_conf.html nach /themes/ihr-theme/mails/de/order_conf.html. Machen Sie dasselbe für order_conf.txt. Falls das Verzeichnis mails/de/ in Ihrem Theme nicht existiert, erstellen Sie es.

Wenn Ihr Shop mehrere Sprachen unterstützt, kopieren Sie die Vorlagen für jedes Sprachverzeichnis. Ihre französische Bestellbestätigung gehört in /themes/ihr-theme/mails/fr/order_conf.html und so weiter.

Schritt 2: Das HTML-Layout anpassen

Öffnen Sie die HTML-Vorlage in einem Texteditor (nicht in einem visuellen Editor, der unerwünschten Code hinzufügen könnte). E-Mail-HTML unterscheidet sich in mehreren wichtigen Punkten von Web-HTML:

Verwenden Sie Tabellen für das Layout, keine Divs. E-Mail-Clients, insbesondere Outlook, haben eine sehr eingeschränkte CSS-Unterstützung. Ein dreispaltiges Layout muss eine <table> mit drei <td>-Elementen verwenden, nicht CSS-Columns oder Flexbox.

Verwenden Sie Inline-Styles bei jedem Element. Anstatt <p class="heading"> mit einem separaten Stylesheet zu verwenden, nutzen Sie <p style="font-size:18px; font-weight:bold; color:#333333;">. Jedes gestylte Element benötigt sein eigenes Inline-Style-Attribut.

Setzen Sie explizite Breiten für Tabellen und Zellen. E-Mail-Clients respektieren nicht immer prozentbasierte Breiten. Verwenden Sie eine feste Breite für Ihre Hauptinhaltstabelle (600 Pixel ist der Standard) mit prozentbasierten internen Spalten.

Verwenden Sie websichere Schriftarten. Nicht alle E-Mail-Clients unterstützen benutzerdefinierte Schriftarten. Bleiben Sie bei Arial, Helvetica, Georgia, Times New Roman, Verdana oder Trebuchet MS. Sie können versuchen, eine benutzerdefinierte Schriftart als Fallback zu laden, aber geben Sie immer eine websichere Schriftart als endgültigen Fallback an.

Schritt 3: Ihr Branding hinzufügen

Ersetzen Sie den Standard-PrestaShop-Header durch das Branding Ihres Shops. Dies umfasst typischerweise das Aktualisieren des Logos (die Variable {shop_logo} verwendet automatisch das Logo Ihres Shops, aber Sie möchten möglicherweise eine spezielle E-Mail-Version), das Ändern der Header-Hintergrundfarbe passend zu Ihrer Marke, das Hinzufügen des Farbschemas Ihrer Marke zu Überschriften und Links sowie das Einfügen des Slogans Ihres Shops oder einer kurzen Marketingbotschaft.

Halten Sie die Gesamtstruktur einfach. Übermäßig komplexe E-Mail-Designs brechen in verschiedenen E-Mail-Clients auseinander. Ein sauberes, einspaltiges Layout mit Ihren Markenfarben und Ihrem Logo ist effektiver und zuverlässiger als ein aufwendiges mehrspaltiges Design.

Schritt 4: Die Produkttabelle anpassen

Die Standard-Produkttabelle in der PrestaShop-Bestellbestätigung ist funktional, aber grundlegend. Sie können sie verbessern, indem Sie Produktbilder hinzufügen (verwenden Sie absolute URLs zu Bildern, die auf Ihrem Server gehostet werden, keine relativen Pfade), Links zu Produktseiten einfügen, damit Kunden leicht nachbestellen oder Bewertungen hinterlassen können, benutzerdefinierte Felder wie voraussichtliche Liefertermine oder personalisierte Nachrichten hinzufügen und das Tabellen-Styling an Ihre Marke anpassen.

Wenn Sie Produktbilder hinzufügen, halten Sie diese klein (50 bis 80 Pixel breit) und fügen Sie immer ein alt-Attribut hinzu. Einige E-Mail-Clients blockieren Bilder standardmäßig, und der Alt-Text stellt sicher, dass Kunden ihre Produkte trotzdem identifizieren können.

Benutzerdefinierte Felder zu Bestell-E-Mails hinzufügen

Die Standardvariablen von PrestaShop decken die üblichen Bestellinformationen ab, aber Sie möchten möglicherweise zusätzliche Daten einbeziehen, wie verdiente Treuepunkte, voraussichtliches Lieferdatum, eine personalisierte Dankesnachricht oder Cross-Selling-Produktempfehlungen.

Variablen über ein Modul hinzufügen

Der sauberste Weg, benutzerdefinierte Variablen hinzuzufügen, ist über ein Modul, das sich in den E-Mail-Versandprozess einklinkt. Erstellen Sie ein Modul, das den Hook actionEmailSendBefore (verfügbar ab PrestaShop 1.7.6) oder den Hook actionGetExtraMailTemplateVars registriert. In Ihrem Hook-Handler fügen Sie Ihre benutzerdefinierten Variablen zum Vorlagenvariablen-Array hinzu:

Ihre Hook-Funktion erhält das Vorlagenvariablen-Array per Referenz. Sie können neue Variablen zu diesem Array hinzufügen, und sie werden in der Vorlage über die Standard-Syntax {variablenname} verfügbar. Nachdem Sie beispielsweise loyalty_points zum Array in Ihrem Hook hinzugefügt haben, können Sie {loyalty_points} in Ihrer Bestellbestätigungs-HTML-Vorlage verwenden.

Vorhandene Datenbankdaten verwenden

Sie können beliebige Daten aus Ihrer PrestaShop-Datenbank in E-Mail-Variablen einbinden. Gängige Beispiele umfassen die Gesamtanzahl der Bestellungen des Kunden (um "Vielen Dank für Ihre 5. Bestellung!" anzuzeigen), das Treuepunkte-Guthaben des Kunden, benutzerdefinierte Produktfelder, die in Produkteigenschaften oder -attributen gespeichert sind, sowie Lager- oder Lieferanteninformationen für die bestellten Produkte.

Mehrsprachige E-Mail-Einrichtung

Wenn Ihr Shop Kunden in mehreren Sprachen bedient, benötigt jede E-Mail-Vorlage eine Version für jede Sprache. PrestaShop übernimmt die Sprachauswahl automatisch basierend auf der Sprachpräferenz des Kunden, aber Sie müssen die Vorlagen bereitstellen.

Sprachspezifische Vorlagen erstellen

Erstellen Sie für jede Sprache, die Ihr Shop unterstützt, ein Verzeichnis im Mails-Ordner Ihres Themes: /themes/ihr-theme/mails/en/, /themes/ihr-theme/mails/fr/, /themes/ihr-theme/mails/de/ und so weiter. Kopieren und übersetzen Sie jede Vorlagendatei in das entsprechende Verzeichnis.

Verwenden Sie keine automatische Übersetzung für transaktionale E-Mails. Diese E-Mails repräsentieren die Kommunikation Ihres Shops mit den Kunden, und schlechte Übersetzungen schädigen das Vertrauen. Lassen Sie jede Sprachversion von einem Muttersprachler verfassen oder überprüfen.

Unterstützung für Rechts-nach-Links-Sprachen

Wenn Sie Sprachen wie Arabisch oder Hebräisch unterstützen, benötigen Ihre E-Mail-Vorlagen RTL-Layout-Unterstützung (Rechts-nach-Links). Fügen Sie dir="rtl" zum Haupttabellenelement hinzu und passen Sie die Textausrichtung und den Abstand in Ihren Inline-Styles an. Erstellen Sie separate Vorlagen für RTL-Sprachen, anstatt zu versuchen, eine einzelne Vorlage für beide Richtungen zum Funktionieren zu bringen.

Datums- und Währungsformatierung

PrestaShop formatiert Datums- und Währungswerte automatisch entsprechend den Sprach- und Währungseinstellungen des Kunden. Die Werte {date}, {total_paid} und andere formatierte Werte spiegeln bereits das korrekte Gebietsschema wider. Wenn Sie jedoch benutzerdefinierte Variablen mit Datums- oder Währungswerten hinzufügen, stellen Sie sicher, dass diese für die Zielsprache korrekt formatiert sind.

SMTP-Konfiguration für zuverlässige Zustellung

Die beste E-Mail-Vorlage der Welt ist nutzlos, wenn Ihre E-Mails nicht im Posteingang ankommen. Die Standard-E-Mail-Konfiguration von PrestaShop verwendet die in PHP integrierte mail()-Funktion, die für transaktionale E-Mails unzuverlässig ist. Die meisten dieser E-Mails landen im Spam-Ordner oder werden von modernen E-Mail-Anbietern vollständig abgelehnt.

Warum SMTP wichtig ist

SMTP (Simple Mail Transfer Protocol) mit korrekter Authentifizierung ist essenziell für die E-Mail-Zustellbarkeit. Wenn Sie E-Mails über die PHP-Funktion mail() versenden, kommt die E-Mail von der IP-Adresse Ihres Webservers ohne jegliche Authentifizierung. E-Mail-Anbieter wie Gmail, Outlook und Yahoo sehen dies als Warnsignal und klassifizieren diese E-Mails häufig als Spam.

Mit SMTP werden Ihre E-Mails über einen authentifizierten E-Mail-Server mit korrekten SPF-, DKIM- und DMARC-Einträgen versendet. Dies beweist den empfangenden E-Mail-Servern, dass die E-Mail legitim und von Ihrer Domain autorisiert ist.

SMTP in PrestaShop konfigurieren

Gehen Sie zu Erweiterte Einstellungen > E-Mail in Ihrem PrestaShop Back-Office. Ändern Sie die Methode von "PHPs mail()-Funktion verwenden" auf "Eigene SMTP-Parameter festlegen". Geben Sie Ihre SMTP-Serverdaten ein: die Serveradresse, den Port (typischerweise 587 für TLS oder 465 für SSL), den Verschlüsselungstyp, den Benutzernamen und das Passwort.

Gängige SMTP-Anbieter für PrestaShop umfassen Gmail SMTP (smtp.gmail.com, Port 587, TLS, erfordert ein App-Passwort bei aktivierter 2FA), Amazon SES (preiswert für hohe Volumina), SendGrid (großzügiges kostenloses Kontingent), Mailgun (entwicklerfreundlich mit guter Protokollierung) und den SMTP-Server Ihres Hosting-Anbieters (erkundigen Sie sich bei Ihrem Hoster nach den Einstellungen).

SMTP-Konfiguration testen

Verwenden Sie nach der SMTP-Konfiguration die Schaltfläche "Test-E-Mail senden" am unteren Rand der E-Mail-Konfigurationsseite. Geben Sie Ihre eigene E-Mail-Adresse ein und überprüfen Sie, ob die Test-E-Mail in Ihrem Posteingang ankommt (nicht im Spam). Wenn die Test-E-Mail fehlschlägt, überprüfen Sie Ihre SMTP-Zugangsdaten, stellen Sie sicher, dass Ihr Server den SMTP-Server auf dem konfigurierten Port erreichen kann (einige Hosting-Anbieter blockieren den ausgehenden Port 25 und 587) und prüfen Sie, ob Ihr SMTP-Anbieter bestimmte Sicherheitseinstellungen erfordert.

SPF-, DKIM- und DMARC-Einträge

Konfigurieren Sie für maximale Zustellbarkeit diese DNS-Einträge für Ihre Domain. SPF (Sender Policy Framework) legt fest, welche Server berechtigt sind, E-Mails im Namen Ihrer Domain zu versenden. DKIM (DomainKeys Identified Mail) fügt Ihren E-Mails eine digitale Signatur hinzu, die beweist, dass sie von Ihrer Domain gesendet wurden. DMARC (Domain-based Message Authentication, Reporting, and Conformance) teilt empfangenden Servern mit, was mit E-Mails geschehen soll, die die SPF- oder DKIM-Prüfungen nicht bestehen.

Ihr SMTP-Anbieter stellt Ihnen die spezifischen DNS-Einträge zur Verfügung, die hinzugefügt werden müssen. Wenn Sie beispielsweise SendGrid verwenden, erhalten Sie SPF- und DKIM-Einträge während des Domain-Authentifizierungsprozesses. Fügen Sie diese als TXT-Einträge in den DNS-Einstellungen Ihrer Domain hinzu.

E-Mail-Vorlagen testen

Test-E-Mails versenden

PrestaShop bietet keine integrierte Möglichkeit zur Vorschau bestimmter E-Mail-Vorlagen. Um Ihre Bestellbestätigungs-Vorlage zu testen, müssen Sie eine echte Testbestellung aufgeben. Erstellen Sie ein Testkundenkonto, legen Sie Produkte in den Warenkorb und schließen Sie den Bestellvorgang mit einer Testzahlungsmethode ab. Wenn Sie ein Sandbox-Zahlungsmodul konfiguriert haben, verwenden Sie dieses. Andernfalls ermöglichen die Banküberweisung oder Scheck-Zahlungsmethoden das Abschließen einer Bestellung ohne tatsächliche Zahlungsabwicklung.

Tests über verschiedene E-Mail-Clients hinweg

Die E-Mail-Darstellung variiert dramatisch zwischen verschiedenen E-Mail-Clients. Was in Gmail perfekt aussieht, kann in Outlook fehlerhaft sein. Testen Sie Ihre Vorlagen mindestens in Gmail (Web), Outlook (Desktop und Web), Apple Mail, Yahoo Mail und mindestens einer mobilen E-Mail-App. Dienste wie Litmus oder Email on Acid automatisieren dieses Testen, indem sie Ihre E-Mail in Dutzenden von E-Mail-Clients gleichzeitig rendern, aber es handelt sich um kostenpflichtige Dienste.

Häufige Darstellungsprobleme

Wenn Ihre E-Mail in Outlook fehlerhaft aussieht, handelt es sich fast sicher um ein CSS-Problem. Outlook verwendet die Rendering-Engine von Microsoft Word für HTML-E-Mails, die eine äußerst eingeschränkte CSS-Unterstützung bietet. Es unterstützt keine Hintergrundbilder auf Tabellenzellen (verwenden Sie stattdessen Hintergrundfarben), kein Padding auf Blockelementen (verwenden Sie Tabellenzellen-Padding), kein max-width (verwenden Sie feste Breiten), kein Margin zum Zentrieren (verwenden Sie align="center" auf Tabellen) und keine CSS-Floats.

Für mobile Responsivität umhüllen Sie Ihre Inhaltstabelle mit einem Container mit max-width:600px und fügen Sie eine Media Query im Head-Style-Block hinzu (die einige E-Mail-Clients unterstützen), die Tabellenbreiten auf 100% auf kleinen Bildschirmen setzt. Dies ist kein perfektes responsives Design, verhindert aber horizontales Scrollen auf den meisten mobilen Geräten.

Häufige Probleme und Fehlerbehebung

Fehlende Bilder in E-Mails

Dies ist das häufigste E-Mail-Vorlagenproblem. Bilder in E-Mails müssen absolute URLs verwenden (beginnend mit https://), keine relativen Pfade. Wenn Ihre Vorlage auf /img/logo.png verweist, ändern Sie dies zu https://www.ihredomain.com/img/logo.png. Die Variable {shop_logo} generiert automatisch eine absolute URL, aber alle Bilder, die Sie manuell hinzufügen, müssen vollständige URLs verwenden.

Überprüfen Sie außerdem, dass Ihre Bilder von außerhalb Ihres Netzwerks zugänglich sind. Wenn Ihr Shop hinter einer Firewall oder HTTP-Authentifizierung steht, können E-Mail-Clients die Bilder nicht laden. Testen Sie, indem Sie die Bild-URL in einem privaten/Inkognito-Browserfenster öffnen.

Fehlerhaftes Layout nach der Bearbeitung

E-Mail-HTML ist fragil. Ein einzelnes nicht geschlossenes Tag oder eine fehlende Tabellenzelle kann das gesamte Layout zerstören. Validieren Sie immer Ihr HTML nach der Bearbeitung. Zählen Sie Ihre öffnenden und schließenden table-, tr- und td-Tags. Jedes <table> benötigt ein </table>, jedes <tr> benötigt ein </tr> und jedes <td> benötigt ein </td>. Stellen Sie sicher, dass jede Zeile in einer Tabelle die gleiche Anzahl an Zellen hat (oder colspan verwendet, um die Differenz auszugleichen).

Variablen werden nicht ersetzt

Wenn Sie in Ihren gesendeten E-Mails den buchstäblichen Text {variablenname} anstelle der tatsächlichen Werte sehen, überprüfen Sie den Variablennamen auf Tippfehler. Variablennamen unterscheiden zwischen Groß- und Kleinschreibung. Stellen Sie außerdem sicher, dass die Variable für den spezifischen E-Mail-Typ existiert, den Sie anpassen. Nicht alle Variablen sind in allen E-Mail-Vorlagen verfügbar. Die bestellspezifischen Variablen wie {order_name} sind nur in bestellbezogenen E-Mails verfügbar.

E-Mails werden gar nicht versendet

Wenn keine E-Mails versendet werden, überprüfen Sie das PrestaShop Back-Office unter Erweiterte Einstellungen > E-Mail. Dort können Sie ein Protokoll der gesendeten E-Mails einsehen. Wenn das Protokoll Fehler zeigt, überprüfen Sie Ihre SMTP-Konfiguration. Wenn keine E-Mails im Protokoll erscheinen, wird die E-Mail möglicherweise gar nicht ausgelöst. Überprüfen Sie, ob Ihre Bestellstatusübergänge so konfiguriert sind, dass sie E-Mails an den Kunden senden (Bestellungen > Status > Status bearbeiten > "E-Mail an den Kunden senden" aktivieren).

Überprüfen Sie auch das PHP-Fehlerprotokoll Ihres Servers auf E-Mail-bezogene Fehler. Häufige Probleme sind: Die PHP-Funktion mail() wurde vom Hosting-Anbieter deaktiviert, SMTP-Authentifizierungsfehler aufgrund geänderter Passwörter und Netzwerkverbindungsprobleme zwischen Ihrem Server und dem SMTP-Server.

E-Mails landen im Spam

Selbst mit korrekter SMTP-Konfiguration können E-Mails immer noch im Spam landen. Die häufigsten Gründe sind fehlende oder fehlerhafte SPF/DKIM/DMARC-Einträge, E-Mail-Inhalte, die Spam-Filter auslösen (übermäßige Verwendung von Großbuchstaben, Spam-Triggerwörter wie "kostenlos" oder "jetzt handeln", zu viele Bilder mit wenig Text), Versand von einer IP-Adresse mit schlechtem Ruf (häufig bei Shared Hosting) und eine Absender-E-Mail-Adresse, deren Domain nicht mit der SMTP-Server-Domain übereinstimmt.

Beheben Sie zuerst die DNS-Einträge und überprüfen Sie dann Ihren E-Mail-Inhalt. Verwenden Sie ein Tool wie mail-tester.com, um Ihre E-Mails auf Spam-Auslöser zu analysieren. Senden Sie eine Test-E-Mail an die dort bereitgestellte Adresse, und Sie erhalten einen detaillierten Bericht, der zeigt, was eine Spam-Klassifizierung verursachen könnte.

Theme-spezifische E-Mail-Überschreibungen

Einige PrestaShop-Themes enthalten eigene E-Mail-Vorlagen, die zum Design des Themes passen. Wenn Ihr Theme Vorlagen in /themes/ihr-theme/mails/ hat, überschreiben diese automatisch die Core-Vorlagen.

Auf Theme-E-Mail-Vorlagen prüfen

Schauen Sie im Verzeichnis Ihres aktiven Themes nach einem mails-Ordner. Wenn dieser existiert, bietet das Theme benutzerdefinierte E-Mail-Vorlagen. Diese Vorlagen passen normalerweise zum Farbschema und Header-/Footer-Design des Themes und verleihen Ihren E-Mails visuelle Konsistenz mit Ihrem Storefront.

Theme-E-Mail-Vorlagen anpassen

Wenn Ihr Theme E-Mail-Vorlagen bereitstellt, bearbeiten Sie diese, anstatt sie aus dem Core-Verzeichnis mails/ zu kopieren. Die Theme-Vorlagen können eine andere HTML-Struktur verwenden oder zusätzliches CSS enthalten, das spezifisch für das Designsystem des Themes ist. Wenn Sie von der Theme-Version ausgehen, stellen Sie visuelle Konsistenz sicher.

Vorlagen bei Theme-Updates synchron halten

Wenn Sie Ihr Theme aktualisieren, überprüfen Sie, ob das Update Änderungen an den E-Mail-Vorlagen enthält. Falls ja, könnten Ihre Anpassungen überschrieben werden. Sichern Sie vor dem Update Ihre angepassten Vorlagen. Vergleichen Sie nach dem Update die neuen Vorlagen mit Ihren Sicherungen und wenden Sie Ihre Anpassungen auf die aktualisierten Versionen erneut an. Dies ist mühsam, aber notwendig, um sowohl Ihre Anpassungen als auch eventuelle Verbesserungen oder Korrekturen des Theme-Entwicklers beizubehalten.

Best Practices für Bestellbestätigungs-E-Mails

Eine gut gestaltete Bestellbestätigungs-E-Mail tut mehr, als nur die Transaktion zu bestätigen. Sie baut Vertrauen auf, reduziert Support-Anfragen und schafft Möglichkeiten zur Kundenbindung.

Platzieren Sie eine deutlich sichtbare Bestellreferenznummer prominent am Anfang. Kunden benötigen diese Nummer, wenn sie den Support kontaktieren oder ihre Bestellung verfolgen. Listen Sie jedes Produkt mit Name, Menge, Preis und allen Optionen oder Individualisierungen auf. Fügen Sie die vollständige Aufschlüsselung von Zwischensumme, Versandkosten, Steuern, Rabatten und Gesamtbetrag ein. Zeigen Sie die Lieferadresse an, damit Kunden sie überprüfen und Sie sofort kontaktieren können, falls sie falsch ist. Geben Sie die verwendete Zahlungsmethode und alle relevanten Transaktionsdetails an. Stellen Sie einen Link zur Sendungsverfolgungsseite oder zur Bestellhistorie des Kunden in dessen Konto bereit. Fügen Sie Ihre Kundenservice-Kontaktdaten hinzu, damit Kunden wissen, wie sie Sie bei Problemen erreichen können.

Halten Sie das Design sauber und mobilfreundlich. Mehr als die Hälfte aller E-Mails wird auf mobilen Geräten gelesen. Verwenden Sie ein einspaltiges Layout, große lesbare Schrift (mindestens 14px für Fließtext) und Schaltflächen mit ausreichend großen Berührungszielen (mindestens 44px Höhe). Ihre Bestellbestätigungs-E-Mail ist ein Spiegelbild der Professionalität Ihres Shops. Investieren Sie die Zeit, um sie richtig zu gestalten.

Warum regelmaessige technische Audits wichtig sind

PrestaShop-Shops verschlechtern sich mit der Zeit. Module werden installiert und vergessen. PHP-Versionen fallen zurueck. Fehlerprotokolle fuellen sich mit Warnungen, die niemand liest. Datenbanktabellen blaehen sich auf mit Daten aus abgebrochenen Warenkoerben und abgelaufenen Sitzungen. Sicherheitspatches werden nicht angewendet. Jedes dieser Probleme ist fuer sich genommen klein, aber zusammen fuehren sie zu langsamen Seitenladezeiten, Sicherheitsluecken und letztlich zu Ausfallzeiten oder Datenverlust.

Das Problem ist, dass die meisten Shopbetreiber diese Probleme erst entdecken, wenn etwas kaputtgeht. Ein Kunde beschwert sich ueber einen langsamen Checkout. Google stuft Ihre Rankings herab, weil Ihre Website die Core Web Vitals nicht besteht. Oder schlimmer noch: Sie entdecken, dass Ihr Admin-Panel kompromittiert wurde, weil Sie nie den Standard-Admin-Pfad geaendert haben und Ihre PHP-Version eine bekannte Sicherheitsluecke hatte.

Ein 30-minuetiges technisches Gesundheits-Audit, monatlich durchgefuehrt, verhindert all dies. Es ist kein tiefer Tauchgang in jede Konfigurationseinstellung. Es ist eine fokussierte Checkliste, die die haeufigsten und gefaehrlichsten Probleme erkennt, bevor sie zu Notfaellen werden. Dieser Leitfaden fuehrt durch jede Pruefung mit ungefaehren Zeitschaetzungen und gibt Ihnen einen wiederholbaren Prozess, dem Sie jeden Monat folgen koennen.

Pruefung 1: PHP-Version und Konfiguration (3 Minuten)

PHP ist der Motor, der PrestaShop antreibt, und eine veraltete Version zu verwenden ist sowohl ein Leistungs- als auch ein Sicherheitsrisiko. PHP-Versionen erhalten zwei Jahre aktiven Support und ein weiteres Jahr Sicherheitsupdates. Danach bleiben bekannte Sicherheitsluecken ungepatcht.

PHP-Version pruefen

Gehen Sie in Ihr PrestaShop Back Office und navigieren Sie zu Erweiterte Einstellungen > Informationen. Die PHP-Version ist im Abschnitt Server-Informationen aufgefuehrt. Alternativ koennen Sie sie in Ihrem Hosting-Kontrollpanel (cPanel, Plesk oder aehnlich) pruefen.

Stand 2026 sind die aktiv unterstuetzten PHP-Versionen 8.2, 8.3 und 8.4. Wenn Sie PHP 8.1 oder aelter verwenden, sollte ein Upgrade Prioritaet haben. PrestaShop 8.x erfordert PHP 7.2 oder hoeher, performt aber deutlich besser mit PHP 8.1 und hoeher. PrestaShop 1.7.x unterstuetzt PHP 7.1 bis 8.1, abhaengig von der spezifischen Version.

Wichtige PHP-Einstellungen ueberpruefen

Pruefen Sie auf der Informationsseite diese PHP-Konfigurationswerte:

memory_limit sollte mindestens 256M fuer PrestaShop betragen. Wenn es niedriger ist, koennen bei der Verarbeitung grosser Kataloge oder der Erstellung von Berichten weisse Seiten oder unvollstaendige Operationen auftreten.

max_execution_time sollte mindestens 300 (5 Minuten) betragen. Niedrigere Werte koennen Timeouts bei Importvorgaengen, Cache-Neuaufbauten und Modulinstallationen verursachen.

upload_max_filesize und post_max_size sollten mindestens 16M betragen, oder hoeher, wenn Sie regelmaessig grosse Produktbilder oder Importdateien hochladen.

OPcache sollte aktiviert sein. OPcache speichert kompilierten PHP-Code im Arbeitsspeicher und reduziert die Seitenladezeiten dramatisch. Wenn es deaktiviert ist, laeuft Ihr Shop deutlich langsamer als er koennte.

Pruefung 2: Fehlerprotokoll-Ueberpruefung (4 Minuten)

Fehlerprotokolle zeigen Ihnen, was hinter den Kulissen kaputtgeht, selbst wenn das Frontend normal zu funktionieren scheint. Warnungen und Hinweise, die die Seite nicht zum Absturz bringen, deuten dennoch auf Probleme hin, die Serverressourcen verschwenden und sich zu echten Ausfaellen entwickeln koennen.

PrestaShop-Protokolle

Gehen Sie im Back Office zu Erweiterte Einstellungen > Protokolle. Sortieren Sie nach Datum (neueste zuerst) und scannen Sie die Eintraege der letzten Woche. Konzentrieren Sie sich auf Schweregrad 3 (Fehler) und Schweregrad 4 (Kritisch). Haeufige kritische Fehler umfassen Datenbankverbindungsfehler, Dateiberechtigungsfehler, Modul-Ausnahmen und Zahlungsverarbeitungsfehler.

Wenn Sie wiederholt Fehler vom selben Modul sehen, hat dieses Modul einen Bug, der Aufmerksamkeit erfordert. Wenn Sie Datenbankfehler sehen, gehen Ihrem Datenbankserver moeglicherweise die Verbindungen oder der Speicherplatz aus.

PHP-Fehlerprotokoll

Der Speicherort des PHP-Fehlerprotokolls haengt von Ihrer Hosting-Umgebung ab. Gaengige Speicherorte sind /var/log/php/error.log, /var/log/apache2/error.log oder ein in Ihrem Hosting-Kontrollpanel angegebener Pfad. Ueberpruefen Sie die letzten 100 Zeilen auf schwerwiegende Fehler, Warnungen und Veralterungshinweise.

Veralterungshinweise sind besonders wichtig zu verfolgen. Sie warnen Sie, dass eine Funktion oder ein Feature, das Ihr Code verwendet, in einer zukuenftigen PHP-Version entfernt wird. Diese jetzt zu beheben verhindert, dass Ihr Shop beim naechsten PHP-Upgrade kaputtgeht.

Was mit Fehlern tun

Versuchen Sie nicht, jeden Fehler waehrend des Audits zu beheben. Das Audit dient der Identifizierung. Erstellen Sie eine Liste der kritischsten und haeufigsten Fehler, priorisiert nach Schweregrad. Schwerwiegende und kritische Fehler erfordern sofortige Aufmerksamkeit. Warnungen sollten innerhalb des Monats behoben werden. Hinweise und Veralterungswarnungen koennen fuer Ihr naechstes Wartungsfenster eingeplant werden.

Pruefung 3: Modul-Audit (5 Minuten)

Module sind die haeufigste Quelle von Sicherheitsluecken, Leistungsproblemen und Kompatibilitaetsproblemen in PrestaShop. Ein schnelles Modul-Audit identifiziert toten Ballast und potenzielle Risiken.

Ungenutzte Module identifizieren

Gehen Sie zu Module > Modul-Manager. Suchen Sie nach Modulen, die installiert, aber deaktiviert sind. Diese Module haben immer noch Dateien auf Ihrem Server und moeglicherweise Datenbanktabellen, aber sie erfuellen keinen Zweck. Sie vergroessern Ihre Angriffsflaeche (eine Sicherheitsluecke in den Dateien eines deaktivierten Moduls kann dennoch ausgenutzt werden) und verlangsamen Backups.

Entscheiden Sie fuer jedes deaktivierte Modul, ob Sie es wieder verwenden werden. Wenn nicht, deinstallieren Sie es vollstaendig (nicht nur deaktivieren). Die Deinstallation entfernt die Datenbanktabellen und die Konfiguration des Moduls. Loeschen Sie nach der Deinstallation auch das Modulverzeichnis aus /modules/, um seine Dateien vollstaendig vom Server zu entfernen.

Updates pruefen

Suchen Sie im Modul-Manager nach Modulen mit verfuegbaren Updates. Veraltete Module sind ein primaerer Angriffsvektor fuer Sicherheitsexploits. Update-Benachrichtigungen erscheinen als Badges in der Modulliste. Priorisieren Sie Updates fuer Module, die sensible Daten verarbeiten: Zahlungsmodule, Kundenkonto-Module und jedes Modul, das Formulare verarbeitet.

Bevor Sie ein Modul aktualisieren, pruefen Sie das Changelog, um zu verstehen, was sich geaendert hat. Wenn das Update Sicherheitsbehebungen enthaelt, wenden Sie es sofort an. Wenn es ein Feature-Update ist, testen Sie es zuerst in einer Staging-Umgebung, wenn moeglich.

Gesamtzahl der Module zaehlen

Pruefen Sie, wie viele Module insgesamt installiert sind. PrestaShop wird standardmaessig mit vielen Modulen ausgeliefert, und Shops sammeln im Laufe der Zeit weitere an. Jedes aktive Modul fuegt Hooks hinzu, die bei jedem Seitenaufruf ausgefuehrt werden, was die Antwortzeit erhoeht. Wenn Sie mehr als 80 bis 100 aktive Module haben, ueberpruefen Sie die Liste kritisch. Viele Standard-PrestaShop-Module (wie Social-Sharing-Buttons, Datenschutzhinweise und Statistik-Module) koennen deaktiviert werden, wenn Sie sie nicht verwenden, was zu messbaren Leistungsverbesserungen fuehrt.

Pruefung 4: Datenbankgesundheit (4 Minuten)

Ihre PrestaShop-Datenbank waechst kontinuierlich. Jeder Kundenbesuch erzeugt Sitzungsdaten. Jeder abgebrochene Warenkorb bleibt in der Datenbank. Jeder Protokolleintrag sammelt sich an. Ueber Monate und Jahre verlangsamt diese Aufblaehung Abfragen und erhoeht Backup-Zeiten.

Datenbankgroesse pruefen

Pruefen Sie in Ihrem Hosting-Kontrollpanel (cPanel > phpMyAdmin, zum Beispiel) die Gesamtgroesse der Datenbank. Eine gesunde PrestaShop-Datenbank fuer einen kleinen bis mittleren Shop (unter 10.000 Produkte) sollte unter 500 MB liegen. Wenn Ihre deutlich groesser ist, ist Datenaufblaehung wahrscheinlich die Ursache.

Grosse Tabellen identifizieren

Klicken Sie in phpMyAdmin auf Ihre Datenbank und sortieren Sie die Tabellen nach Groesse. Die ueblichen Verdaechtigen fuer Aufblaehung sind: ps_connections und ps_connections_page (Besucherverfolgungsdaten, die auf Gigabytes anwachsen koennen), ps_log (PrestaShops internes Protokoll), ps_mail (E-Mail-Verlauf), ps_cart und ps_cart_product (Daten abgebrochener Warenkoerbe), ps_guest (anonyme Besuchereintraege) und ps_pagenotfound (404-Fehlerverfolgung).

Diese Tabellen koennen sicher von alten Daten bereinigt werden. Zum Beispiel benoetigen Sie keine Verbindungsdaten von vor zwei Jahren. PrestaShop hat eine eingebaute Funktion zur Bereinigung einiger dieser Tabellen: Gehen Sie zu Erweiterte Einstellungen > Administration und suchen Sie nach den Datenbereinigungsoptionen. Fuer eine gruendlichere Bereinigung kann das kostenlose Modul PrestaShop Cleaner alte Statistikdaten, abgebrochene Warenkoerbe und abgelaufene Sitzungen loeschen.

Fehlende Indizes pruefen

Waehrend Sie in phpMyAdmin sind, pruefen Sie die Struktur Ihrer wichtigsten Tabellen (ps_product, ps_category_product, ps_stock_available) und verifizieren Sie, dass Indizes auf den Spalten existieren, die bei Suche und Filterung verwendet werden. Fehlende Indizes verursachen langsame Abfragen, die die Seitenladezeiten beeinflussen. Fuegen Sie jedoch keine Indizes hinzu, ohne die Kompromisse zu verstehen, da jeder Index Schreiboperationen geringfuegig verlangsamt.

Pruefung 5: Sicherheitsgrundlagen (5 Minuten)

Sicherheitsluecken in PrestaShop-Shops werden aktiv ausgenutzt. Automatisierte Scanner durchsuchen kontinuierlich das Internet nach verwundbaren Installationen. Fuenf Minuten Sicherheitspruefungen koennen einen katastrophalen Einbruch verhindern.

Admin-Panel-URL

Ihr Admin-Panel sollte nicht ueber eine vorhersehbare URL wie /admin/ oder /backoffice/ erreichbar sein. PrestaShop generiert waehrend der Installation einen zufaelligen Admin-Verzeichnisnamen (wie /admin738xyz/). Ueberpruefen Sie, ob Ihre Admin-URL weiterhin zufaellig ist, indem Sie den Admin-Verzeichnisnamen auf Ihrem Server kontrollieren. Wenn jemand ihn in etwas Erratbares umbenannt hat, benennen Sie ihn zurueck in eine zufaellige Zeichenfolge.

SSL-Zertifikat

Ihr gesamter Shop muss ueber HTTPS laufen. Pruefen Sie dies, indem Sie die URL Ihres Shops mit http:// aufrufen und verifizieren, dass es auf https:// umleitet. Gehen Sie im Back Office zu Shopeinstellungen > Allgemein und ueberpruefen Sie, dass "SSL aktivieren" und "SSL auf allen Seiten aktivieren" beide auf Ja gesetzt sind.

Pruefen Sie auch das Ablaufdatum Ihres SSL-Zertifikats. Let's Encrypt-Zertifikate laufen alle 90 Tage ab und sollten sich automatisch erneuern, aber die automatische Erneuerung scheitert oefter still, als man erwarten wuerde. Klicken Sie auf das Schloss-Symbol in der Adressleiste Ihres Browsers, um die Zertifikatsdetails und das Ablaufdatum zu sehen. Wenn es innerhalb der naechsten 30 Tage ablaeuft, ueberpruefen Sie, ob die automatische Erneuerung konfiguriert ist und funktioniert.

Dateiberechtigungen

Falsche Dateiberechtigungen sind ein Sicherheitsrisiko. Auf Linux-Servern sollten Ihre PrestaShop-Dateien generell dem Webserver-Benutzer gehoeren (typischerweise www-data oder apache) und diese Berechtigungen haben: Verzeichnisse mit 755 (Eigentuemer kann lesen/schreiben/ausfuehren, andere koennen lesen/ausfuehren), Dateien mit 644 (Eigentuemer kann lesen/schreiben, andere koennen lesen), und Konfigurationsdateien wie config/settings.inc.php oder app/config/parameters.php mit 640 oder 440 (eingeschraenkter Lesezugriff).

Ueberpruefen Sie einige kritische Dateien, um sicherzustellen, dass die Berechtigungen nicht zu offen sind. Keine Datei sollte 777 (weltbeschreibbar) sein. Wenn Sie 777-Berechtigungen finden, beheben Sie sie sofort. Sie erlauben jedem Benutzer auf dem Server, diese Dateien zu aendern.

Debug-Modus

Stellen Sie sicher, dass der Debug-Modus auf Ihrem Produktiv-Shop deaktiviert ist. Der Debug-Modus zeigt Besuchern detaillierte Fehlermeldungen, Dateipfade und Datenbankabfragen, was wertvolle Informationen fuer Angreifer darstellt. Pruefen Sie die Datei /config/defines.inc.php und stellen Sie sicher, dass _PS_MODE_DEV_ auf false gesetzt ist. In PrestaShop 8.x pruefen Sie auch die .env-Datei auf die Einstellung APP_DEBUG.

Bekannte Sicherheitsluecken

Pruefen Sie, ob Ihre PrestaShop-Version bekannte Sicherheitsluecken aufweist. Besuchen Sie die PrestaShop-Sicherheitshinweisseite und vergleichen Sie die aufgefuehrten Versionen mit Ihrer. Wenn Ihre Version von einem Hinweis betroffen ist, den Sie nicht gepatcht haben, priorisieren Sie die Anwendung des Fixes.

Pruefung 6: Schneller Performance-Test (4 Minuten)

Performance beeinflusst direkt die Konversionsraten. Jede zusaetzliche Sekunde Seitenladezeit reduziert die Konversionen messbar. Ein schneller Performance-Test identifiziert groessere Engpaesse.

Lighthouse-Audit durchfuehren

Oeffnen Sie Google Chrome, navigieren Sie zur Startseite Ihres Shops, oeffnen Sie die Chrome DevTools (F12) und klicken Sie auf den Lighthouse-Tab. Fuehren Sie ein Audit fuer Performance, Best Practices und SEO auf einem Mobilgeraet durch. Der Test dauert etwa 30 Sekunden.

Konzentrieren Sie sich auf den Performance-Score. Ein Score unter 50 deutet auf ernsthafte Performance-Probleme hin. Zwischen 50 und 89 bedeutet, dass es Verbesserungspotenzial gibt. Ueber 90 ist gut. Der Audit-Bericht zeigt spezifische Probleme und Schaetzungen, wie viel Zeit jede Behebung einsparen wuerde.

Wichtige Metriken pruefen

Achten Sie im Lighthouse-Bericht auf den Largest Contentful Paint (LCP), der misst, wie lange es dauert, bis der Hauptinhalt erscheint. Er sollte unter 2,5 Sekunden liegen. First Input Delay (FID) oder Interaction to Next Paint (INP) misst die Reaktionsfaehigkeit. Er sollte unter 200 Millisekunden liegen. Cumulative Layout Shift (CLS) misst die visuelle Stabilitaet. Er sollte unter 0,1 liegen.

Wenn der LCP hoch ist, sind die haeufigsten Ursachen in PrestaShop nicht optimierte Bilder (grosse Produktbilder ohne Komprimierung oder ordnungsgemaesse Groessenanpassung), langsame Serverantwortzeit (pruefen Sie Ihren Hosting-Plan und die Datenbankleistung), render-blockierendes CSS und JavaScript (deaktivieren Sie unnoetige Module, die ihre Assets auf jeder Seite laden) und deaktiviertes Caching (Smarty-Cache und CCC sollten in der Produktion aktiviert sein).

Cache-Konfiguration pruefen

Gehen Sie im Back Office zu Erweiterte Einstellungen > Leistung. Ueberpruefen Sie diese Einstellungen: Smarty-Cache sollte auf Ja stehen, mit dem Cache-Typ "Datei". CCC (Combine, Compress, Cache) sollte CSS- und JavaScript-Minifizierung und -Zusammenfuehrung aktiviert haben. Die Template-Kompilierung sollte auf "Templates neu kompilieren, wenn Dateien aktualisiert wurden" eingestellt sein (nicht "Kompilierung erzwingen", was nur fuer die Entwicklung gedacht ist).

Wenn eine dieser Einstellungen falsch konfiguriert ist, bietet deren Korrektur eine sofortige und spuerbare Leistungsverbesserung.

Pruefung 7: SEO-Grundlagen (3 Minuten)

Technische SEO-Probleme verhindern, dass Suchmaschinen Ihren Shop ordnungsgemaess crawlen und indexieren. Ein paar schnelle Pruefungen erfassen die wirkungsvollsten Probleme.

Robots.txt

Besuchen Sie ihredomain.de/robots.txt in Ihrem Browser. Ueberpruefen Sie, ob sie existiert und sinnvolle Regeln enthaelt. PrestaShop generiert automatisch eine robots.txt-Datei. Pruefen Sie, dass sie keine wichtigen Seiten blockiert. Ihre Produktseiten, Kategorieseiten und CMS-Seiten sollten nicht gesperrt sein. Haeufige Fehler sind das Blockieren aller URLs mit Parametern (was gefilterte Kategorieseiten und Suchergebnisse blockiert) und das Blockieren des /modules/-Verzeichnisses (was verhindern kann, dass CSS und JavaScript von Suchmaschinen-Renderern geladen werden).

Ueberpruefen Sie ausserdem, ob die robots.txt eine Sitemap-Anweisung enthaelt, die auf Ihre XML-Sitemap verweist: Sitemap: https://www.ihredomain.de/1_index_sitemap.xml.

XML-Sitemap

Besuchen Sie die in Ihrer robots.txt aufgefuehrte Sitemap-URL. Ueberpruefen Sie, ob sie laedt, ob sie aktuell ist (pruefen Sie die letzten Aenderungsdaten) und ob sie Ihre wichtigen Seiten enthaelt. Wenn die Sitemap veraltet oder leer ist, regenerieren Sie sie. Wenn Sie den eingebauten PrestaShop-Sitemap-Generator verwenden, gehen Sie zu Module > Modul-Manager, suchen Sie das Google Sitemap-Modul und klicken Sie auf Konfigurieren, um es zu regenerieren.

Pruefen Sie die Anzahl der URLs in der Sitemap gegen Ihre erwartete Anzahl. Wenn Sie 1.000 Produkte haben, aber die Sitemap nur 200 URLs auflistet, stimmt etwas mit dem Generierungsprozess nicht. Haeufige Ursachen sind deaktivierte oder nicht vorraetige Produkte, die von der Sitemap ausgeschlossen werden, Kategoriesichtbarkeitseinstellungen, die Produkte herausfiltern, und der Sitemap-Generierungsprozess, der vor der Fertigstellung abbricht.

Kanonische URLs

Besuchen Sie einige Produktseiten und betrachten Sie den Quelltext (Strg+U). Suchen Sie nach dem <link rel="canonical">-Tag im Head-Bereich. Es sollte die saubere URL der aktuellen Seite ohne Abfrageparameter enthalten. Wenn kanonische Tags fehlen oder falsch sind, schaedigen Duplicate-Content-Probleme Ihre SEO. Gehen Sie im Back Office zu Shopeinstellungen > Traffic & SEO und ueberpruefen Sie, ob "Apaches MultiViews-Option deaktivieren" und "Apaches mod_security-Modul deaktivieren" fuer Ihren Server korrekt konfiguriert sind.

Pruefung 8: Backup-Verifizierung (3 Minuten)

Backups, die nie getestet wurden, sind keine Backups. Sie sind Wunschdenken. Diese Pruefung verifiziert, dass Ihr Backup-System tatsaechlich funktioniert.

Aktualitaet des Backups pruefen

Ermitteln Sie, wo Ihre Backups gespeichert werden. Dies variiert je nach Hosting-Anbieter. Pruefen Sie Ihr Hosting-Kontrollpanel auf Backup-Tools (cPanel hat einen Backup-Bereich, Plesk hat einen Backup-Manager). Wenn Sie ein Backup-Modul in PrestaShop verwenden, pruefen Sie dessen Konfiguration und das aktuelle Backup-Protokoll.

Ihr aktuellstes Backup sollte fuer aktive Shops nicht aelter als 24 Stunden sein. Wenn Ihr letztes Backup aelter als eine Woche ist, ist Ihr Backup-System entweder nicht konfiguriert, laeuft nicht oder scheitert still. Beheben Sie dies sofort. Datenverlust durch einen Serverausfall oder Hack ohne ein aktuelles Backup kann geschaeftsbedrohend sein.

Backup-Vollstaendigkeit ueberpruefen

Ein vollstaendiges PrestaShop-Backup umfasst die gesamte Datenbank (alle Tabellen, nicht nur Produktdaten) und das Dateisystem (alle PrestaShop-Dateien, einschliesslich hochgeladener Bilder, Moduldateien und Theme-Anpassungen). Viele Backup-Loesungen erfassen nur die Datenbank oder nur die Dateien. Ueberpruefen Sie, ob Ihre beides erfasst.

Pruefen Sie die Backup-Dateigroessen. Ein Datenbank-Backup fuer einen kleinen Shop sollte mindestens mehrere Megabyte gross sein. Wenn es verdaechtig klein ist (unter 1 MB fuer einen aktiven Shop), koennte es leer oder beschaedigt sein. Ein Datei-Backup sollte Ihr /img/-Verzeichnis enthalten, das typischerweise das groesste Verzeichnis ist und bei Shops mit vielen Produktbildern mehrere Gigabyte umfassen kann.

Offsite-Backup-Speicherung

Backups, die auf demselben Server wie Ihr Shop gespeichert sind, sind denselben Ausfaellen ausgesetzt. Wenn die Festplatte des Servers ausfaellt, verlieren Sie sowohl den Shop als auch das Backup. Ueberpruefen Sie, ob Ihre Backups an einen separaten Ort kopiert werden: einen anderen Server, Cloud-Speicher (wie Amazon S3, Google Cloud Storage oder Dropbox) oder auf einen lokalen Computer heruntergeladen werden.

Pruefung 9: Update-Status (2 Minuten)

Veraltete Software zu betreiben ist der haeufigste Grund, warum PrestaShop-Shops gehackt werden. Diese letzte Pruefung ueberprueft, ob Ihre Core-Installation und kritische Module auf dem neuesten Stand sind.

PrestaShop Core-Version

Pruefen Sie Ihre aktuelle PrestaShop-Version in der Fusszeile des Back Office oder auf der Seite Erweiterte Einstellungen > Informationen. Vergleichen Sie sie mit der neuesten stabilen Version auf der PrestaShop-Website oder der GitHub-Releases-Seite. Wenn Sie mehr als eine Minor-Version hinterherhinken (zum Beispiel 8.1.2 verwenden, waehrend 8.1.5 verfuegbar ist), planen Sie ein Update. Wenn Sie eine Version mit bekannten Sicherheitsluecken verwenden, aktualisieren Sie dringend.

PrestaShop-Major-Version-Upgrades (wie 1.7 auf 8.x) sind komplexe Migrationsprojekte, keine einfachen Updates. Versuchen Sie diese nicht ohne gruendliche Planung und Tests. Minor-Version-Updates (wie 8.1.2 auf 8.1.5) sind jedoch generell sicher und enthalten hauptsaechlich Sicherheits- und Fehlerbehebungen.

Kritische Modul-Updates

Einige Module verarbeiten sensible Operationen und muessen aktuell gehalten werden: Zahlungsmodule (jedes Modul, das Kreditkarten, PayPal oder andere Zahlungsmethoden verarbeitet), das PrestaShop Autoupgrade-Modul (fuer Core-Updates verwendet) und alle sicherheitsrelevanten Module. Pruefen Sie den Modul-Manager auf verfuegbare Updates fuer diese spezifischen Module.

Zusammenfassung der 30-Minuten-Audit-Checkliste

Hier ist die vollstaendige Checkliste mit Zeiteinteilungen, der Sie jeden Monat folgen koennen:

Minuten 1-3: PHP-Version und Konfiguration. PHP-Version ist unterstuetzt pruefen. memory_limit, max_execution_time und OPcache-Status verifizieren.

Minuten 4-7: Fehlerprotokoll-Ueberpruefung. PrestaShop-Protokolle auf Eintraege mit Schweregrad 3 und 4 scannen. PHP-Fehlerprotokoll auf schwerwiegende Fehler und Veralterungshinweise pruefen. Wiederkehrende Fehler fuer Nachverfolgung notieren.

Minuten 8-12: Modul-Audit. Deaktivierte Module ueberpruefen und ungenutzte deinstallieren. Verfuegbare Updates pruefen, insbesondere bei Zahlungs- und Sicherheitsmodulen. Gesamtzahl aktiver Module zaehlen und Kandidaten fuer die Entfernung identifizieren.

Minuten 13-16: Datenbankgesundheit. Gesamtgroesse der Datenbank pruefen. Aufgeblaehte Tabellen identifizieren. Bereinigung alter Verbindungs-, Protokoll- und Warenkorbdaten planen.

Minuten 17-21: Sicherheitsgrundlagen. Admin-URL ist zufaellig verifizieren. SSL-Zertifikat und Ablaufdatum pruefen. Dateiberechtigungen verifizieren. Debug-Modus ist deaktiviert bestaetigen. Bekannte Sicherheitsluecken Ihrer Version pruefen.

Minuten 22-25: Schneller Performance-Test. Lighthouse-Audit auf der Startseite durchfuehren. LCP-, INP- und CLS-Metriken pruefen. Cache- und CCC-Einstellungen im Back Office verifizieren.

Minuten 26-28: SEO-Grundlagen. robots.txt auf Fehler pruefen. Sitemap ist aktuell und vollstaendig verifizieren. Kanonische URLs auf Produktseiten stichprobenartig pruefen.

Minuten 29-30: Backup und Updates. Aktualitaet und Vollstaendigkeit des Backups verifizieren. PrestaShop Core- und kritische Modulversionen mit den neuesten Veroeffentlichungen vergleichen.

Dieses Audit behebt keine Probleme. Es identifiziert sie. Nach Abschluss der Checkliste sollten Sie eine priorisierte Liste von Problemen haben, die behoben werden muessen. Kritische Sicherheitsprobleme und defekte Funktionalitaet stehen an erster Stelle. Performance-Optimierungen und Bereinigungsaufgaben kommen an zweiter Stelle. Kleinere Verbesserungen und Zukunftsplanung an dritter Stelle. Indem Sie dieses Audit monatlich durchfuehren, erkennen Sie Probleme frueh, behalten ein klares Bild des technischen Zustands Ihres Shops und vermeiden die unangenehmen Ueberraschungen, die durch Monate vernachlaessigter Wartung entstehen.

Lazy Loading in 2026: Was Browser nativ unterstützen und wofür man ein Modul braucht

Lazy Loading ist eine Performance-Optimierungstechnik, die das Laden von Ressourcen außerhalb des Bildschirms verzögert, bis der Benutzer in ihre Nähe scrollt. Im Jahr 2026 hat die native Browser-Unterstützung für Lazy Loading deutlich zugenommen, aber es gibt immer noch Szenarien, in denen PrestaShop-Shop-Betreiber zusätzliche Module oder benutzerdefinierte Implementierungen benötigen. Dieser Leitfaden erklärt genau, was Browser selbst erledigen, welche Lücken bestehen und wie Sie die beste Lazy-Loading-Strategie für Ihren PrestaShop-Shop implementieren.

Was natives Lazy Loading 2026 abdeckt

Das HTML-Attribut loading="lazy" wird jetzt von über 95% der Browser weltweit unterstützt. Dazu gehören Chrome (seit v77), Firefox (seit v75), Safari (seit v15.4), Edge (seit v79) und alle Chromium-basierten Browser. Das bedeutet, dass natives Lazy Loading für die meisten Besucher Ihres Shops sofort funktioniert.

So funktioniert natives Lazy Loading

Das Hinzufügen von loading="lazy" zu einem <img>- oder <iframe>-Tag weist den Browser an, das Laden dieser Ressource zu verzögern, bis sie sich in einer bestimmten Entfernung vom Viewport befindet. Der Browser übernimmt die gesamte Timing- und Intersection-Logik intern, ohne JavaScript-Overhead.

<!-- Natives Lazy Loading für Bilder -->
<img src="produkt-bild.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Produktname">

<!-- Natives Lazy Loading für Iframes -->
<iframe src="https://www.youtube.com/embed/VIDEO_ID" 
        loading="lazy" 
        width="560" 
        height="315"></iframe>

Was Browser nativ unterstützen

Was Browser NICHT unterstützen

Natives Lazy Loading in PrestaShop implementieren

Für PrestaShop 8.x und 9.x Themes

Moderne PrestaShop-Themes (wie Hummingbird für PS 9) enthalten oft standardmäßig natives Lazy Loading. Um es zu überprüfen oder zu Ihrem Theme hinzuzufügen, bearbeiten Sie die Template-Dateien, in denen Produktbilder gerendert werden.

{* Vorher - kein Lazy Loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Nachher - mit nativem Lazy Loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Kritische Regel: Bilder above-the-fold niemals lazy laden

Der häufigste Lazy-Loading-Fehler ist die Anwendung auf Bilder, die ohne Scrollen sichtbar sind. Dies verschlechtert tatsächlich die Performance, da der Browser das Laden von Inhalten verzögert, die der Benutzer sofort sieht. Googles Core Web Vitals werden Sie dafür mit einem höheren LCP-Wert (Largest Contentful Paint) bestrafen.

Bilder, die NICHT lazy geladen werden sollten:

• Ihr Shop-Logo
• Hero-/Bannerbilder oben auf der Seite
• Die ersten 1-2 Produktbilder auf Kategorieseiten
• Jedes Bild, das im initialen Viewport ohne Scrollen sichtbar ist

Für diese kritischen Bilder verwenden Sie Eager Loading mit Priority-Hints:

<img src="hero-banner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Sommer-Sale-Banner">

Wann Sie ein Modul brauchen: CSS-Hintergrundbilder

PrestaShop-Themes verwenden häufig CSS-Hintergrundbilder für Slider, Banner, Kategorieheader und Werbeblöcke. Das Attribut loading="lazy" funktioniert nicht für CSS-Hintergründe. Sie benötigen JavaScript, um diese zu behandeln.

IntersectionObserver-Ansatz

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                const el = entry.target;
                el.style.backgroundImage = 'url(' + el.dataset.bg + ')';
                observer.unobserve(el);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Wann Sie ein Modul brauchen: Platzhalter-Effekte

Natives Lazy Loading zeigt nichts an, bis das Bild geladen ist, was zu einem unangenehmen visuellen Erlebnis führen kann. Module oder Bibliotheken können hinzufügen:

• Blur-up-Effekt (LQIP) - Laden Sie zuerst eine winzige, unscharfe Version, dann ersetzen Sie sie durch das vollständige Bild
• Skeleton-Screens - Graue Platzhalterblöcke, die den Bilddimensionen entsprechen
• Dominante Farb-Platzhalter - Extrahieren Sie die dominante Farbe aus dem Bild und verwenden Sie sie als Platzhalter-Hintergrund

Auswirkungen auf PrestaShop-Performance und Core Web Vitals

Richtiges Lazy Loading beeinflusst direkt drei Core Web Vitals Metriken:

• LCP - Lazy Loading von Above-the-fold-Bildern VERSCHLECHTERT LCP. Nur Below-the-fold-Bilder lazy laden.
• CLS - Bilder ohne width/height-Attribute verursachen Layoutverschiebungen. Immer Dimensionen angeben.
• INP - Weniger gleichzeitig ladende Ressourcen bedeuten weniger Hauptthread-Belastung.

Pflicht: Width- und Height-Attribute

<!-- SCHLECHT - verursacht Layoutverschiebung -->
<img src="produkt.jpg" loading="lazy" alt="Produkt">

<!-- GUT - reserviert Platz, keine Layoutverschiebung -->
<img src="produkt.jpg" loading="lazy" 
     width="400" height="400" alt="Produkt">

PrestaShop-spezifische Empfehlungen

Produktlistenseiten

Alle Produktbilder lazy laden außer der ersten Reihe. Natives loading="lazy" für Produktbilder verwenden und fetchpriority="high" auf die erste Reihe anwenden.

Produktdetailseiten

Das Hauptproduktbild sollte eager geladen werden mit fetchpriority="high". Thumbnail-Bilder in der Galerie können lazy geladen werden.

Startseite

Slider-/Karussell-Bilder above the fold sollten eager geladen werden. Modulblöcke below the fold sollten Lazy Loading verwenden.

Zusammenfassung: Modul vs. Nativ

Rate Limiting und Bot-Schutz fuer PrestaShop ohne WAF

Bots machen 2026 ueber 40% des gesamten Web-Traffics aus. Scraper stehlen Produktdaten, Credential-Stuffing-Bots greifen Login-Seiten an, und Inventory-Hoarding-Bots kaufen limitierten Bestand auf. Dieser Leitfaden zeigt, wie Sie effektiven Bot-Schutz mit Serverkonfiguration, .htaccess-Regeln und leichtgewichtigen Modulen implementieren.

Methode 1 - Apache .htaccess Rate Limiting

Bekannte boesartige User Agents blockieren

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot|DotBot) [NC]
RewriteRule .* - [F,L]

RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule .* - [F,L]

Methode 2 - Nginx Rate Limiting

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;

location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

location / {
    limit_req zone=general burst=20;
}

Methode 3 - fail2ban fuer Brute-Force-Schutz

fail2ban ueberwacht Serverlogs und sperrt automatisch IPs mit bösartigem Verhalten.

Methode 4 - PHP-Level Rate Limiting

Fuer Shared Hosting: dateibasierter Rate Limiter in PHP implementieren.

Methode 5 - robots.txt und Crawl-Kontrolle

User-agent: SemrushBot
Crawl-delay: 10

User-agent: AhrefsBot
Crawl-delay: 10

Methode 6 - CAPTCHA auf kritischen Formularen

reCAPTCHA oder hCaptcha auf Login, Registrierung, Kontaktformular und Newsletter hinzufuegen.

Methode 7 - Cloudflare Free Tier

Auch ohne Pro-Plan: Browser Integrity Check, Bot Fight Mode und Rate Limiting sind kostenlos verfuegbar.

Ueberwachung und Erkennung

awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20

Zusammenfassung der Schutzschichten

PrestaShop .htaccess-Weiterleitungen: Regeln schreiben, ohne den Shop zu beschädigen

Die .htaccess-Datei ist eine der leistungsfähigsten und gefährlichsten Dateien in Ihrer PrestaShop-Installation. Ein einziges falsch platziertes Zeichen kann Ihren gesamten Shop offline nehmen. Aber das Beherrschen von .htaccess-Weiterleitungen ist für SEO unverzichtbar - Sie brauchen sie beim Ändern von URLs, bei der Migration von einer anderen Plattform, beim Entfernen alter Produkte oder bei der Umstrukturierung Ihres Kategoriebaums.

Wie PrestaShop .htaccess verwendet

PrestaShop generiert und verwaltet die .htaccess-Datei automatisch. Wenn Sie Freundliche URLs in den SEO & URLs-Einstellungen aktivieren, schreibt PrestaShop Rewrite-Regeln zwischen zwei Markierungskommentaren:

# ~~start~~ Entfernen Sie diesen Kommentar nicht
# -- Ihre PrestaShop-Regeln hier --
# ~~end~~ Entfernen Sie diesen Kommentar nicht

Kritische Regel - Fügen Sie Ihre benutzerdefinierten Weiterleitungen niemals innerhalb dieses Blocks ein. PrestaShop überschreibt sie bei der nächsten Neugenerierung. Platzieren Sie Ihre Regeln VOR dem PrestaShop-Block.

Weiterleitung-Typen verstehen

301 - Permanente Weiterleitung

Verwenden Sie diese, wenn eine Seite dauerhaft an eine neue URL umgezogen ist. Suchmaschinen übertragen den SEO-Wert der alten Seite auf die neue URL.

302 - Temporäre Weiterleitung

Verwenden Sie diese, wenn eine Seite vorübergehend nicht verfügbar ist. Suchmaschinen behalten die alte URL im Index.

410 - Gone

Verwenden Sie diese, wenn eine Seite dauerhaft entfernt wurde und es keinen Ersatz gibt.

Grundlegende Weiterleitungs-Syntax

Einfache Eins-zu-Eins-Weiterleitungen

# Eine einzelne URL umleiten
Redirect 301 /alte-seite.html https://ihrshop.com/neue-seite.html

# Eine alte Produkt-URL umleiten
Redirect 301 /altes-produkt.html https://ihrshop.com/de/neues-produkt.html

# Eine alte Kategorie umleiten
Redirect 301 /alte-kategorie/ https://ihrshop.com/de/neue-kategorie/

Musterbasierte Weiterleitungen mit RewriteRule

RewriteEngine On

# Alle Seiten aus alter Ordnerstruktur umleiten
RewriteRule ^alter-ordner/(.*)$ https://ihrshop.com/neuer-ordner/$1 [R=301,L]

# Produkt-IDs zu freundlichen URLs umleiten
RewriteRule ^product\.php\?id_product=([0-9]+)$ https://ihrshop.com/de/produkt-$1.html [R=301,L]

Häufige PrestaShop-Weiterleitungsszenarien

Szenario 1 - Migration von einer anderen Plattform

# WooCommerce zu PrestaShop
RewriteRule ^product/alter-slug/?$ https://ihrshop.com/de/neue-url.html [R=301,L]

# Magento zu PrestaShop
RewriteRule ^catalog/product/view/id/([0-9]+)/?$ https://ihrshop.com/de/produkt-$1.html [R=301,L]

Szenario 2 - HTTPS und WWW erzwingen

# HTTPS erzwingen
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# www erzwingen
RewriteCond %{HTTP_HOST} ^ihrshop\.com$ [NC]
RewriteRule ^(.*)$ https://www.ihrshop.com/$1 [R=301,L]

Regeln, die PrestaShop beschädigen können

Endlose Weiterleitungsschleifen

Der gefährlichste Fehler. Dies passiert, wenn eine Regel URL A zu URL B umleitet und eine andere Regel URL B zurück zu URL A umleitet.

# GEFÄHRLICH - kann Schleifen verursachen
RewriteRule ^(.*)$ https://ihrshop.com/$1 [R=301,L]

# SICHER - verhindert Schleife durch Prüfung
RewriteCond %{HTTP_HOST} !^www\.ihrshop\.com$ [NC]
RewriteRule ^(.*)$ https://www.ihrshop.com/$1 [R=301,L]

Back-Office- und API-Zugriff unterbrechen

# GEFÄHRLICH
RewriteRule ^(.*)$ https://ihrshop.com/de/$1 [R=301,L]

# SICHER - Admin und API ausschließen
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules [NC]
RewriteRule ^(.*)$ https://ihrshop.com/de/$1 [R=301,L]

Weiterleitungen sicher testen

Schritt 1 - Immer zuerst sichern

cp .htaccess .htaccess.backup

Schritt 2 - Zuerst mit 302 testen

Verwenden Sie temporäre (302) Weiterleitungen während der Tests. Wechseln Sie erst nach Bestätigung zu 301.

Schritt 3 - Mit curl testen

curl -I -L https://ihrshop.com/alte-seite.html
curl -I https://ihrshop.com/alte-seite.html

Wo benutzerdefinierte Regeln platzieren

# IHRE WEITERLEITUNGEN HIER (vor dem PrestaShop-Block)
Redirect 301 /alte-seite.html https://ihrshop.com/neue-seite.html

# ~~start~~ PrestaShop-Block
# ... automatisch generierte Regeln ...
# ~~end~~ PrestaShop-Block

Wann Sie ein Modul verwenden sollten

Erwägen Sie ein Weiterleitungsmodul statt manueller .htaccess-Bearbeitung wenn: nicht-technisches Personal Weiterleitungen verwalten muss, Sie Hunderte von Weiterleitungen mit einer Benutzeroberfläche verwalten möchten, Sie automatische 404-Erkennung benötigen, oder Sie Weiterleitungs-Analysen wünschen.

Kurzreferenz

PHP-Versionskompatibilitätsmatrix für PrestaShop

Die Wahl der richtigen PHP-Version für Ihren PrestaShop-Shop ist eine der wichtigsten Infrastrukturentscheidungen, die Sie treffen werden. Eine inkompatible PHP-Version kann weiße Bildschirme, fehlerhafte Checkout-Abläufe, Modulfehler und Sicherheitslücken verursachen. Dieser umfassende Leitfaden behandelt jede PrestaShop-Version von 1.6 bis 9.x und ordnet jede Version ihren unterstützten PHP-Versionen, empfohlenen Konfigurationen und Upgrade-Überlegungen zu.

Warum die PHP-Version für PrestaShop wichtig ist

PHP ist die serverseitige Programmiersprache, die PrestaShop antreibt. Jede wichtige PHP-Version bringt Leistungsverbesserungen, neue Sprachfunktionen und veraltet ältere Funktionen. Die PrestaShop-Codebasis entwickelt sich parallel zu PHP weiter, was bedeutet, dass neuere PrestaShop-Versionen moderne PHP-Funktionen nutzen und gleichzeitig die Unterstützung für veraltete Versionen einstellen.

Die Verwendung der falschen PHP-Version verursacht drei Kategorien von Problemen:

• Fatale Fehler - Funktionen, die in neueren PHP-Versionen entfernt wurden (z.B. mysql_*-Funktionen in PHP 7.0, each() in PHP 8.0), verursachen sofortige Abstürze.
• Verfallswarnungen - Veraltete Funktionen erzeugen Warnungen, die AJAX-Antworten, JSON-Ausgaben und PDF-Erstellung stören können, wenn display_errors aktiviert ist.
• Sicherheitsrisiken - PHP-Versionen, die ihr Lebensende erreicht haben, erhalten keine Sicherheitspatches mehr und machen Ihren Shop anfällig für Angriffe.

Vollständige Kompatibilitätsmatrix

PrestaShop 1.6.x

Empfohlenes PHP für 1.6.x - PHP 7.1. Es bietet die beste Balance zwischen Leistung und Kompatibilität. Das Ausführen von 1.6.x auf PHP 7.2+ erfordert Änderungen an Kerndateien, die den Upgrade-Pfad unterbrechen und nicht empfohlen werden.

PrestaShop 1.7.x

Kritische Warnung - Keine Version von PrestaShop 1.7 unterstützt PHP 8.0 oder höher. Wenn Sie PS 1.7.6 auf PHP 8 ausführen, stürzt Smarty sofort ab, da die Template-Engine Funktionen verwendet, die in PHP 8.0 entfernt wurden. Die Entfernung der each()-Funktion und Änderungen an der Funktionsweise von array_key_exists() mit Objekten verursachen fatale Fehler.

PrestaShop 8.x

Empfohlenes PHP für 8.x - PHP 8.1. Es bietet die optimale Kombination aus voller Kompatibilität, aktivem Sicherheitssupport und hervorragender Leistung mit JIT-Kompilierung. PHP 8.1 bringt Fibers, Enums, Readonly-Eigenschaften und Intersection-Typen, die PrestaShop 8 nutzen kann.

PrestaShop 9.x

Empfohlenes PHP für 9.x - PHP 8.3 oder 8.4. PrestaShop 9 läuft auf Symfony 6.4 LTS und erfordert PHP 8.1 als Minimum. PHP 8.4 bringt Property Hooks und asymmetrische Sichtbarkeit, die zukünftige PrestaShop-Updates nutzen werden.

PHP-End-of-Life-Daten, die Sie kennen müssen

Wenn Sie im Jahr 2026 PHP 7.4 oder 8.0 verwenden, arbeiten Sie mit einer nicht unterstützten Version, die keine Sicherheitspatches mehr erhält. Dies ist ein kritisches Risiko für jeden E-Commerce-Shop, der Zahlungsdaten verarbeitet.

So überprüfen Sie Ihre aktuelle PHP-Version

Methode 1 - PrestaShop Back Office

Navigieren Sie zu Erweiterte Einstellungen > Informationen. Der Bereich Serverinformationen zeigt Ihre PHP-Version zusammen mit dem Speicherlimit, der maximalen Ausführungszeit und anderen relevanten Einstellungen an.

Methode 2 - PHP-Info-Datei

Erstellen Sie eine Datei namens phpinfo.php im Stammverzeichnis Ihres Shops mit folgendem Inhalt:

<?php phpinfo();

Rufen Sie sie über Ihren Browser auf: https://ihrshop.com/phpinfo.php. Löschen Sie diese Datei sofort nach der Überprüfung - sie legt sensible Serverkonfigurationsdetails offen.

Methode 3 - Kommandozeile

php -v
php -r "echo PHP_VERSION;"

Beachten Sie, dass die CLI-PHP-Version sich von der Webserver-PHP-Version unterscheiden kann. Überprüfen Sie immer über die Weboberfläche oder phpinfo().

Häufige Probleme bei falscher PHP-Version

Weißer Bildschirm des Todes (WSOD)

Das häufigste Symptom einer PHP-Inkompatibilität. Überprüfen Sie Ihr PHP-Fehlerprotokoll (normalerweise unter /var/log/php-errors.log oder über Ihr Hosting-Panel zugänglich). Typische Fehler sind:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Verfallswarnungen brechen AJAX

Wenn display_errors = On ist und Sie PHP upgraden, werden Verfallshinweise den AJAX-Antworten vorangestellt. Dies unterbricht das JSON-Parsing im Back Office und führt dazu, dass Funktionen wie Produktsuche, Kundensuche und Bestellerstellung stillschweigend fehlschlagen. Die Lösung:

; php.ini
display_errors = Off
log_errors = On
error_log = /pfad/zum/php-error.log

Modulinkompatibilität

Module von Drittanbietern unterstützen möglicherweise Ihre PHP-Version nicht. Überprüfen Sie vor dem PHP-Upgrade jedes installierte Modul auf Kompatibilität. Häufige Problembereiche:

• Module, die create_function() verwenden - in PHP 8.0 entfernt
• Module, die mysql_*-Funktionen verwenden - in PHP 7.0 entfernt
• Module, die positionellen Stringzugriff mit geschweiften Klammern $str{0} verwenden - in PHP 8.0 entfernt
• Module, die nullable Rückgabetypen nicht korrekt behandeln - strenger ab PHP 8.1+

So upgraden Sie PHP für PrestaShop sicher

Schritt 1 - Aktuelle Konfiguration dokumentieren

Bevor Sie etwas ändern, dokumentieren Sie Ihre aktuelle Umgebung:

php -v                    # Aktuelle PHP-Version
php -m                    # Geladene Erweiterungen
php -i | grep memory      # Speicherlimit
php -i | grep max_exec    # Ausführungszeitlimit

Schritt 2 - Modulkompatibilität prüfen

Überprüfen Sie jedes installierte Modul. Konsultieren Sie die Dokumentation des Modulentwicklers bezüglich PHP-Versionsunterstützung. Wenn ein Modul seit über zwei Jahren nicht aktualisiert wurde, ist es wahrscheinlich inkompatibel mit PHP 8.x.

Schritt 3 - Zuerst auf Staging testen

Upgraden Sie niemals PHP auf Ihrem Produktionsserver ohne vorherige Tests. Erstellen Sie eine Staging-Kopie Ihres Shops und testen Sie mit der neuen PHP-Version. Prüfen Sie:

• Front-Office-Seiten laden korrekt
• Produktseiten, Kategorieseiten, CMS-Seiten
• Der Warenkorb- und Checkout-Prozess wird vollständig abgeschlossen
• Zahlungsmodule verarbeiten Testtransaktionen
• Back-Office-Funktionalität funktioniert (Produktbearbeitung, Bestellverwaltung)
• Alle Drittanbietermodule funktionieren korrekt
• Cron-Jobs werden fehlerfrei ausgeführt

Schritt 4 - Upgrade mit Rollback-Plan

Die meisten Hosting-Anbieter ermöglichen den Wechsel der PHP-Version über das Control Panel (cPanel, Plesk, DirectAdmin). Halten Sie die vorherige PHP-Version für ein schnelles Rollback bereit, falls Probleme auftreten.

Schritt 5 - Alle Caches nach dem Upgrade leeren

Nach dem Wechsel der PHP-Version leeren Sie jede Cache-Schicht:

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

# Smarty-kompilierte Templates leeren
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Bei Verwendung von OPcache PHP-FPM neu starten
systemctl restart php8.3-fpm

# CDN-Cache leeren (Cloudflare, etc.)

PHP-Konfigurationsempfehlungen für PrestaShop

Unabhängig von der gewählten PHP-Version sind diese Einstellungen für eine optimale PrestaShop-Leistung unerlässlich:

; php.ini empfohlene Einstellungen
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; OPcache-Einstellungen (kritisch für Leistung)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Erforderliche Erweiterungen
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Überlegungen für Modulentwickler

Wenn Sie PrestaShop-Module entwickeln, müssen Sie die PHP-Kompatibilität sorgfältig berücksichtigen:

• Mindest-PHP-Version - Zielen Sie auf PHP 7.2 als Minimum für Module, die mit PrestaShop 8.0+ funktionieren sollen, oder PHP 8.1 für Module, die nur für PrestaShop 9 bestimmt sind.
• PHPStan oder Psalm verwenden - Statische Analysetools erkennen PHP-Versionsinkompatibilitäten, bevor Ihre Benutzer es tun.
• Versionsspezifische Syntax vermeiden - Funktionen wie Match-Ausdrücke (PHP 8.0), Enums (PHP 8.1) und Readonly-Eigenschaften (PHP 8.1) beschränken Ihr Modul auf diese PHP-Versionen und höher.
• Auf mehreren Versionen testen - Verwenden Sie Docker-Container mit verschiedenen PHP-Versionen, um Ihr Modul über den gesamten Kompatibilitätsbereich zu testen.

Häufig gestellte Fragen

Kann ich PrestaShop 1.7 auf PHP 8 ausführen?

Nein. Keine Version von PrestaShop 1.7 unterstützt offiziell PHP 8.0 oder höher. Während einige Benutzer Patches angewendet haben, um es teilweise zum Laufen zu bringen, ist dies nicht unterstützt und wird bei Updates Probleme verursachen. Der richtige Weg ist ein Upgrade auf PrestaShop 8.x.

Sollte ich PHP 8.4 mit PrestaShop 8.1 verwenden?

Nicht empfohlen. PrestaShop 8.1 wurde hauptsächlich mit PHP 8.1 entwickelt und getestet. Während PHP 8.2 in späteren 8.1.x-Releases teilweise unterstützt wird, führt PHP 8.4 Änderungen ein, die Probleme mit älteren Symfony-Komponenten verursachen können. Bleiben Sie bei PHP 8.1 für PrestaShop 8.x.

Wie viel schneller ist PHP 8.x im Vergleich zu 7.x?

Benchmarks zeigen, dass PHP 8.1 für typische PrestaShop-Workloads etwa 20-30% schneller als PHP 7.4 ist. Der JIT-Compiler bietet den größten Vorteil bei rechenintensiven Aufgaben. Für I/O-gebundene Operationen (Datenbankabfragen, Dateizugriffe) ist die Verbesserung kleiner, aber dennoch messbar.

Erfordert ein PHP-Upgrade auch ein PrestaShop-Upgrade?

Nicht unbedingt, aber beides geht Hand in Hand. Sie können PHP innerhalb des unterstützten Bereichs für Ihre PrestaShop-Version upgraden, ohne PrestaShop selbst zu aktualisieren. Wenn Sie jedoch eine moderne PHP-Version (8.3+) verwenden möchten, benötigen Sie PrestaShop 8.1 oder 9.x.

Was Content Security Policy ist und warum es wichtig ist

Content Security Policy (CSP) ist ein Sicherheitsmechanismus, der über HTTP-Header implementiert wird und dem Browser genau mitteilt, welche Ressourcen auf Ihren Seiten geladen werden dürfen. Es verhindert Cross-Site-Scripting (XSS)-Angriffe, Dateninjektionsangriffe und andere Code-Injektionsschwachstellen, indem es Ihnen eine granulare Kontrolle darüber gibt, woher JavaScript, CSS, Bilder, Schriftarten, Frames und andere Ressourcen stammen dürfen.

Ohne CSP führt ein Browser jedes JavaScript aus, das er auf Ihrer Seite findet, unabhängig davon, woher es stammt. Wenn es einem Angreifer gelingt, ein bösartiges Skript zu injizieren (über ein anfälliges Modul, eine kompromittierte Drittanbieter-Bibliothek oder eine gespeicherte XSS-Schwachstelle), führt der Browser es bereitwillig mit vollem Zugriff auf den Seiteninhalt aus, einschließlich Kundendaten, Formulareingaben und Sitzungs-Cookies.

Mit CSP deklarieren Sie eine Whitelist vertrauenswürdiger Quellen. Wenn der Browser auf eine Ressource stößt, die nicht zur Richtlinie passt, blockiert er sie und protokolliert einen Verstoß. Das bedeutet, dass selbst wenn ein Angreifer einen Weg findet, Code in Ihre Seite einzuschleusen, der Browser die Ausführung verweigert, da er nicht von einer genehmigten Quelle stammt.

Für PrestaShop-Shops, die persönliche Kundendaten, Zahlungsdaten und Authentifizierungsdaten verarbeiten, ist CSP eine kritische Sicherheitsschicht. Es ersetzt nicht die Behebung von Schwachstellen in Ihrem Code, ist aber eine effektive Defense-in-Depth-Maßnahme, die den Schaden begrenzt, wenn eine Schwachstelle existiert.

CSP-Direktiven erklärt

Eine Content Security Policy besteht aus einer oder mehreren Direktiven, die jeweils einen bestimmten Ressourcentyp steuern. Die wichtigsten Direktiven für PrestaShop sind:

default-src: Die Fallback-Direktive. Wenn eine spezifischere Direktive nicht gesetzt ist, verwendet der Browser default-src. Das Setzen von default-src 'self' bedeutet, dass standardmäßig nur Ressourcen von Ihrer eigenen Domain erlaubt sind.

script-src: Steuert, von wo JavaScript geladen werden kann. Dies ist die kritischste Direktive zur XSS-Prävention. Übliche Werte sind 'self' (Ihre eigene Domain), bestimmte CDN-Domains und Analytics-Domains.

style-src: Steuert, von wo CSS geladen werden kann. PrestaShop-Themes und -Module verwenden häufig Inline-Stile, was bedeutet, dass Sie möglicherweise 'unsafe-inline' benötigen, es sei denn, Sie implementieren einen Nonce-basierten Ansatz.

img-src: Steuert, von wo Bilder geladen werden können. PrestaShop-Shops laden oft Bilder von ihrer eigenen Domain, CDN-Domains und Drittanbieterdiensten wie Google (für Benutzer-Avatare oder Maps).

font-src: Steuert, von wo Schriftarten geladen werden können. Google Fonts, Font Awesome CDN und Ihre eigene Domain sind gängige Quellen.

connect-src: Steuert, welche URLs über JavaScript kontaktiert werden können (AJAX-Anfragen, WebSocket-Verbindungen, EventSource). Zahlungsgateways, Analytics-Endpunkte und Ihre eigenen API-Endpunkte müssen hier aufgeführt werden.

frame-src: Steuert, welche Domains in Iframes eingebettet werden können. Zahlungsgateways wie PayPal, Stripe und Klarna verwenden Iframes für ihre Zahlungsformulare. YouTube- und Vimeo-Einbettungen erfordern ebenfalls frame-src-Einträge.

frame-ancestors: Steuert, welche Domains Ihre Seite in einem Iframe einbetten können. Das Setzen von frame-ancestors 'self' verhindert Clickjacking-Angriffe, indem sichergestellt wird, dass Ihr Shop nicht in den Iframe einer anderen Website eingebettet werden kann.

object-src: Steuert Plugin-Inhalte wie Flash. Setzen Sie dies auf 'none', da Flash veraltet ist und keine PrestaShop-Funktionalität es erfordert.

base-uri: Steuert, welche URLs im <base>-Element verwendet werden können. Setzen Sie es auf 'self', um Base-URI-Manipulationsangriffe zu verhindern.

form-action: Steuert, an welche URLs Formulare gesendet werden können. Dies sollte Ihre eigene Domain und alle externen Zahlungsverarbeitungsendpunkte einschließen.

Beginnen Sie mit dem Report-Only-Modus

Die Bereitstellung von CSP in einem PrestaShop-Shop erfordert sorgfältige Vorbereitung, da eine zu restriktive Richtlinie die Funktionalität beeinträchtigt. Der richtige Ansatz ist, mit dem Report-Only-Modus zu beginnen, der den Browser anweist, Verstöße zu melden, ohne tatsächlich etwas zu blockieren.

Anstatt den Content-Security-Policy-Header zu verwenden, verwenden Sie Content-Security-Policy-Report-Only. Dieser Header akzeptiert genau die gleichen Direktiven, generiert aber nur Berichte, ohne die Richtlinie durchzusetzen. Ihr Shop funktioniert weiterhin normal, während Sie Daten darüber sammeln, was blockiert werden würde.

Verstoßberichte einrichten

Fügen Sie Ihrer Richtlinie eine report-uri-Direktive hinzu, die auf einen Endpunkt zeigt, der Verstoßberichte sammelt. Sie können einen kostenlosen Dienst wie Report URI (report-uri.com) verwenden, der ein Dashboard zum Anzeigen und Analysieren von CSP-Verstößen bietet, oder Sie können Ihren eigenen Endpunkt einrichten.

Der Browser sendet Verstoßberichte als JSON-POST-Anfragen. Jeder Bericht enthält die blockierte URI, die verletzte Direktive, die Seite, auf der der Verstoß aufgetreten ist, und andere nützliche Debugging-Informationen. Das Sammeln dieser Berichte über ein oder zwei Wochen in einem Live-Shop gibt Ihnen ein umfassendes Bild aller Ressourcen, die Ihr Shop lädt, und woher sie stammen.

Ihre initiale Richtlinie erstellen

Erstellen Sie anhand der Verstoßberichte aus dem Report-Only-Modus eine Whitelist aller legitimen Ressourcenquellen. Gruppieren Sie sie nach Direktiventyp. Ihre initiale Richtlinie wird wahrscheinlich umfassen:

Ihre eigene Domain für alle Ressourcentypen. CDN-Domains (wie cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) für Skripte, Stile und Schriftarten. Analytics-Domains (wie google-analytics.com, googletagmanager.com, connect.facebook.net) für Tracking. Zahlungsgateway-Domains für Skripte, Frames und Verbindungen. Chat-Widget-Domains, wenn Sie Live-Chat verwenden. Social-Media-Domains für eingebettete Inhalte oder Teilen-Buttons.

Eine CSP für PrestaShop erstellen

PrestaShop stellt spezifische Herausforderungen für die CSP-Implementierung aufgrund seiner Architektur und des Modul-Ökosystems dar.

Umgang mit Inline-Stilen und -Skripten

PrestaShop-Kern, Themes und viele Module verwenden Inline-Stile und Inline-JavaScript umfangreich. Inline-Code wird standardmäßig in CSP blockiert, da ein Angreifer, der Inhalte in Ihre Seite injiziert, Inline-Code injizieren würde. Es gibt drei Ansätze, um damit umzugehen:

'unsafe-inline' verwenden: Der einfachste, aber am wenigsten sichere Ansatz. Das Hinzufügen von 'unsafe-inline' zu script-src und style-src erlaubt allen Inline-Code, was den XSS-Schutz von CSP erheblich schwächt. Für style-src ist dies im Allgemeinen akzeptabel, da Inline-Stile ein viel geringeres Sicherheitsrisiko darstellen als Inline-Skripte. Für script-src vermeiden Sie 'unsafe-inline' wenn irgend möglich.

Nonces verwenden: Der empfohlene Ansatz. Ein Nonce ist ein zufälliges, einmalig verwendetes Token, das bei jeder Anfrage generiert wird. Sie fügen den Nonce zu Ihrem CSP-Header (script-src 'nonce-abc123') und zu jedem legitimen Inline-Script-Tag (<script nonce="abc123">) hinzu. Der Browser führt nur Inline-Skripte mit dem korrekten Nonce aus. Da sich der Nonce bei jeder Anfrage ändert und ein Angreifer ihn nicht vorhersagen kann, werden injizierte Skripte ohne Nonce blockiert.

Die Implementierung von Nonces in PrestaShop erfordert die Änderung des Themes, um Nonce-Attribute zu allen Inline-Script-Tags hinzuzufügen, und die Erstellung eines Mechanismus (typischerweise ein Modul oder ein benutzerdefinierter Hook), der den Nonce generiert, ihn zum CSP-Header hinzufügt und ihn für Templates verfügbar macht. Dies ist ein erheblicher Implementierungsaufwand, bietet aber starken XSS-Schutz.

Hashes verwenden: Sie können bestimmte Inline-Skripte über ihren SHA-256-Hash whitelisten. Der Browser berechnet den Hash jedes Inline-Skripts und vergleicht ihn mit den im CSP aufgelisteten Hashes. Dieser Ansatz funktioniert für Inline-Skripte, die sich zwischen Anfragen nicht ändern (statische Inline-Skripte), ist aber für PrestaShop unpraktisch, da viele Inline-Skripte dynamische Inhalte wie Produkt-IDs, Preise und benutzerspezifische Daten enthalten, die den Hash ändern.

Umgang mit eval und dynamischem Code

Einige JavaScript-Bibliotheken verwenden eval() oder new Function(), um dynamisch Code zu erstellen und auszuführen. CSP blockiert diese standardmäßig. Wenn ein Modul oder eine Bibliothek eval benötigt, müssen Sie 'unsafe-eval' zu script-src hinzufügen. Häufige Verursacher sind ältere Versionen von jQuery-Templates, einige Analytics-Skripte und bestimmte Zahlungsgateway-Bibliotheken.

Prüfen Sie Ihre Verstoßberichte auf Einträge mit eval oder inline als blockierte URI. Diese weisen auf Code hin, der dynamische Auswertung verwendet. Ersetzen Sie die Bibliothek wenn möglich durch eine Version, die eval nicht verwendet. Wenn das nicht möglich ist (z. B. bei einer Zahlungsgateway-Bibliothek eines Drittanbieters, die Sie nicht ändern können), ist 'unsafe-eval' die einzige Option.

Drittanbieter-Dienste

Die meisten PrestaShop-Shops sind auf mehrere Drittanbieter-Dienste angewiesen, die jeweils in Ihrer CSP auf die Whitelist gesetzt werden müssen. Hier sind die häufigsten und die Direktiven, die sie benötigen:

Google Analytics und Google Tag Manager: Diese erfordern Einträge in script-src für www.google-analytics.com, www.googletagmanager.com und tagmanager.google.com. Sie benötigen auch connect-src-Einträge für www.google-analytics.com und analytics.google.com (zum Senden von Tracking-Daten) sowie img-src-Einträge für www.google-analytics.com (für das Tracking-Pixel). Google Tag Manager ist besonders herausfordernd, da er dynamisch Skripte von Domains lädt, die Sie möglicherweise nicht im Voraus kennen, da die geladenen Skripte von den in GTM konfigurierten Tags abhängen.

PayPal: Erfordert script-src- und frame-src-Einträge für *.paypal.com und *.paypalobjects.com. Die genauen Domains hängen davon ab, ob Sie PayPal Standard, PayPal Express oder die neuere PayPal Commerce Platform-Integration verwenden.

Stripe: Erfordert script-src für js.stripe.com, frame-src für js.stripe.com und hooks.stripe.com, sowie connect-src für api.stripe.com.

Google Fonts: Erfordert style-src für fonts.googleapis.com und font-src für fonts.gstatic.com.

YouTube-Einbettungen: Erfordern frame-src für www.youtube.com und www.youtube-nocookie.com.

Facebook Pixel und Social Plugins: Erfordern script-src und connect-src für connect.facebook.net und www.facebook.com, plus img-src für www.facebook.com und *.fbcdn.net.

Live-Chat-Widgets (Tidio, Crisp, Intercom usw.): Jedes hat seinen eigenen Satz von Domains für Skripte, Stile, WebSocket-Verbindungen und Bilder. Prüfen Sie Ihre Verstoßberichte oder die Dokumentation des Anbieters für die genauen erforderlichen Domains.

Ein vollständiges CSP-Beispiel für PrestaShop

Hier ist ein realistischer CSP-Header für einen PrestaShop-Shop, der Google Analytics, Google Fonts, PayPal, YouTube-Einbettungen verwendet und Inline-Stile hat:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

Diese Richtlinie enthält 'unsafe-inline' und 'unsafe-eval' für Skripte, was den XSS-Schutz schwächt, aber für die meisten PrestaShop-Installationen notwendig ist, die nicht für die Unterstützung von Nonces modifiziert wurden. Für img-src ist die data:-Quelle enthalten, da PrestaShop und viele Module Data-URIs für kleine Bilder und Icons verwenden.

CSP in PrestaShop implementieren

Über .htaccess (Apache)

Für Apache-Server fügen Sie den CSP-Header in Ihrer .htaccess-Datei hinzu. Platzieren Sie ihn am Anfang der Datei, vor den PrestaShop-Umschreibungsregeln:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

Dies erfordert, dass das Modul mod_headers aktiviert ist. Sie können überprüfen, ob Ihr Server den Header zurückgibt, indem Sie die Browser-DevTools verwenden (Tab Netzwerk, auf die Hauptdokumentanfrage klicken, Antwort-Header prüfen).

Über Nginx-Konfiguration

Für Nginx fügen Sie den Header in Ihrem Server-Block hinzu:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

Der Parameter always stellt sicher, dass der Header auch für Fehlerantworten gesendet wird, was wichtig ist, da Fehlerseiten ebenfalls Ziele für XSS-Angriffe sein können.

Über ein PrestaShop-Modul

Die Implementierung von CSP über ein Modul gibt Ihnen die Möglichkeit, die Richtlinie vom Back-Office aus zu verwalten. Das Modul hakt sich in den actionOutputHTMLBefore ein oder verwendet PHPs header()-Funktion in einem Front-Controller-Hook, um den CSP-Header zu jeder Antwort hinzuzufügen. Ein modulbasierter Ansatz ist einfacher zu warten, da Sie die Richtlinie aktualisieren können, ohne Serverkonfigurationsdateien zu bearbeiten und ohne den Webserver neu zu starten.

Testen Ihrer CSP mit Browser-DevTools

Verwenden Sie nach der Implementierung Ihrer CSP (zunächst im Report-Only-Modus) die Browser-DevTools, um Verstöße zu überwachen. Öffnen Sie den Konsolen-Tab und suchen Sie nach Nachrichten, die mit "[Report Only]" (im Report-Only-Modus) oder "Refused to" (im Durchsetzungsmodus) beginnen. Jede Nachricht sagt Ihnen genau, was blockiert wurde und welche Direktive verantwortlich war.

Testen Sie jeden Seitentyp in Ihrem Shop: die Startseite, Kategorieseiten, Produktseiten, den Warenkorb, den Checkout-Prozess (einschließlich jedes Schritts und jeder Zahlungsmethode), die Kundenkontoseiten und CMS-Seiten. Jeder Seitentyp kann unterschiedliche Ressourcen laden, und Sie müssen sicherstellen, dass Ihre Richtlinie alle abdeckt.

Achten Sie besonders auf den Checkout-Prozess. Ein blockiertes Zahlungsgateway-Skript oder -Iframe während des Checkouts verhindert direkt, dass Kunden ihre Käufe abschließen. Testen Sie jede Zahlungsmethode, die Sie anbieten, einschließlich des 3D-Secure-Verifizierungsablaufs, falls zutreffend, da diese oft zusätzliche Ressourcen von Domains laden, die nicht offensichtlich sind.

Häufige Testfallen

Tests in einer Entwicklungsumgebung decken möglicherweise nicht alle Verstöße auf, da Ihr Entwicklungs-Setup möglicherweise nicht alle Drittanbieter-Dienste enthält, die in der Produktion laufen (Analytics, Werbepixel, Live-Chat, A/B-Testtools). Stellen Sie CSP immer zuerst im Report-Only-Modus in der Produktion bereit und sammeln Sie mindestens ein bis zwei Wochen lang Berichte, bevor Sie zur Durchsetzung wechseln.

Einige Verstöße treten nur unter bestimmten Bedingungen auf. Zum Beispiel könnte ein Zahlungsgateway zusätzliche Verifizierungsskripte nur laden, wenn die Karte eines Kunden eine 3D-Secure-Authentifizierung erfordert. Social-Sharing-Buttons laden möglicherweise Skripte erst, wenn ein Besucher sie anklickt. Dynamische Inhalte, die über AJAX geladen werden, können Ressourcen referenzieren, die beim initialen Seitenaufruf nicht vorhanden sind. Durchlaufen Sie jeden möglichen Benutzerablauf beim Testen.

Schrittweise Durchsetzungsstrategie

Die empfohlene Bereitstellungsstrategie für CSP auf PrestaShop folgt diesen Schritten:

Phase 1: Erkundung. Stellen Sie einen permissiven Content-Security-Policy-Report-Only-Header mit default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; und einer report-uri bereit. Dies protokolliert alle Ressourcen ohne etwas zu blockieren und gibt Ihnen ein vollständiges Inventar dessen, was Ihr Shop lädt.

Phase 2: Richtlinienentwurf. Basierend auf den Verstoßberichten erstellen Sie eine Whitelist-Richtlinie, die alle legitimen Ressourcen abdeckt. Stellen Sie sie im Report-Only-Modus bereit und überwachen Sie Verstöße, die darauf hinweisen, dass Sie eine Ressource übersehen haben.

Phase 3: Verfeinerung. Prüfen Sie über ein bis zwei Wochen täglich die Verstoßberichte und fügen Sie alle legitimen Quellen hinzu, die Sie übersehen haben. Achten Sie auf Berichte, die von bestimmten Seitentypen oder Benutzerabläufen stammen, die Sie möglicherweise nicht manuell getestet haben.

Phase 4: Durchsetzung. Wechseln Sie von Content-Security-Policy-Report-Only zu Content-Security-Policy. Behalten Sie die report-uri-Direktive bei, damit Sie weiterhin Verstoßberichte erhalten. Überwachen Sie in der ersten Woche nach der Durchsetzung genau, um legitime Ressourcen zu finden, die blockiert werden.

Phase 5: Verschärfung. Sobald die Durchsetzung stabil ist, suchen Sie nach Möglichkeiten, die Richtlinie zu verschärfen. Können Sie 'unsafe-inline' in script-src durch Nonces ersetzen? Können Sie Wildcard-Domains auf bestimmte Subdomains eingrenzen? Können Sie Quellen entfernen, die nicht mehr verwendet werden? Jeder Verschärfungsschritt verbessert Ihre Sicherheitslage.

Pflege Ihrer CSP

Eine CSP ist keine Einmal-und-Vergessen-Konfiguration. Jedes Mal, wenn Sie ein neues Modul installieren, einen Drittanbieter-Dienst hinzufügen, Zahlungsgateways wechseln oder Ihr Theme aktualisieren, müssen Sie möglicherweise Ihre CSP aktualisieren, um neue Ressourcenquellen einzuschließen. Machen Sie die CSP-Überprüfung zum Teil Ihres Modul-Installations- und Aktualisierungsprozesses.

Halten Sie Ihre report-uri auch nach der Durchsetzung aktiv, damit Sie Warnungen über neue Verstöße erhalten. Ein plötzlicher Anstieg der Verstoßberichte könnte darauf hinweisen, dass ein Modul-Update neue Ressourcenanforderungen eingeführt hat, oder es könnte auf einen tatsächlichen XSS-Angriffsversuch hinweisen, den Ihre CSP erfolgreich blockiert. In beiden Fällen möchten Sie davon erfahren.

Dokumentieren Sie Ihre CSP und den Grund für jeden Eintrag. Im Laufe der Zeit sammeln sich Einträge für Dienste an, die Sie nicht mehr nutzen. Regelmäßige Überprüfungen zur Entfernung unnötiger Einträge halten die Richtlinie sauber und reduzieren die Angriffsfläche. Eine CSP mit weniger erlaubten Quellen ist inhärent sicherer als eine mit vielen.

Wie PrestaShop Produktbilder verarbeitet

Jedes Bild, das in PrestaShop hochgeladen wird, durchläuft eine Verarbeitungspipeline. Wenn Sie ein Produktbild hinzufügen, speichert das System die Originaldatei und generiert dann mehrere skalierte Versionen, sogenannte Thumbnails. Jedes Thumbnail entspricht einem Bildtyp, der im Back Office unter Design > Bildeinstellungen definiert ist. Diese Bildtypen legen exakte Pixelabmessungen fest und sind an bestimmte Kontexte gebunden: Produktlisten, Produktseiten, Warenkorb-Vorschauen, Kategorie-Header, Hersteller-Logos und mehr.

PrestaShop speichert Bilder im Verzeichnis /img/. In PrestaShop 1.7 und 8.x werden Produktbilder anhand einer Verzeichnisstruktur organisiert, die auf der Bild-ID basiert. Beispielsweise wird ein Bild mit der ID 1234 unter /img/p/1/2/3/4/ gespeichert. In diesem Verzeichnis finden Sie das Originalbild (benannt nach der ID, wie 1234.jpg) und alle generierten Thumbnails (wie 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

Die Namenskonvention folgt dem Muster: {bild_id}-{bildtyp_name}.{erweiterung}. Das bedeutet, dass jeder von Ihnen definierte Bildtyp eine zusätzliche Datei für jedes Produktbild in Ihrem Katalog erzeugt. Ein Shop mit 5.000 Produktbildern und 8 Bildtypen wird ungefähr 45.000 Bilddateien haben (5.000 Originale plus 5.000 mal 8 Thumbnails). Diese Größenordnung ist relevant, wenn Sie sie regenerieren müssen.

Bildtypen verstehen

Bildtypen werden in der Datenbanktabelle ps_image_type definiert und über das Back Office verwaltet. Jeder Bildtyp hat einen Namen, eine Breite, eine Höhe und Flags, die angeben, auf welche Entitätstypen er angewendet wird (Produkte, Kategorien, Hersteller, Lieferanten, Filialen). Die Standard-PrestaShop-Installation enthält mehrere Bildtypen:

cart_default ist typischerweise 125x125 Pixel groß und wird im Warenkorb und Miniwarenkorb verwendet. small_default liegt bei etwa 98x98 Pixeln und wird in Produktlisten einiger Themes verwendet. medium_default liegt bei etwa 452x452 Pixeln und wird für Produkt-Thumbnails auf der Produktseite verwendet. home_default liegt bei etwa 250x250 Pixeln und wird auf der Startseite und in Kategorielisten verwendet. large_default liegt bei etwa 800x800 Pixeln und wird als Hauptproduktbild auf der Produktseite verwendet.

Themes können ihre eigenen Bildtypanforderungen definieren. Wenn Sie ein neues Theme installieren, registriert es typischerweise seine bevorzugten Bildtypen während der Installation. Der entscheidende Punkt ist, dass die tatsächlichen Bilddateien auf der Festplatte mit dem übereinstimmen müssen, was das Theme erwartet. Wenn das Theme home_default mit 340x340 anfordert, aber Ihre Bilddateien mit 250x250 generiert wurden, weil Sie zuvor ein anderes Theme verwendet haben, wird jede Produktliste falsch dimensionierte Bilder anzeigen.

Wann eine Bildregeneration notwendig ist

Mehrere Situationen erfordern eine vollständige oder teilweise Thumbnail-Regeneration. Zu verstehen, wann sie wirklich notwendig ist, erspart Ihnen einen Prozess, der bei großen Katalogen Stunden dauern kann.

Theme-Wechsel

Dies ist der häufigste Grund. Verschiedene Themes erfordern unterschiedliche Bildabmessungen. Wenn Sie von einem Theme zu einem anderen wechseln, referenzieren die Templates des neuen Themes Bildtypen mit bestimmten Abmessungen. Wenn diese Abmessungen nicht mit den vorhandenen Thumbnail-Dateien übereinstimmen, erscheinen Bilder gestreckt, falsch zugeschnitten oder unscharf. Überprüfen Sie nach der Installation eines neuen Themes immer dessen Bildtypanforderungen und regenerieren Sie die Thumbnails entsprechend.

Änderung der Bildtypabmessungen

Wenn Sie die Breite oder Höhe eines vorhandenen Bildtyps über Design > Bildeinstellungen ändern, betrifft die Änderung nur die Datenbankdefinition. Alle vorhandenen Thumbnail-Dateien auf der Festplatte behalten ihre alten Abmessungen bei. Sie müssen die Thumbnails für den geänderten Bildtyp regenerieren, um die neuen Abmessungen auf bestehende Bilder anzuwenden.

Hinzufügen eines neuen Bildtyps

Wenn Sie einen neuen Bildtyp erstellen, existieren dafür noch keine Thumbnail-Dateien. Wenn ein Template diesen neuen Bildtyp referenziert, werden defekte Bildlinks angezeigt, bis Sie regenerieren. Der Regenerationsprozess erstellt die fehlenden Thumbnail-Dateien für jedes vorhandene Bild.

Bildqualitätsprobleme

Wenn Sie die JPEG-Komprimierungsqualitätseinstellung in PrestaShop ändern (zu finden unter Leistung > Bildeinstellungen oder im Bildkonfigurationsbereich, je nach Version), wurden bestehende Thumbnails mit der alten Qualitätseinstellung generiert. Die Regeneration wendet das neue Qualitätsniveau auf alle Thumbnails an.

Nach einer Migration oder einem Serverwechsel

Manchmal gehen bei einer Migration Thumbnail-Dateien verloren oder werden beschädigt, während Originalbilder erhalten bleiben. Wenn Produktbilder defekt erscheinen, aber Originale in den erwarteten Verzeichnissen existieren, erstellt die Regeneration alle Thumbnails aus den Originalen neu.

Aktivierung des WebP-Formats

PrestaShop 8.x hat WebP-Unterstützung für Produktbilder eingeführt. Wenn Sie die WebP-Generierung aktivieren, erhalten bestehende Bilder nicht automatisch WebP-Varianten. Sie müssen Thumbnails regenerieren, um die .webp-Versionen neben den vorhandenen JPEG- oder PNG-Dateien zu erstellen.

Regeneration über das Admin-Panel

PrestaShop bietet ein integriertes Regenerationstool im Back Office unter Design > Bildeinstellungen (oder Einstellungen > Bilder in älteren Versionen). Am Ende der Seite finden Sie den Regenerationsbereich.

Verfügbare Optionen

Sie können wählen, ob vorherige Bilder vor der Regeneration gelöscht werden sollen. Wenn aktiviert, löscht PrestaShop alle vorhandenen Thumbnails, bevor es neue erstellt. Dies ist nützlich, wenn Sie Thumbnails für Bildtypen entfernen möchten, die nicht mehr existieren, bedeutet aber, dass alle Bilder während des Regenerationsprozesses nicht verfügbar sind. Bei Deaktivierung überschreibt PrestaShop vorhandene Thumbnails und erstellt fehlende, ohne vorher etwas zu löschen.

Sie können wählen, welche Entitätstypen regeneriert werden sollen: Produkte, Kategorien, Hersteller, Lieferanten oder Filialen. Wenn Sie nur Produktbildabmessungen geändert haben, ist es nicht nötig, Kategorie- oder Herstellerbilder zu regenerieren.

Einschränkungen des Admin-Panel-Ansatzes

Die Admin-Panel-Regeneration läuft als Web-Anfrage. Dies schafft bei großen Katalogen mehrere Probleme. Webserver haben Ausführungszeitlimits, typischerweise 30 bis 300 Sekunden, abhängig von Ihrer Konfiguration. Ein Shop mit 10.000 Produktbildern und 8 Bildtypen muss 80.000 Thumbnail-Dateien generieren. Selbst bei großzügigen 10 Bildern pro Sekunde dauert das über zwei Stunden. Die meisten Webserver werden den Prozess lange vorher beenden.

Auch Speicherlimits gelten. Jedes Bild muss in den Arbeitsspeicher geladen, mit GD oder ImageMagick skaliert und gespeichert werden. Hochauflösende Originalbilder können während der Verarbeitung jeweils 20 bis 50 MB Speicher verbrauchen. PHPs Standard-Speicherlimit von 128 MB oder 256 MB kann schnell erschöpft sein, besonders bei sequenzieller Bildverarbeitung ohne ordnungsgemäße Speicherbereinigung.

Wenn der Prozess durch einen Timeout oder Speicherfehler unterbrochen wird, erhalten Sie einen teilweise regenerierten Katalog. Einige Produkte haben neue Thumbnails, andere alte, und manche haben möglicherweise gar keine. Dieser inkonsistente Zustand ist schlimmer als das ursprüngliche Problem.

CLI-Regeneration für große Kataloge

Für Shops mit mehr als ein paar hundert Produkten wird die Kommandozeilen-Regeneration dringend empfohlen. Sie umgeht die Timeout-Limits des Webservers und kann mit höheren Speicherlimits konfiguriert werden.

Verwendung der PrestaShop-Konsole

PrestaShop 1.7.5 und neuer enthält eine Symfony-Konsole. Sie können Thumbnails regenerieren mit:

php bin/console prestashop:image:regenerate

Dieser Befehl akzeptiert mehrere Optionen. Um nur bestimmte Bildtypen zu regenerieren, verwenden Sie das Flag --image-type gefolgt vom Bildtypnamen. Um nur Produkte, Kategorien oder andere bestimmte Entitätstypen zu verarbeiten, verwenden Sie das Flag --entity. Das Flag --format erlaubt Ihnen anzugeben, welche Ausgabeformate generiert werden sollen (jpg, png, webp).

Führen Sie den Befehl aus dem PrestaShop-Stammverzeichnis aus. Wenn Sie Docker verwenden, führen Sie ihn innerhalb des Containers aus:

docker exec -u www-data ihr-container php bin/console prestashop:image:regenerate

Das Flag -u www-data stellt sicher, dass generierte Dateien dem Webserver-Benutzer gehören. Eine Ausführung als Root erstellt Dateien, die der Webserver nicht bereitstellen oder später modifizieren kann.

Speicher- und Zeitkonfiguration

Für die CLI-Ausführung können Sie PHP-Limits direkt im Befehl erhöhen:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Das Setzen von max_execution_time=0 entfernt das Zeitlimit vollständig, und 512 MB Arbeitsspeicher sind für die meisten Kataloge ausreichend. Für Shops mit extrem hochauflösenden Originalen (4000x4000 Pixel oder größer) benötigen Sie möglicherweise 1 GB oder mehr.

Benutzerdefinierter Regenerationsansatz

Für sehr große Kataloge (50.000 oder mehr Bilder) kann selbst der Konsolenbefehl langsam oder problematisch sein. Ein benutzerdefinierter PHP-Ansatz ermöglicht die Verarbeitung von Bildern in Stapeln mit Fortschrittsverfolgung, Fehlerbehandlung und der Möglichkeit, nach einer Unterbrechung fortzufahren.

Der Ansatz beinhaltet das Abfragen der Datenbank nach allen Bilddatensätzen, das Durchlaufen in Stapeln von 100 oder 200, das Generieren von Thumbnails für jedes Bild und das Protokollieren des Fortschritts. Wenn der Prozess unterbrochen wird, können Sie an der Stelle fortfahren, an der er gestoppt wurde, indem Sie prüfen, welche Thumbnails bereits existieren.

Ein Stapelansatz ermöglicht es Ihnen auch, die Regeneration über mehrere Durchläufe während verkehrsarmer Zeiten zu verteilen, um Leistungseinbußen im laufenden Shop zu vermeiden.

WebP-Generierung während der Regeneration

WebP ist ein modernes Bildformat, das bei vergleichbarer Qualität deutlich kleinere Dateigrößen als JPEG bietet. PrestaShop 8.x kann während des Regenerationsprozesses WebP-Versionen der Thumbnails generieren.

WebP-Unterstützung aktivieren

Aktivieren Sie WebP vor der Regeneration in Ihrer PrestaShop-Konfiguration. In PrestaShop 8.x befindet sich diese Option in den Bildeinstellungen. Wenn aktiviert, erstellt der Regenerationsprozess sowohl das traditionelle JPEG/PNG-Thumbnail als auch eine .webp-Version für jeden Bildtyp.

Serveranforderungen

Die WebP-Generierung erfordert entweder die GD-Erweiterung, die mit WebP-Unterstützung kompiliert wurde (--with-webp), oder die ImageMagick-Erweiterung mit WebP-Delegates. Sie können die GD-Unterstützung mit phpinfo() oder gd_info() überprüfen. Suchen Sie in der Ausgabe nach WebP-Unterstützung. Wenn die WebP-Unterstützung fehlt, überspringt der Regenerationsprozess die WebP-Erstellung stillschweigend, ohne Fehler zu erzeugen.

Speicherplatzüberlegungen

WebP-Dateien sind typischerweise 25 bis 35 Prozent kleiner als gleichwertige JPEG-Dateien, aber Sie speichern beide Formate. Ein Shop mit 40.000 JPEG-Thumbnails, die 2 GB Speicherplatz belegen, benötigt nach der WebP-Generierung ungefähr 3,4 GB insgesamt (die ursprünglichen 2 GB plus rund 1,4 GB WebP-Dateien). Planen Sie Ihren Speicherplatz entsprechend, bevor Sie eine vollständige Regeneration starten.

WebP an Browser ausliefern

Das Generieren von WebP-Dateien ist nur die halbe Lösung. Ihr Theme und Server müssen so konfiguriert sein, dass WebP an Browser ausgeliefert wird, die es unterstützen, während ein Fallback auf JPEG/PNG für Browser erfolgt, die es nicht unterstützen. Dies wird typischerweise durch <picture>-Elemente in den Theme-Templates oder durch serverseitige Content-Negotiation mit dem Accept-Header gehandhabt.

In Apache können Sie Rewrite-Regeln hinzufügen, die die WebP-Unterstützung prüfen und die WebP-Version ausliefern, wenn sie verfügbar ist. In Nginx kann die try_files-Direktive nach einer .webp-Version des angeforderten Bildes suchen und sie ausliefern, wenn der Accept-Header des Browsers image/webp enthält.

Leistungsauswirkungen und Gegenmaßnahmen

Die Bildregeneration ist CPU-intensiv und I/O-lastig. In einem laufenden Shop kann sie die Leistung erheblich beeinträchtigen, wenn sie nicht sorgfältig verwaltet wird.

CPU-Auswirkung

Jede Bildskalierung erfordert das Laden des Originals in den Arbeitsspeicher, die Durchführung des Skalierungsalgorithmus, die Anwendung von Qualitäts-/Komprimierungseinstellungen und das Schreiben des Ergebnisses auf die Festplatte. Die Skalierungsoperation selbst ist rechenintensiv, besonders bei großen Bildern, die auf kleine Thumbnails herunterskaliert werden. In einer Shared-Hosting-Umgebung kann dies die CPU auslasten und den gesamten Shop verlangsamen.

I/O-Auswirkung

Die Regeneration liest jedes Originalbild und schreibt mehrere Thumbnail-Dateien. Auf herkömmlichen Festplatten verursacht dies eine erhebliche I/O-Last. Auf SSD-Speicher ist die Auswirkung deutlich geringer, aber im großen Maßstab immer noch spürbar. Das I/O-Muster ist besonders ungünstig für rotierende Festplatten, da es zufällige Lesezugriffe (Originale über Verzeichnisse verteilt) mit sequenziellen Schreibzugriffen (Thumbnails in denselben Verzeichnissen) kombiniert.

Regeneration außerhalb der Stoßzeiten durchführen

Planen Sie die Regeneration für Ihre verkehrsärmste Periode. Für europäische Shops ist dies typischerweise zwischen 2 und 6 Uhr morgens. Für Shops mit globalem Traffic gibt es möglicherweise keine echte verkehrsarme Zeit, aber Sie können relative Tiefpunkte aus Ihren Analysedaten identifizieren.

Nice und Ionice verwenden

Auf Linux-Servern können Sie die Priorität des Regenerationsprozesses senken, damit er anderen Prozessen keine Ressourcen entzieht. Der Befehl nice senkt die CPU-Priorität und ionice senkt die I/O-Priorität:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Ein Nice-Wert von 19 ist die niedrigste Priorität. Ionice-Klasse 3 ist die Leerlauf-Klasse, was bedeutet, dass der Prozess nur I/O-Zeit bekommt, wenn nichts anderes sie benötigt. Dies reduziert die Auswirkung auf den laufenden Shop dramatisch, verlängert aber die Regenerationsdauer.

Temporäre Skalierung

Wenn Sie auf einem Cloud-Server sind, erwägen Sie, Ihren Server vorübergehend hochzuskalieren (mehr CPU-Kerne, mehr RAM, schnellerer Speicher) für die Dauer der Regeneration und dann wieder herunterzuskalieren. Die zusätzlichen Kosten für einige Stunden auf einer höheren Leistungsstufe sind in der Regel minimal im Vergleich zu den Auswirkungen einer langsamen, mehrtägigen Regeneration auf die Leistung Ihres Shops.

Timeouts während der Regeneration vermeiden

Timeouts sind das häufigste Problem bei der Bildregeneration. Hier sind die spezifischen Einstellungen und Konfigurationen, die sie verhindern.

PHP-Konfiguration

Die Direktive max_execution_time begrenzt, wie lange ein PHP-Prozess laufen kann. Für die CLI-Ausführung ist dies typischerweise bereits auf 0 (unbegrenzt) gesetzt, aber überprüfen Sie es mit php -i | grep max_execution_time. Für die webbasierte Regeneration über das Admin-Panel erhöhen Sie diesen Wert in Ihrer php.ini oder .htaccess:

php_value max_execution_time 7200

Erhöhen Sie auch max_input_time, wenn Sie das Admin-Panel verwenden, da der Formularübermittlungs-Timeout vom Ausführungs-Timeout getrennt ist:

php_value max_input_time 7200

Webserver-Timeout

Apaches Timeout-Direktive und Nginx' proxy_read_timeout / fastcgi_read_timeout können lang laufende Anfragen beenden, selbst wenn PHP selbst kein Timeout hatte. Für Apache: Timeout 7200. Für Nginx fügen Sie zu Ihrem Server-Block hinzu: fastcgi_read_timeout 7200; oder proxy_read_timeout 7200;.

PHP-FPM-Konfiguration

Wenn Sie PHP-FPM verwenden (was bei den meisten modernen Setups der Fall ist), kann der request_terminate_timeout in Ihrer Pool-Konfiguration ebenfalls lang laufende Prozesse beenden. Setzen Sie ihn auf 0, um den Timeout zu deaktivieren, oder passen Sie ihn an Ihre gewünschte maximale Laufzeit an:

request_terminate_timeout = 7200

Cloudflare- und CDN-Timeouts

Wenn Ihr Shop hinter Cloudflare oder einem anderen CDN steht, hat das CDN seinen eigenen Anfrage-Timeout (Cloudflares kostenloser Plan hat einen 100-Sekunden-Timeout). Dies macht die Regeneration über das Admin-Panel hinter einem CDN praktisch unmöglich. Sie müssen entweder CLI-Regeneration verwenden, das CDN für den Admin-Zugriff umgehen oder eine Lösung verwenden, die Bilder asynchron verarbeitet.

Inkrementelle Regenerationsstrategien

Die vollständige Regeneration verarbeitet jedes Bild im Katalog. Für Shops mit Zehntausenden von Bildern kann dies viele Stunden dauern. Inkrementelle Ansätze verarbeiten nur die Bilder, die tatsächlich neue Thumbnails benötigen.

Selektive Bildtyp-Regeneration

Wenn Sie nur einen Bildtyp hinzugefügt oder geändert haben, müssen Sie nicht alle Bildtypen regenerieren. Verwenden Sie die Option --image-type im Konsolenbefehl, um nur den spezifischen Bildtyp anzusprechen, der sich geändert hat. Dies reduziert die Arbeit auf ein Achtel (oder den entsprechenden Bruchteil Ihrer gesamten Bildtypen) einer vollständigen Regeneration.

Datumsbasierte Verarbeitung

Wenn Sie Thumbnails nur für kürzlich hinzugefügte Produkte regenerieren müssen (beispielsweise nach der Behebung eines Bildverarbeitungsproblems), können Sie die Datenbank nach Bildern abfragen, die nach einem bestimmten Datum hinzugefügt wurden, und nur diese verarbeiten. Die Tabelle ps_image hat standardmäßig keine Datumsspalte, aber die zugehörige Tabelle ps_product hat die Felder date_add und date_upd, die zur Identifizierung kürzlich geänderter Produkte verwendet werden können.

Erkennung fehlender Thumbnails

Anstatt alles zu regenerieren, scannen Sie die Bildverzeichnisse, um Bilder zu finden, denen bestimmte Thumbnails fehlen, und regenerieren Sie nur diese. Dies ist der schnellste Ansatz, wenn Sie einen neuen Bildtyp hinzugefügt haben oder wenn eine teilweise Regeneration unterbrochen wurde.

Die Logik ist unkompliziert: Für jede Bild-ID in der Datenbank prüfen Sie, ob die erwartete Thumbnail-Datei auf der Festplatte existiert. Wenn nicht, regenerieren Sie nur dieses Thumbnail. Dies verwandelt eine mehrstündige vollständige Regeneration in einen gezielten Prozess, der möglicherweise nur Minuten dauert.

Parallelverarbeitung

Für sehr große Kataloge können Sie den Bild-ID-Bereich in Chunks aufteilen und sie parallel mit mehreren PHP-Prozessen verarbeiten. Ein Prozess verarbeitet beispielsweise Bild-IDs 1 bis 10.000, ein anderer 10.001 bis 20.000 und so weiter. Jeder Prozess läuft unabhängig, und der kombinierte Durchsatz ist in etwa proportional zur Anzahl der parallelen Prozesse (begrenzt durch CPU-Kerne und I/O-Bandbreite).

Seien Sie vorsichtig mit Parallelverarbeitung und Festplatten-I/O. Zu viele gleichzeitige Prozesse auf einer herkömmlichen Festplatte verursachen I/O-Konkurrenz und verlangsamen die Dinge tatsächlich. Auf SSD-Speicher funktionieren 4 bis 8 parallele Prozesse typischerweise gut.

Bildformat-Überlegungen

PrestaShop unterstützt JPEG, PNG und GIF als Quellformate und kann Thumbnails in diesen Formaten plus WebP generieren. Das Quellformat beeinflusst das Regenerationsverhalten.

JPEG-Bilder

JPEG ist das gebräuchlichste Format für Produktfotos. Es unterstützt verlustbehaftete Komprimierung, was bedeutet, dass bei jedem Speichern einer JPEG-Datei etwas Qualität verloren geht. Deshalb liefert die Regeneration von Thumbnails aus originalen Uploads bessere Ergebnisse als die Regeneration aus zuvor skalierten Thumbnails. Stellen Sie immer sicher, dass Sie mit dem ursprünglich hochgeladenen Bild arbeiten, nicht mit einem zuvor generierten Thumbnail.

PNG-Bilder

PNG unterstützt Transparenz und verlustfreie Komprimierung. Wenn Ihre Produktbilder transparente Hintergründe verwenden, bewahren PNG-Thumbnails diese Transparenz. PNG-Dateien sind jedoch typischerweise deutlich größer als JPEG-Dateien. Überlegen Sie, ob Sie tatsächlich Transparenz benötigen. Wenn nicht, kann die Konvertierung von PNG-Produktbildern in JPEG während der Regeneration den Speicherplatz erheblich reduzieren und die Seitenladezeiten verbessern.

GIF-Behandlung

PrestaShop kann GIF-Uploads akzeptieren, aber generierte Thumbnails aus GIF-Quellen sind statisch (keine Animation wird beibehalten). Wenn Sie animierte GIF-Produktbilder haben, beachten Sie, dass die Regeneration statische Thumbnails aus dem ersten Frame erzeugt.

Überprüfung nach der Regeneration

Überprüfen Sie nach Abschluss der Regeneration die Ergebnisse, bevor Sie davon ausgehen, dass alles korrekt ist.

Stichprobenartige Qualitätsprüfung

Öffnen Sie mehrere Produktseiten und überprüfen Sie die Bilder visuell. Stellen Sie sicher, dass Thumbnails scharf, korrekt proportioniert und nicht gestreckt oder verpixelt sind. Achten Sie besonders auf Bilder, die ursprünglich klein waren (nah an oder kleiner als die Thumbnail-Abmessungen), da diese am wahrscheinlichsten Qualitätsprobleme bei der Hochskalierung zeigen.

Dateianzahl-Überprüfung

Vergleichen Sie die Anzahl der generierten Thumbnails mit den Erwartungen. Wenn Sie 5.000 Produktbilder und 8 Bildtypen haben, sollten Sie ungefähr 40.000 Thumbnail-Dateien haben (plus die Originale und möglicherweise WebP-Varianten). Eine deutlich niedrigere Zahl deutet darauf hin, dass der Regenerationsprozess unterbrochen wurde oder bei einigen Bildern auf Fehler gestoßen ist.

Dateiberechtigungsprüfung

Überprüfen Sie, dass die regenerierten Dateien dem Webserver-Benutzer gehören (typischerweise www-data auf Debian/Ubuntu oder apache auf CentOS). Wenn Sie die Regeneration als Root ausgeführt haben, sind die Dateien möglicherweise nicht vom Webserver lesbar, was zu defekten Bildern im Frontend führt. Beheben Sie dies mit: chown -R www-data:www-data img/p/.

Cache leeren

Leeren Sie nach der Regeneration alle Caches. Dies umfasst PrestaShops internen Cache (Erweiterte Einstellungen > Leistung), jeden Opcode-Cache (OPcache) und jeden CDN- oder Reverse-Proxy-Cache. Alte gecachte Seiten referenzieren möglicherweise noch alte Bild-URLs oder -Abmessungen. Wenn Sie ein Modul verwenden, das CSS-Sprites oder Inline-Bilder generiert, regenerieren Sie auch diese.

Wenn Ihr Shop hinter Cloudflare steht, leeren Sie den Cache für den Pfad /img/ oder führen Sie eine vollständige Cache-Bereinigung durch. Cloudflare cachet Bilder aggressiv, und Besucher sehen möglicherweise alte Thumbnails, bis der CDN-Cache abläuft oder bereinigt wird.

Fehlerbehebung bei häufigen Regenerationsproblemen

Schwarze oder beschädigte Thumbnails

Dies deutet normalerweise auf ein GD-Bibliotheksproblem hin. Die GD-Erweiterung unterstützt möglicherweise das Quellformat nicht (zum Beispiel GD kompiliert ohne JPEG-Unterstützung). Überprüfen Sie die GD-Fähigkeiten mit gd_info(). Eine weitere Ursache ist unzureichender Arbeitsspeicher: Wenn PHP nicht genug Speicher zum Laden des Originalbildes zuweisen kann, erzeugt GD möglicherweise ein schwarzes Bild, anstatt einen Fehler auszulösen.

Falsche Abmessungen in generierten Thumbnails

Wenn Thumbnails unerwartete Abmessungen haben, überprüfen Sie die Bildtypdefinitionen in der Datenbank. Das Admin-Panel zeigt möglicherweise einen Wert an, während die Datenbank einen anderen enthält (dies kann nach einem fehlgeschlagenen Import oder einer manuellen Datenbankänderung auftreten). Fragen Sie direkt ab: SELECT * FROM ps_image_type WHERE name = 'home_default';

Regeneration hängt ohne Fortschritt

Ein hängender Regenerationsprozess bedeutet normalerweise, dass er auf ein sehr großes Bild gestoßen ist, das den verfügbaren Speicher erschöpft hat. Prüfen Sie das PHP-Fehlerprotokoll auf Speicherzuweisungsfehler. Die Lösung besteht darin, das Speicherlimit zu erhöhen oder die problematischen Quellbilder vor der Regeneration vorab zu verarbeiten, um ihre Auflösung zu reduzieren.

Zugriffsverweigerungsfehler

Wenn die Regeneration Berechtigungsfehler meldet, kann der PHP-Prozess nicht in die Bildverzeichnisse schreiben. Dies passiert häufig in Docker-Umgebungen, in denen bind-gemountete Volumes innerhalb und außerhalb des Containers unterschiedliche Eigentumsrechte haben. Stellen Sie sicher, dass der Benutzer, der den Regenerationsbefehl ausführt, Schreibzugriff auf den gesamten Verzeichnisbaum /img/ hat.

Zusammenfassung

Die Bildregeneration ist eine Wartungsaufgabe, auf die jeder PrestaShop-Shopbetreiber stößt, meist bei einem Theme-Wechsel oder bei der Optimierung der Bildeinstellungen. Für kleine Kataloge (unter 500 Produkte) funktioniert das Admin-Panel-Tool ausreichend. Für alles darüber hinaus ist die CLI-Regeneration der einzig zuverlässige Ansatz. Die grundlegenden Prinzipien sind: immer mit Originalbildern arbeiten, die Bildtypdefinitionen an die Anforderungen Ihres Themes anpassen, Serverressourcen und Timeouts proaktiv verwalten, wo möglich inkrementelle Ansätze verwenden und die Ergebnisse nach Abschluss des Prozesses überprüfen. Da WebP zum Standard für Webbilder wird, dient die Regeneration auch als Mechanismus, um moderne Formatvarianten Ihres gesamten Produktkatalogs zu erstellen und Ihren Kunden kleinere Dateigrößen und schnellere Seitenladezeiten zu liefern.

Was Varnish ist und warum es für PrestaShop wichtig ist

Varnish Cache ist ein HTTP-Reverse-Proxy, der zwischen Ihrem Webserver und dem Internet sitzt und gecachte Kopien von Seiten ausliefert, ohne jemals PHP oder MySQL zu berühren. Wenn ein Besucher eine Seite anfordert, die Varnish zwischengespeichert hat, kommt die Antwort direkt aus dem Arbeitsspeicher – in Mikrosekunden. PHP wird nicht ausgeführt. MySQL erhält keine Abfrage. Der Webserver bemerkt die Anfrage kaum.

Dies unterscheidet sich grundlegend von der Funktionsweise PHP-basierter Full Page Cache (FPC) Module in PrestaShop. Ein FPC-Modul läuft weiterhin innerhalb von PHP. Die Anfrage trifft auf Apache oder Nginx, PHP startet, PrestaShop initialisiert sich (Konfiguration laden, Datenbankverbindungen aufbauen, Routen parsen), und dann fängt das FPC-Modul die Anfrage ab, bevor die vollständige Controller-Logik ausgeführt wird, und liefert eine gecachte HTML-Datei. Dies ist zwar deutlich schneller als die Seite von Grund auf zu rendern, beinhaltet aber immer noch den Start von PHP und das Laden des PrestaShop-Frameworks. Dieser Overhead von typischerweise 50–200 Millisekunden selbst bei einem Cache-Hit summiert sich unter Last.

Varnish eliminiert diesen Overhead vollständig. Ein Varnish-Cache-Hit wird in 1–5 Millisekunden ausgeliefert. Bei hohem Traffic ist der Unterschied dramatisch. Ein PrestaShop-Shop, der mit einem FPC-Modul Schwierigkeiten hat, 100 gleichzeitige Benutzer zu bedienen, kann mit Varnish Tausende von gleichzeitigen Benutzern versorgen, da die überwiegende Mehrheit der Anfragen das PHP-Backend überhaupt nicht erreicht.

Wann PHP Full Page Cache Module ausreichend sind

Bevor Sie in Varnish investieren, lohnt es sich zu verstehen, wann ein PHP-basiertes FPC-Modul ausreicht. Für viele PrestaShop-Shops ist das der Fall.

Wenn Ihr Shop weniger als 50.000 tägliche Seitenaufrufe verzeichnet, wird ein gut konfiguriertes FPC-Modul die Last problemlos bewältigen. Die zusätzliche Komplexität von Varnish ist nicht gerechtfertigt, wenn Ihr Server über Reservekapazität verfügt. Wenn Ihre Server-Antwortzeiten mit FPC konstant unter 200 Millisekunden liegen, erhalten Ihre Besucher bereits schnelle Seitenladezeiten. Der Engpass liegt an diesem Punkt wahrscheinlich beim Frontend-Rendering (CSS, JavaScript, Bilder) und nicht bei der Serverantwortzeit.

FPC-Module handhaben einige PrestaShop-spezifische Szenarien auch eleganter als Varnish, da sie innerhalb der Anwendung laufen. Sie können prüfen, ob ein Benutzer eingeloggt ist, ob der Warenkorb Artikel enthält und ob bestimmte dynamische Inhalte personalisiert werden müssen – alles innerhalb desselben PHP-Prozesses. Bei Varnish müssen diese Prüfungen über Cookie-Inspektion und Cache-Variationsregeln gehandhabt werden, was die Konfigurationskomplexität erhöht.

Ziehen Sie Varnish in Betracht, wenn Ihr Shop regelmäßig mit Traffic-Spitzen konfrontiert ist (Flash-Sales, Marketingkampagnen, saisonale Spitzen), die Ihre PHP-Kapazität überlasten, wenn Sie aus SEO- oder User-Experience-Gründen Antwortzeiten unter 10 ms benötigen, wenn Ihr Hosting-Budget begrenzt ist und Sie mehr Traffic mit derselben Hardware bedienen müssen, oder wenn Ihr Shop einen hohen Anteil an anonymem Browsing-Traffic (Kategorieseiten, Produktseiten) im Verhältnis zur Warenkorb- und Checkout-Aktivität aufweist.

Wie Varnish funktioniert: Der Request-Flow

Das Verständnis des Anfrage-Flows durch Varnish ist wesentlich für die korrekte Konfiguration mit PrestaShop.

Anfrage kommt an

Wenn ein Besucher eine Seite anfordert, trifft die Anfrage zuerst auf Varnish (Varnish lauscht auf Port 80 oder 443, wenn es durch einen Frontend-Proxy terminiert wird). Varnish untersucht die Anfrage: die URL, die HTTP-Methode, die Cookies und die Header.

Cache-Lookup

Varnish prüft seinen Cache auf eine gespeicherte Antwort, die zu dieser Anfrage passt. Der Cache-Schlüssel basiert typischerweise auf der URL und ausgewählten Headern. Wenn eine passende Antwort existiert und nicht abgelaufen ist, liefert Varnish sie direkt aus. Dies ist ein Cache-Hit. Die Antwort wird an den Besucher gesendet, und der Backend-Server wird niemals kontaktiert.

Cache-Miss

Wenn keine passende gecachte Antwort existiert, leitet Varnish die Anfrage an den Backend-Server weiter (Apache oder Nginx, auf dem PrestaShop läuft). PrestaShop verarbeitet die Anfrage normal, generiert die HTML-Antwort und sendet sie an Varnish zurück. Varnish speichert die Antwort in seinem Cache (wenn die Antwort cache-fähig ist) und leitet sie an den Besucher weiter. Nachfolgende Anfragen für dieselbe Seite werden aus dem Cache bedient.

Cache-Invalidierung

Wenn sich Produktdaten ändern, Preise aktualisiert werden oder Inhalte modifiziert werden, wird die gecachte Version veraltet. Varnish muss angewiesen werden, die alte gecachte Version zu verwerfen, damit es eine frische vom Backend holt. Das ist die Cache-Invalidierung, und sie ist der schwierigste Teil jedes Caching-Systems, um ihn richtig hinzubekommen.

VCL-Konfiguration für PrestaShop

Varnish Configuration Language (VCL) ist eine domänenspezifische Sprache, die steuert, wie Varnish Anfragen behandelt. Eine ordnungsgemäße VCL-Konfiguration für PrestaShop muss mehrere PrestaShop-spezifische Verhaltensweisen berücksichtigen.

Backend-Definition

Die Backend-Definition teilt Varnish mit, wohin Cache-Misses weitergeleitet werden sollen. Für ein typisches PrestaShop-Setup, bei dem Apache oder Nginx auf demselben Server auf Port 8080 läuft:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

Die Timeouts sind wichtig. PrestaShop-Seiten können bei einem kalten Cache mehrere Sekunden zur Generierung benötigen, insbesondere Kategorieseiten mit vielen Produkten. Ein zu niedriger first_byte_timeout-Wert führt dazu, dass Varnish einen 503-Fehler zurückgibt, bevor PrestaShop die Seitengenerierung abgeschlossen hat.

Umgang mit Cookies und Sitzungen

Cookies sind die größte Herausforderung beim Caching von PrestaShop mit Varnish. PrestaShop setzt standardmäßig mehrere Cookies, und Varnish behandelt jede Anfrage mit Cookies als nicht cache-fähig, sofern nicht anders angewiesen. Wenn Sie Cookies in Ihrer VCL nicht behandeln, wird Varnish fast nichts cachen.

PrestaShop setzt bei den meisten Anfragen folgende Cookies: das Sitzungs-Cookie (typischerweise PrestaShop-xxxx genannt), die warenkorbebezogenen Cookies, Google Analytics Cookies (_ga, _gid, _gat) und verschiedene Tracking-Cookies von Marketing-Tools. Von diesen ist nur das PrestaShop-Sitzungs-Cookie für das Cache-Verhalten relevant. Analytics- und Tracking-Cookies sollten vor dem Cache-Lookup aus der Anfrage entfernt werden, damit sie das Caching nicht verhindern.

In Ihrer VCL-Subroutine vcl_recv entfernen Sie nicht-essentielle Cookies:

sub vcl_recv {
  # Google Analytics und andere Tracking-Cookies entfernen
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Leeren Cookie-Header entfernen
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Entscheidung, was gecacht werden soll

Nicht jede PrestaShop-Seite sollte gecacht werden. Die VCL muss zwischen cache-fähigen und nicht cache-fähigen Anfragen unterscheiden.

Immer cachen: Produktseiten für anonyme Besucher, Kategorielistenseiten, CMS-Seiten (Über uns, AGB, Kontakt), die Startseite, Hersteller- und Lieferantenseiten, Sitemap-Seiten.

Niemals cachen: Die Warenkorbseite, Checkout-Seiten (alle Schritte), den Kundenkontobereich (Bestellungen, Adressen, persönliche Informationen), die Login- und Registrierungsseiten, jede Seite für einen eingeloggten Kunden, POST-Anfragen, AJAX-Anfragen, die den Zustand verändern (zum Warenkorb hinzufügen, Menge aktualisieren).

Die VCL-Logik hierfür prüft typischerweise den URL-Pfad und das Vorhandensein von Sitzungs-Cookies:

sub vcl_recv {
  # POST-Anfragen nicht cachen
  if (req.method == "POST") {
    return (pass);
  }
  # Admin-Bereich nicht cachen
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Checkout und Warenkorb nicht cachen
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Nicht cachen, wenn der Kunde Artikel im Warenkorb hat
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Cache-Dauer festlegen

In der Subroutine vcl_backend_response steuern Sie, wie lange Varnish jede Antwort cachet. PrestaShop sendet Cache-Control-Header, die typischerweise no-cache oder private lauten, da es davon ausgeht, dass jede Antwort personalisierten Inhalt enthalten könnte. Sie müssen diese für Seiten überschreiben, von denen Sie wissen, dass sie sicher gecacht werden können:

sub vcl_backend_response {
  # Produkt- und Kategorieseiten für 1 Stunde cachen
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Statische Assets für 1 Tag cachen
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Das Entfernen von Set-Cookie aus gecachten Antworten ist kritisch. Wenn eine gecachte Antwort einen Set-Cookie-Header enthält, wird Varnish sie standardmäßig nicht cachen, und selbst wenn es zum Cachen gezwungen wird, würde es dasselbe Sitzungs-Cookie für jeden Besucher setzen, was zu Session-Hijacking führt.

Cache-Invalidierung mit PURGE-Anfragen

Wenn sich ein Produktpreis ändert, ein neues Produkt hinzugefügt wird oder Inhalte aktualisiert werden, muss die gecachte Version invalidiert werden. Varnish unterstützt PURGE-Anfragen: eine spezielle HTTP-Methode, die Varnish anweist, eine bestimmte URL aus seinem Cache zu entfernen.

PURGE-Unterstützung konfigurieren

Fügen Sie die PURGE-Behandlung Ihrer VCL hinzu:

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Nicht erlaubt."));
    }
    return (purge);
  }
}

Die ACL beschränkt PURGE-Anfragen auf localhost und verhindert, dass externe Benutzer Ihren Cache leeren.

Purges von PrestaShop aus auslösen

PrestaShop sendet von Haus aus keine PURGE-Anfragen. Sie benötigen ein Modul oder einen benutzerdefinierten Hook, der erkennt, wann sich cache-fähiger Inhalt ändert, und eine PURGE-Anfrage an Varnish sendet. Das Modul hängt sich in PrestaShop-Ereignisse wie actionProductUpdate, actionCategoryUpdate und actionCMSPageUpdate ein. Wenn diese Ereignisse ausgelöst werden, sendet das Modul eine HTTP-PURGE-Anfrage an die entsprechende URL auf dem Varnish-Server.

Bei einem Produktupdate würde das Modul die Produkt-URL, die Kategorie-URLs, zu denen das Produkt gehört (da Kategorielistenseiten Produktpreise und Verfügbarkeit anzeigen), und möglicherweise die Startseite purgen, wenn sie empfohlene Produkte anzeigt. Diese Kaskade von Purges ist notwendig, um zu verhindern, dass veraltete Daten irgendwo auf der Website erscheinen.

Ban-basierte Invalidierung

Für Szenarien, in denen viele URLs auf einmal gepurgt werden müssen (eine seitenweite Preisaktualisierung, eine Designänderung, ein neues Werbebanner), sind einzelne PURGE-Anfragen unpraktisch. Varnish unterstützt Bans, die musterbasierte Invalidierungsregeln sind. Ein Ban weist Varnish an, jedes gecachte Objekt zu verwerfen, das einem Muster entspricht:

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Nicht erlaubt."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Gebannt."));
  }
}

Das Senden einer BAN-Anfrage mit dem Header X-Ban-Pattern: /category/ würde alle gecachten Kategorieseiten in einer einzigen Operation invalidieren.

Edge Side Includes (ESI) für dynamische Blöcke

Viele PrestaShop-Seiten enthalten eine Mischung aus statischem und dynamischem Inhalt. Die Produktliste auf einer Kategorieseite ist für jeden Besucher gleich, aber die Kopfzeile mit der Warenkorbanzahl ist personalisiert. Ohne ESI können Sie die Seite überhaupt nicht cachen, da der dynamische Header die gesamte Antwort besucherspezifisch macht.

Edge Side Includes lösen dieses Problem, indem sie es ermöglichen, Abschnitte der Seite als separate Fragmente zu markieren, die einzeln abgerufen werden. Varnish setzt die endgültige Seite aus gecachten und ungecachten Fragmenten zusammen.

Wie ESI funktioniert

In Ihrem Smarty-Template fügen Sie statt des direkten Renderns des Warenkorb-Widgets ein ESI-Tag ein:

<esi:include src="/module/cartwidget/ajax" />

Wenn Varnish die gecachte Seite verarbeitet, trifft es auf das ESI-Tag und stellt eine separate Backend-Anfrage für dieses Fragment. Der Hauptseitenkörper wird aus dem Cache geliefert, während das Warenkorb-Widget frisch von PrestaShop geholt wird. Die zusammengesetzte Antwort enthält sowohl den gecachten Body als auch das frische Warenkorb-Widget.

Aktivieren Sie die ESI-Verarbeitung in Ihrer VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

ESI-Überlegungen für PrestaShop

Die Implementierung von ESI erfordert die Modifikation Ihrer PrestaShop-Templates, um dynamische Inhalte in ESI-kompatible Fragmente zu trennen. Jedes Fragment benötigt seinen eigenen URL-Endpunkt, der nur das HTML für diesen Block zurückgibt. Die Fragmente, die typischerweise dynamisch sind und eine ESI-Behandlung benötigen, umfassen das Warenkorb-Zusammenfassungs-Widget (Artikelanzahl, Gesamtbetrag), die Kundenbegrüßung ("Hallo, Max"), personalisierte Produktempfehlungen, den Login-/Logout-Link und kürzlich angesehene Produkte.

Der Aufwand für eine ordnungsgemäße ESI-Implementierung ist erheblich. Jedes dynamische Fragment benötigt einen eigenen Controller, die Templates müssen umstrukturiert werden, und die Caching-Regeln für jedes Fragment müssen individuell angepasst werden. Dies ist einer der Gründe, warum Varnish als fortgeschrittene Optimierung gilt – es funktioniert am besten, wenn die Anwendung damit im Hinterkopf entwickelt wurde.

Backend Health Checks

Varnish kann den Zustand Ihres Backend-Servers überwachen und Maßnahmen ergreifen, wenn dieser nicht mehr verfügbar ist. Dies wird in der Backend-Definition konfiguriert:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish sendet alle 5 Sekunden eine Anfrage an /ping.php. Wenn 3 von den letzten 5 Prüfungen fehlschlagen, markiert Varnish das Backend als krank. Solange das Backend krank ist, kann Varnish veralteten gecachten Inhalt ausliefern (Grace-Modus), anstatt Fehler an die Besucher zurückzugeben. Das bedeutet, dass Ihr Shop teilweise verfügbar bleibt, selbst wenn das PHP-Backend abstürzt oder neu gestartet wird.

Die Grace-Modus-Konfiguration bestimmt, wie lange Varnish veralteten Inhalt ausliefert:

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Mit einer 6-stündigen Grace-Periode, wenn Ihr Backend ausfällt, sehen Besucher gecachte Seiten (auch wenn sie bis zu 6 Stunden alt sind) statt Fehlerseiten. Produktpreise könnten leicht veraltet sein, aber der Shop bleibt funktionsfähig, während Sie das Backend-Problem beheben.

Performance-Benchmarks

Der Leistungsunterschied zwischen keinem Cache, PHP-FPC und Varnish ist erheblich und messbar.

Ohne Cache (pures PrestaShop): Eine typische PrestaShop-Produktseite benötigt 200–800 Millisekunden zur Generierung, abhängig von der Server-Hardware, der Anzahl geladener Module und der Datenbankabfragenanzahl. Unter Last steigen die Antwortzeiten, da PHP-Worker ausgelastet sind. Ein einzelner Server kann 20–50 gleichzeitige Benutzer bedienen, bevor die Antwortzeiten inakzeptabel werden.

PHP-FPC-Modul: Cache-Hits werden in 30–100 Millisekunden bedient, da PHP immer noch startet und das Framework teilweise initialisiert wird. Unter Last ist die Leistung deutlich besser, da gecachte Antworten minimale PHP-Verarbeitungszeit erfordern. Ein einzelner Server kann 200–500 gleichzeitige Benutzer bedienen, abhängig von der Konfiguration. Cache-Misses benötigen weiterhin die volle Renderzeit.

Varnish: Cache-Hits werden in 1–5 Millisekunden bedient. Unter Last kann Varnish selbst Tausende von gleichzeitigen Verbindungen verarbeiten, da es in C geschrieben und speziell für diese Aufgabe konzipiert ist. Der Backend-Server verarbeitet nur Cache-Misses, die bei einem richtig konfigurierten System einen kleinen Bruchteil des gesamten Traffics ausmachen. Dieselbe Hardware, die ohne Caching mit 50 gleichzeitigen Benutzern kämpft, kann mit Varnish 5.000 oder mehr bedienen.

Diese Zahlen verdeutlichen, warum Varnish die Konfigurationskomplexität für hochfrequentierte Shops wert ist. Die Leistungsverbesserung ist nicht inkrementell – sie ist eine Größenordnung.

Hosting-Anforderungen

Varnish hat spezifische Hosting-Anforderungen, die nicht jede PrestaShop-Hosting-Umgebung erfüllen kann.

Serverzugriff

Sie benötigen Root-Zugriff, um Varnish zu installieren und zu konfigurieren. Shared-Hosting-Pläne unterstützen Varnish nicht, da es einen eigenen Prozess erfordert, der auf einem Port lauscht und den gesamten HTTP-Traffic abfängt. Sie benötigen einen VPS, einen dedizierten Server oder eine Cloud-Instanz, bei der Sie den gesamten Server-Stack kontrollieren.

Arbeitsspeicher

Varnish speichert seinen Cache im RAM. Die Menge an RAM, die Sie benötigen, hängt von der Anzahl der einzigartigen Seiten in Ihrem Katalog und der Größe jeder gecachten Antwort ab. Eine grobe Formel: Anzahl der cache-fähigen Seiten multipliziert mit der durchschnittlichen Seitengröße ergibt die minimale Cache-Größe. Ein Shop mit 5.000 Produkten, 200 Kategorien und einer durchschnittlichen Seitengröße von 50 KB benötigt ungefähr 260 MB Cache-RAM. Fügen Sie Overhead für Varnish selbst hinzu, und Sie sollten mindestens 512 MB zuweisen. Für größere Kataloge sind 1–2 GB üblich.

Port-Konfiguration

In einem Standard-Setup lauscht Varnish auf Port 80 (dem Standard-HTTP-Port) und leitet Cache-Misses an den Webserver auf einem anderen Port weiter (üblicherweise 8080). Das bedeutet, dass Sie Apache oder Nginx so umkonfigurieren müssen, dass es auf Port 8080 statt auf 80 lauscht. Wenn Sie HTTPS verwenden (und das sollten Sie), setzen Sie typischerweise Nginx vor Varnish, um die SSL-Terminierung zu handhaben: Nginx auf Port 443 terminiert SSL und leitet an Varnish auf Port 80 weiter, das Cache-Misses an Apache oder PHP-FPM auf Port 8080 weiterleitet.

Docker-Setup-Beispiel

Varnish in Docker neben einem PrestaShop-Container auszuführen, ist eine saubere Methode, Varnish zu einem bestehenden Setup hinzuzufügen, ohne das Hostsystem zu modifizieren.

Docker Compose Konfiguration

Ein grundlegendes Docker Compose Setup mit Varnish, Nginx für SSL und PrestaShop:

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

In diesem Setup ist Varnish der Eintrittspunkt auf Port 80. Der PrestaShop-Container exponiert seinen Port nicht an den Host, sondern nur ans Docker-Netzwerk. Der VCL-Backend-Host wäre prestashop (der Docker-Servicename) auf Port 80.

VCL für Docker

Die VCL-Backend-Definition für Docker verwendet den Servicenamen statt localhost:

backend default {
  .host = "prestashop";
  .port = "80";
}

Dockers internes DNS löst den Servicenamen zur Container-IP auf. Der Rest der VCL-Konfiguration bleibt identisch zu einem Nicht-Docker-Setup.

Cache-Speicher in Docker

Standardmäßig verwendet das Varnish Docker Image In-Memory-Speicher (malloc), was ideal für die Leistung ist. Die Umgebungsvariable VARNISH_SIZE steuert, wie viel Speicher Varnish für seinen Cache reserviert. Setzen Sie diesen Wert auf einen Wert, der in die Speicherlimits Ihres Containers passt, wobei Platz für den Varnish-Prozess selbst übrig bleiben sollte.

Für persistenten Cache, der Container-Neustarts übersteht, können Sie dateibasierten Speicher verwenden, indem Sie ein Volume mounten, aber das ist selten notwendig. Der Cache wärmt sich schnell auf (innerhalb von Minuten nach Empfang von Traffic), und dateibasierter Speicher ist langsamer als speicherbasierter Speicher.

Überwachung der Varnish-Performance

Varnish bietet integrierte Werkzeuge zur Überwachung der Cache-Performance.

Der Befehl varnishstat zeigt Echtzeit-Statistiken an, einschließlich Cache-Trefferquote, Backend-Verbindungen und Speichernutzung. Die wichtigste Metrik ist die Trefferquote, die bei einem gut konfigurierten Setup 85 % oder höher sein sollte. Wenn Ihre Trefferquote unter 70 % liegt, überprüfen Sie Ihre VCL-Regeln, da zu viele Anfragen zum Backend durchgeleitet werden.

Der Befehl varnishlog zeigt detaillierte Logs pro Anfrage, die unschätzbar wertvoll für das Debugging sind, warum bestimmte Anfragen nicht gecacht werden. Sie können nach URL-Muster, Antwortcode oder Cache-Hit/Miss-Status filtern.

Der Befehl varnishtop zeigt eine Rangliste der häufigsten Log-Einträge und hilft Ihnen, Muster bei Cache-Misses oder Fehlern zu identifizieren.

Häufige Fallstricke

Vergessen, Cookies zu entfernen

Die häufigste Varnish-Fehlkonfiguration mit PrestaShop ist das Nicht-Entfernen von Analytics- und Tracking-Cookies. Diese Cookies sind bei praktisch jeder Anfrage vorhanden und machen jede Anfrage aus Varnish' Perspektive einzigartig, was zu einer Trefferquote von 0 % führt. Entfernen Sie immer Cookies, die Sie nicht für die Cache-Variation benötigen.

Personalisierte Inhalte cachen

Wenn Ihre VCL zu aggressiv ist, wird sie Seiten cachen, die personalisierte Inhalte enthalten (Begrüßung des eingeloggten Benutzers, Warenkorbinhalte) und diese anderen Besuchern ausliefern. Dies verursacht schwerwiegende Usability-Probleme und potenzielle Datenschutzprobleme. Leiten Sie Anfragen mit Sitzungs-Cookies immer an das Backend weiter.

Keine Invalidierung bei Inhaltsänderungen

Ohne einen ordnungsgemäßen Purging-Mechanismus werden Inhaltsänderungen im Back Office nicht sichtbar, bis gecachte Seiten natürlich ablaufen. Für einen Shop mit aktivem Bestandsmanagement bedeutet dies, dass Besucher möglicherweise vergriffene Produkte, falsche Preise oder veraltete Beschreibungen sehen. Implementieren Sie PURGE- oder BAN-Unterstützung und integrieren Sie sie mit den Update-Hooks von PrestaShop.

HTTPS ignorieren

Varnish unterstützt SSL nicht nativ. Sie müssen einen SSL-terminierenden Proxy (Nginx, HAProxy oder einen Cloud Load Balancer) vor Varnish setzen. Wenn Sie dies in Ihrer Architektur nicht einplanen, führt dies zu Mixed-Content-Problemen, Weiterleitungsschleifen oder der Unfähigkeit, HTTPS-Traffic überhaupt zu bedienen.

Ist Varnish das Richtige für Ihren Shop

Varnish ist ein leistungsstarkes Werkzeug, aber nicht die richtige Wahl für jeden PrestaShop-Shop. Es fügt betriebliche Komplexität hinzu: einen weiteren Dienst zum Überwachen, eine weitere Konfigurationssprache zum Erlernen, eine weitere Schicht in Ihrem Debugging-Prozess. Die Vorteile sind klar und messbar für Shops, die sie benötigen, aber sie kommen auf Kosten von Einrichtungszeit, Wartung und Schwierigkeit bei der Fehlerbehebung.

Wenn Ihr Shop weniger als 50.000 Seitenaufrufe pro Tag verzeichnet und Ihr Server die Last mit einem FPC-Modul komfortabel bewältigt, ist Varnish unnötige Komplexität. Wenn Ihr Shop regelmäßig Traffic-Spitzen erlebt, die Ihren Server überlasten, ein hohes Volumen an anonymem Browsing-Traffic bedient oder die schnellstmöglichen Antwortzeiten für SEO oder Benutzererfahrung benötigt, bietet Varnish ein Leistungsniveau, das keine PHP-basierte Caching-Lösung erreichen kann.

Beginnen Sie mit einer ordnungsgemäßen PrestaShop-Optimierung (Abfrageoptimierung, Modul-Audit, PHP OPcache, Bildoptimierung) und einem FPC-Modul. Wenn diese Optimierungen nicht ausreichen, ist Varnish der nächste Schritt auf der Performance-Skalierungsleiter.