PrestaShop Bildregeneration: Wann und wie man Thumbnails neu erstellt

Wie PrestaShop Produktbilder verarbeitet

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

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

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

Bildtypen verstehen

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

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

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

Wann eine Bildregeneration notwendig ist

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

Theme-Wechsel

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

Änderung der Bildtypabmessungen

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

Hinzufügen eines neuen Bildtyps

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

Bildqualitätsprobleme

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

Nach einer Migration oder einem Serverwechsel

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

Aktivierung des WebP-Formats

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

Regeneration über das Admin-Panel

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

Verfügbare Optionen

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

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

Einschränkungen des Admin-Panel-Ansatzes

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

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

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

CLI-Regeneration für große Kataloge

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

Verwendung der PrestaShop-Konsole

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

php bin/console prestashop:image:regenerate

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

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

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

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

Speicher- und Zeitkonfiguration

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

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

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

Benutzerdefinierter Regenerationsansatz

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

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

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

WebP-Generierung während der Regeneration

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

WebP-Unterstützung aktivieren

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

Serveranforderungen

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

Speicherplatzüberlegungen

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

WebP an Browser ausliefern

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

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

Leistungsauswirkungen und Gegenmaßnahmen

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

CPU-Auswirkung

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

I/O-Auswirkung

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

Regeneration außerhalb der Stoßzeiten durchführen

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

Nice und Ionice verwenden

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

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

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

Temporäre Skalierung

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

Timeouts während der Regeneration vermeiden

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

PHP-Konfiguration

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

php_value max_execution_time 7200

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

php_value max_input_time 7200

Webserver-Timeout

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

PHP-FPM-Konfiguration

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

request_terminate_timeout = 7200

Cloudflare- und CDN-Timeouts

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

Inkrementelle Regenerationsstrategien

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

Selektive Bildtyp-Regeneration

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

Datumsbasierte Verarbeitung

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

Erkennung fehlender Thumbnails

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

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

Parallelverarbeitung

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

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

Bildformat-Überlegungen

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

JPEG-Bilder

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

PNG-Bilder

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

GIF-Behandlung

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

Überprüfung nach der Regeneration

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

Stichprobenartige Qualitätsprüfung

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

Dateianzahl-Überprüfung

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

Dateiberechtigungsprüfung

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

Cache leeren

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

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

Fehlerbehebung bei häufigen Regenerationsproblemen

Schwarze oder beschädigte Thumbnails

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

Falsche Abmessungen in generierten Thumbnails

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

Regeneration hängt ohne Fortschritt

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

Zugriffsverweigerungsfehler

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

Zusammenfassung

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