Voraussichtliches Lieferdatum

Checkout Revolution zeigt die Versandoptionen an, die Ihre Versandmodule bereitstellen, einschließlich aller Lieferzeitinformationen, die sie liefern. Wenn Ihr Versandmodul geschätzte Liefertermine enthält, werden diese angezeigt. Das Checkout-Modul selbst berechnet keine Liefertermine — diese Logik gehört zu den Versand-/Carrier-Modulen.

Learn more in our one-page checkout guide.

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

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

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

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.