Zendesk Chat-Integration

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

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.

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.

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

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

PrestaShop Admin-Performance: Warum das Back Office langsam ist

Ein langsames PrestaShop-Back-Office ist eines der frustrierendsten Probleme fuer Shop-Administratoren. Dieser Leitfaden identifiziert die haeufigsten Ursachen und bietet konkrete Loesungen.

Die haeufigsten Ursachen

1. PrestaShop Addons API-Verbindung

Die Nummer-eins-Ursache. Das Back Office macht HTTP-Anfragen an addons.prestashop.com. Wenn diese API langsam ist, wartet Ihr gesamtes Back Office.

Loesung - Vom Addons-Konto abmelden oder API-Aufrufe deaktivieren.

2. Debug-Modus aktiviert

Deaktiviert alle Caches und kompiliert Templates bei jeder Anfrage neu.

define('_PS_MODE_DEV_', false);
define('_PS_DEBUG_PROFILING_', false);

3. Zu viele installierte Module

Jedes Modul fuegt Overhead hinzu. Deinstallieren Sie unbenutzte Module, besonders Statistik- und Gamification-Module.

4. Grosse Datenbank ohne Optimierung

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Shared-Hosting-Einschraenkungen

Empfehlung: VPS mit mindestens 2 CPU-Kernen, 4 GB RAM, SSD und PHP 8.1+.

6. OPcache nicht aktiviert

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 16229

7. Langsame Dashboard-Widgets

Dashboard vereinfachen. Nicht benoetigte Widgets entfernen. Datumsbereiche einschraenken.

8. Grosser Produktkatalog

Produkte pro Seite auf 20-50 reduzieren. Suchfunktion statt Blaettern nutzen.

Optimierungscheckliste

1. Debug-Modus deaktivieren
2. Template-Kompilierung auf "Nie neu kompilieren" setzen
3. Caching aktivieren (Redis bevorzugt)
4. OPcache aktivieren
5. Von Addons API trennen
6. Unbenutzte Module deinstallieren
7. Datenbank-Bloat bereinigen
8. Dashboard vereinfachen
9. Auf VPS/Dedicated upgraden
10. PHP 8.1+ verwenden

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

Wenn PrestaShop-Kombinationen die Performance toten: Grenzen und Losungen

Das PrestaShop-Kombinationssystem ermoglicht es, Produktvarianten zu erstellen - verschiedene Groessen, Farben, Materialien und andere Attribute. Es funktioniert perfekt fuer Produkte mit wenigen Varianten. Aber wenn Produkte Hunderte oder Tausende von Kombinationen haben, verschlechtert sich die Performance dramatisch. Produktseiten brauchen 10-30 Sekunden zum Laden, das Back Office wird unbrauchbar und Kategorielistenseiten kriechen.

Warum Kombinationen Performance-Probleme verursachen

Datenbankarchitektur

PrestaShop speichert Kombinationsdaten in mehreren Tabellen: ps_product_attribute (eine Zeile pro Kombination), ps_product_attribute_combination (Verknuepfung zu Attributwerten), ps_stock_available (Lagerbestand pro Kombination), ps_specific_price (Preisuebersteuerungen).

Ein Produkt mit 5 Groessen und 10 Farben erzeugt 50 Kombinationen mit ueber 350 Datenbankzeilen. Ein Produkt mit 3 Attributen (10 x 15 x 4) erzeugt 600 Kombinationen mit ueber 4.200 Zeilen.

Das exponentielle Wachstumsproblem

Auswirkungen auf das Front Office

Wenn ein Kunde eine Produktseite mit vielen Kombinationen besucht, muss PrestaShop alle Kombinationen abfragen, den Preis fuer jede berechnen, die Verfuegbarkeit pruefen und die JSON-Datenstruktur generieren. Bei 1.000+ Kombinationen kann dies 5-30 Sekunden dauern.

Praktische Grenzen

Loesung 1 - Produktkatalog umstrukturieren

Die effektivste Loesung: Reduktion der Kombinationen pro Produkt durch Aufteilung.

Produkte nach Hauptattribut aufteilen

Statt eines Produkts "T-Shirt" mit 50 Kombinationen erstellen Sie separate Produkte pro Farbe mit je 5 Groessen-Kombinationen. Schnelleres Frontend, besser fuer SEO.

Loesung 2 - Datenbank- und Server-Optimierung

Datenbankindizes hinzufuegen

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

MySQL-Konfiguration

innodb_buffer_pool_size = 2G
query_cache_type = 1
query_cache_size = 128M

Loesung 3 - Lazy Loading von Kombinationen

Statt alle Kombinationen beim Seitenaufruf zu laden, nur die Daten fuer die ausgewaehlten Attribute per AJAX nachladen. Dies reduziert die initiale Ladezeit erheblich.

Loesung 4 - Caching-Strategien

Full-Page-Cache (Varnish, LiteSpeed) fuer Produktseiten implementieren. Redis oder Memcached statt dateibasiertem Caching nutzen.

Wann Kombinationen ganz vermeiden

• Konfigurierbare Produkte mit 4+ Attributen - Produkt-Konfigurator-Modul nutzen
• Dimensionale Produkte (Breite x Hoehe x Tiefe) - Spezielles Dimensionen-Modul nutzen
• Print-on-Demand-Produkte - Produkt-Designer-Modul nutzen

Empfehlungen nach Kombinationsanzahl

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 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.