Wie man PrestaShop-Fehlerprotokolle wie ein Entwickler liest

Warum PrestaShop-Fehlerprotokolle wichtig sind

Jeder PrestaShop-Shop erzeugt Fehler. Einige sind harmlose Hinweise, die Ihre Kunden nie betreffen. Andere sind kritische Ausfälle, die Ihren gesamten Checkout zum Stillstand bringen. Der Unterschied zwischen einem Shop-Betreiber, der tagelang auf Support wartet, und einem, der Probleme in Minuten behebt, liegt oft an einer einzigen Fähigkeit: dem Lesen von Fehlerprotokollen.

Fehlerprotokolle sind die diagnostische Ausgabe Ihres Servers und Ihrer PrestaShop-Anwendung. Sie zeichnen jeden PHP-Fehler, jede fehlgeschlagene Datenbankabfrage, jedes Berechtigungsproblem und jede nicht abgefangene Ausnahme auf. Wenn etwas schiefgeht, liegt die Antwort fast immer in einer Protokolldatei. Die Herausforderung besteht darin zu wissen, wo man suchen muss, wonach man suchen muss und wie man das Gefundene interpretiert.

Dieser Leitfaden deckt die gesamte Landschaft der PrestaShop-Fehlerprotokollierung ab. Sie werden lernen, wo jede Art von Protokoll liegt, wie man die detaillierte Fehlerberichterstattung aktiviert, wie man Stack Traces liest und wie man Kommandozeilenwerkzeuge nutzt, um die Nadel im Heuhaufen zu finden. Ob Sie einen weißen Bildschirm des Todes debuggen oder einen sporadischen Checkout-Fehler aufspüren – dies ist das Wissen, das Sie brauchen.

Wo PrestaShop-Protokolle gespeichert werden

PrestaShop generiert Protokolle auf mehreren Ebenen, und jede Ebene hat ihre eigenen Protokolldateien. Zu verstehen, welches Protokoll zuerst geprüft werden sollte, spart enorm viel Zeit.

PrestaShop-Anwendungsprotokolle (var/logs)

Ab PrestaShop 1.7 verwendet die Anwendung das Symfony-Framework für das Back Office und das zentrale Routing. Symfony schreibt seine eigenen Protokolle in das Verzeichnis var/logs/ in Ihrem PrestaShop-Stammverzeichnis. Sie finden dort Dateien, die nach der aktuellen Umgebung benannt sind:

var/logs/dev.log enthält Protokolle, wenn PrestaShop im Entwicklungsmodus läuft. Diese Datei ist äußerst ausführlich und zeichnet alles von Routing-Entscheidungen bis hin zu Datenbankabfragen auf. Sie kann schnell auf Hunderte von Megabyte anwachsen.

var/logs/prod.log enthält Protokolle aus dem Produktionsmodus. Diese Datei ist standardmäßig deutlich weniger ausführlich und zeichnet nur Warnungen und Fehler auf. Dies ist die Datei, die Sie zuerst überprüfen sollten, wenn bei einem Live-Shop etwas nicht funktioniert.

Diese Protokolldateien folgen dem Monolog-Format, der Standard-Protokollierungsbibliothek in Symfony. Jede Zeile enthält einen Zeitstempel, den Protokoll-Kanal (wie request, security oder doctrine), den Schweregrad und die Meldung. Ein typischer Eintrag sieht so aus:

[2024-03-15 14:22:33] request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "No route found for GET /admin/nonexistent" at /var/www/html/vendor/symfony/http-kernel/EventListener/RouterListener.php line 136

Die Schweregrade, vom geringsten zum höchsten, sind: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT und EMERGENCY. Bei der Fehlerbehebung filtern Sie zuerst nach ERROR und CRITICAL.

PHP-Fehlerprotokoll

PHP selbst führt ein Fehlerprotokoll, das von den Anwendungsprotokollen von PrestaShop getrennt ist. Dieses Protokoll erfasst Fehler, die auftreten, bevor PrestaShops Protokollierungs-Framework initialisiert wird, oder Fehler in Code, der den Symfony-Logger nicht verwendet. Der Speicherort dieser Datei hängt von Ihrer Serverkonfiguration ab.

Auf den meisten Linux-Servern mit Apache befindet sich das PHP-Fehlerprotokoll unter /var/log/php_errors.log oder /var/log/php/error.log. Auf Shared Hosting mit cPanel befindet es sich oft unter /home/username/logs/error.log oder im public_html-Verzeichnis als error_log.

Den genauen Speicherort können Sie über Ihre PHP-Konfiguration ermitteln. Erstellen Sie eine temporäre PHP-Datei mit phpinfo(); und suchen Sie nach der Direktive error_log. Alternativ führen Sie php -i | grep error_log über die Kommandozeile aus.

PHP-Fehlerprotokolle erfassen fatale Fehler, Parse-Fehler, Warnungen und Hinweise. Ein typischer Eintrag eines fatalen Fehlers sieht so aus:

[15-Mar-2024 14:22:33 UTC] PHP Fatal error: Uncaught Error: Class 'SomeModule\SomeClass' not found in /var/www/html/modules/somemodule/somemodule.php:45

Webserver-Protokolle (Apache und Nginx)

Ihr Webserver führt eigene Protokolle, die unabhängig von PHP und PrestaShop sind. Diese Protokolle sind unverzichtbar für die Diagnose von 500-Fehlern, 404-Fehlern und Leistungsproblemen.

Apache-Protokolle befinden sich typischerweise unter:

/var/log/apache2/error.log für das Fehlerprotokoll auf Debian- und Ubuntu-Systemen.
/var/log/httpd/error_log für das Fehlerprotokoll auf CentOS- und RHEL-Systemen.
/var/log/apache2/access.log für das Zugriffsprotokoll, das jede HTTP-Anfrage aufzeichnet.

Nginx-Protokolle befinden sich typischerweise unter:

/var/log/nginx/error.log für das Fehlerprotokoll.
/var/log/nginx/access.log für das Zugriffsprotokoll.

Wenn Ihre Website eine Virtual-Host-Konfiguration verwendet, befinden sich die Protokolle möglicherweise an einem standortspezifischen Speicherort, der durch die Direktive ErrorLog (Apache) oder error_log (Nginx) in Ihrer Virtual-Host-Datei definiert ist.

Webserver-Fehlerprotokolle erfassen Probleme wie Zugriffsverweigerungsfehler, wenn PHP versucht, in ein Verzeichnis zu schreiben, Konfigurationssyntaxfehler nach einer .htaccess-Änderung und Proxy-Timeout-Fehler, wenn Sie PHP-FPM hinter Nginx betreiben. Dies sind die Protokolle, die Sie überprüfen sollten, wenn ein generischer 500-Internal-Server-Error ohne Details in den PHP- oder PrestaShop-Protokollen erscheint.

PrestaShop-Legacy-Protokolle (Back Office)

PrestaShop unterhält auch einen Protokoll-Viewer im Back Office unter Erweiterte Einstellungen > Protokolle. Diese Oberfläche zeigt Protokolleinträge, die in der Datenbanktabelle ps_log gespeichert sind. Diese Protokolle erfassen Events, die PrestaShop explizit aufzeichnet, wie fehlgeschlagene Anmeldeversuche, Modulinstallationsfehler und Fehler beim E-Mail-Versand.

Obwohl der Back-Office-Protokoll-Viewer praktisch ist, hat er erhebliche Einschränkungen. Er erfasst keine PHP-Fehler, keine Webserver-Fehler und die meisten fatalen Fehler, die das Laden der Seite verhindern, nicht. Betrachten Sie ihn als Ergänzung zu den dateibasierten Protokollen, nicht als Ersatz.

Debug-Modus in PrestaShop aktivieren

Standardmäßig läuft PrestaShop im Produktionsmodus und verbirgt detaillierte Fehlermeldungen vor Besuchern. Dies ist für einen Live-Shop korrekt, macht das Debugging jedoch nahezu unmöglich. Wenn etwas nicht funktioniert, sollte Ihr erster Schritt das Aktivieren des Debug-Modus sein.

Methode 1: Die Datei defines.inc.php

Öffnen Sie die Datei config/defines.inc.php und suchen Sie die Zeile, die _PS_MODE_DEV_ setzt. Ändern Sie den Wert von false auf true:

define('_PS_MODE_DEV_', true);

Diese einzelne Änderung hat mehrere Auswirkungen. Die PHP-Fehlerberichterstattung wird auf die maximale Stufe gesetzt und zeigt alle Fehler, Warnungen und Hinweise an. Das Smarty-Template-Caching wird deaktiviert, sodass Template-Änderungen sofort sichtbar sind. Die Symfony-Profiler-Toolbar erscheint am unteren Rand der Back-Office-Seiten. Und vor allem werden Fehlerdetails auf dem Bildschirm angezeigt, anstatt eine generische Fehlerseite zu zeigen.

Methode 2: Der Debug-Profiling-Modus

Für eine tiefergehende Analyse können Sie auch das Profiling aktivieren. Setzen Sie in derselben Datei:

define('_PS_DEBUG_PROFILING_', true);

Dies fügt am Ende jeder Seite detaillierte Timing- und Speicherverbrauchsinformationen hinzu und zeigt Ihnen, welche Hooks am längsten dauern, welche Module den meisten Speicher verbrauchen und wie viele Datenbankabfragen jede Seite generiert. Dies ist für das Performance-Debugging unschätzbar wertvoll, sollte aber niemals in der Produktion aktiviert bleiben.

Sicherheitswarnung

Der Debug-Modus legt sensible Informationen offen, darunter Dateipfade, Datenbankzugangsdaten in Stack Traces und die interne Anwendungsstruktur. Lassen Sie den Debug-Modus niemals auf einem Produktions-Shop aktiviert, der öffentlich zugänglich ist. Wenn Sie einen Live-Shop debuggen müssen, erwägen Sie, den Debug-Modus auf Ihre IP-Adresse zu beschränken, indem Sie die Define-Anweisung in eine IP-Prüfung einbetten, oder verwenden Sie eine Staging-Umgebung.

Stack Traces lesen

Wenn PrestaShop im Debug-Modus auf einen fatalen Fehler oder eine nicht abgefangene Ausnahme stößt, zeigt es einen Stack Trace an. Ein Stack Trace ist eine Momentaufnahme der Aufrufkette, die zum Fehler geführt hat – er liest sich vom Fehlerpunkt zurück bis zum ursprünglichen Einstiegspunkt. Das Lesen von Stack Traces zu erlernen, ist die wertvollste Debugging-Fähigkeit, die Sie entwickeln können.

Anatomie eines Stack Trace

Ein typischer PrestaShop-Stack-Trace sieht so aus:

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Product::getProductProperties() must be of the type int, null given, called in /var/www/html/classes/Product.php on line 4523

Stack trace:
#0 /var/www/html/classes/Product.php(4523): Product::getProductProperties(NULL, Array)
#1 /var/www/html/modules/somemodule/somemodule.php(127): Product::getProductProperties(1, Array)
#2 /var/www/html/classes/Hook.php(523): SomeModule->hookDisplayHome(Array)
#3 /var/www/html/classes/Hook.php(460): Hook::coreCallHook(Object(SomeModule), 'hookDisplayHome', Array)
#4 /var/www/html/classes/Hook.php(408): Hook::exec('displayHome', Array)

Lesen Sie den Stack Trace von oben nach unten. Die erste Zeile sagt Ihnen, was schiefgelaufen ist: Eine Funktion erwartete einen Integer, erhielt aber null. Die Zeile #0 sagt Ihnen, wo der Fehler aufgetreten ist. Die Zeile #1 sagt Ihnen, was den Code bei #0 aufgerufen hat. Die Zeile #2 sagt Ihnen, was #1 aufgerufen hat, und so weiter.

In diesem Beispiel ist die Kette klar: PrestaShop hat den Hook displayHome ausgeführt, der die Methode hookDisplayHome in SomeModule aufgerufen hat, die wiederum Product::getProductProperties() mit einem null-Wert aufgerufen hat, wo ein Integer erwartet wurde. Der Fehler liegt im Modul in Zeile 127, wo ein falscher Wert übergeben wird.

Den relevanten Frame finden

Stack Traces in PrestaShop können lang sein – manchmal 20 oder 30 Frames tief. Der Schlüssel liegt darin, den Frame zu finden, der Ihren Code oder das verursachende Modul enthält. Suchen Sie nach Pfaden, die /modules/ oder /themes/ enthalten, da diese die wahrscheinlichsten Fehlerquellen sind. Frames, die auf /classes/, /src/ oder /vendor/ verweisen, sind PrestaShop-Kerncode oder Code von Drittanbieter-Bibliotheken, die weniger wahrscheinlich die Problemquelle sind – es sei denn, Sie haben Core-Dateien modifiziert.

Häufige PrestaShop-Fehlermuster

Nach dem Lesen tausender PrestaShop-Fehlerprotokolle zeichnen sich bestimmte Muster ab, die sich immer wieder wiederholen. Das Erkennen dieser Muster ermöglicht es Ihnen, Probleme in Sekunden statt in Stunden zu diagnostizieren.

Class-Not-Found-Fehler

PHP Fatal error: Uncaught Error: Class 'ModuleName\ClassName' not found

Dies bedeutet, dass der Autoloader die angegebene Klasse nicht finden kann. Häufige Ursachen sind: eine fehlende vendor/autoload.php-Datei (das Modul benötigt composer install), eine nicht übereinstimmende Namespace-Deklaration, eine Datei, die nicht im Modul-ZIP während der Installation enthalten war, oder ein Groß-/Kleinschreibungsproblem auf Linux-Servern, wo ClassName.php und classname.php unterschiedliche Dateien sind.

Zugriffsverweigerungsfehler

Warning: file_put_contents(/var/www/html/var/cache/prod/some_file): failed to open stream: Permission denied

Diese treten auf, wenn der Webserver-Benutzer (normalerweise www-data auf Debian/Ubuntu oder apache auf CentOS) keine Schreibberechtigung für eine Datei oder ein Verzeichnis hat. Beheben Sie dies durch Korrektur der Eigentümerschaft: chown -R www-data:www-data var/cache/ und der Berechtigungen: chmod -R 775 var/cache/.

Speicherlimitfehler

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes)

Die Zahl 134217728 Bytes entspricht 128MB, dem Standard-PHP-Speicherlimit. PrestaShop empfiehlt mindestens 256MB. Erhöhen Sie es in Ihrer php.ini-Datei: memory_limit = 512M. Wenn der Fehler auch bei hohen Speicherlimits weiterhin auftritt, hat der Code wahrscheinlich ein Speicherleck, das oft durch das Laden zu vieler Produkte oder Kategorien in einer einzigen Abfrage ohne Paginierung verursacht wird.

Datenbankverbindungsfehler

Link to database cannot be established: SQLSTATE[HY000] [2002] Connection refused

Dies bedeutet, dass PrestaShop keine Verbindung zum MySQL-Server herstellen kann. Überprüfen Sie, ob der Datenbankserver läuft, ob die Zugangsdaten in app/config/parameters.php korrekt sind und ob der Datenbank-Host vom Webserver aus erreichbar ist.

Smarty-Template-Fehler

SmartyException: Unable to load template file 'module:somemodule/views/templates/hook/display.tpl'

Die Template-Datei fehlt, ist falsch geschrieben oder befindet sich im falschen Verzeichnis. Überprüfen Sie, ob die Datei am erwarteten Pfad existiert und ob der Dateiname exakt übereinstimmt, einschließlich Groß-/Kleinschreibung.

CSRF-Token-Fehler

Invalid token. Please try to log in again.

Dieser Fehler erscheint im Back Office, wenn eine Formularübermittlung ein abgelaufenes oder fehlendes Sicherheitstoken enthält. Er tritt typischerweise auf, wenn eine Session während einer langen Bearbeitungssitzung abläuft, wenn mehrere Tabs auf derselben Admin-Seite geöffnet sind oder wenn ein Modul seine Formular-URLs falsch generiert.

Mit grep Fehler finden

Wenn Protokolldateien groß werden, ist das manuelle Durchscrollen unpraktisch. Der Befehl grep ist Ihr bester Freund, um relevante Einträge schnell zu finden.

Grundlegende Fehlersuche

Um alle fatalen Fehler im PHP-Fehlerprotokoll zu finden:

grep 'Fatal error' /var/log/php_errors.log

Um Fehler eines bestimmten Moduls zu finden:

grep 'somemodule' /var/www/html/var/logs/prod.log

Um nur Fehler von heute zu finden (unter Annahme des Datumsformats im Protokoll):

grep '2024-03-15' /var/www/html/var/logs/prod.log | grep 'ERROR\|CRITICAL'

Erweiterte Filterung

Um Fehler mit umgebendem Kontext zu sehen (3 Zeilen vor und nach jedem Treffer):

grep -C 3 'Fatal error' /var/log/php_errors.log

Um zu zählen, wie oft jeder eindeutige Fehler auftritt:

grep 'Fatal error' /var/log/php_errors.log | sort | uniq -c | sort -rn | head -20

Diese Pipeline sortiert die Fehler, zählt Duplikate, sortiert nach Anzahl in absteigender Reihenfolge und zeigt die Top 20 an. Dies ist unglaublich nützlich, um die häufigsten Fehler zu identifizieren, die zuerst behoben werden müssen.

Um gleichzeitig in mehreren Protokolldateien zu suchen:

grep -r 'Fatal error' /var/log/ --include='*.log'

Das Flag -r sucht rekursiv, und --include beschränkt die Suche auf Dateien mit der Endung .log.

Echtzeit-Protokollüberwachung mit tail -f

Wenn Sie aktiv ein Problem debuggen, müssen Sie Fehler sehen, sobald sie auftreten. Der Befehl tail -f folgt einer Protokolldatei in Echtzeit und zeigt neue Einträge an, sobald sie geschrieben werden.

Grundlegende Echtzeitüberwachung

Um das PrestaShop-Produktionsprotokoll in Echtzeit zu beobachten:

tail -f /var/www/html/var/logs/prod.log

Um das PHP-Fehlerprotokoll zu beobachten:

tail -f /var/log/php_errors.log

Um mehrere Protokolldateien gleichzeitig zu beobachten:

tail -f /var/www/html/var/logs/prod.log /var/log/php_errors.log /var/log/apache2/error.log

Gefilterte Echtzeitüberwachung

Um nur Einträge auf Fehlerebene in Echtzeit zu beobachten, kombinieren Sie tail mit grep:

tail -f /var/www/html/var/logs/prod.log | grep --line-buffered 'ERROR\|CRITICAL'

Das Flag --line-buffered ist hier wichtig. Ohne es puffert grep seine Ausgabe und Sie sehen Treffer möglicherweise nicht sofort.

Um bestimmte Schlüsselwörter hervorzuheben und gleichzeitig alle Ausgaben anzuzeigen:

tail -f /var/www/html/var/logs/prod.log | grep --color=always -E 'ERROR|CRITICAL|$'

Dies hebt ERROR und CRITICAL farblich hervor und zeigt trotzdem alle Zeilen an.

Der Debugging-Workflow

Der effektivste Debugging-Workflow kombiniert Echtzeitüberwachung mit aktivem Testen. Öffnen Sie ein Terminalfenster mit tail -f auf den relevanten Protokolldateien. Reproduzieren Sie in Ihrem Browser die Aktion, die den Fehler verursacht. Beobachten Sie das Terminal auf neue Protokolleinträge, die genau in dem Moment erscheinen, in dem Sie das Problem auslösen. Dieser Ansatz eliminiert Rätselraten und zeigt Ihnen präzise, was beim Auftreten des Fehlers passiert.

Protokollrotation und -verwaltung

Protokolldateien wachsen kontinuierlich und können den gesamten verfügbaren Speicherplatz verbrauchen, wenn sie nicht verwaltet werden. Die meisten Linux-Server verwenden logrotate zur automatischen Verwaltung, aber PrestaShops eigene Protokolle in var/logs/ sind möglicherweise nicht in der Standard-logrotate-Konfiguration enthalten.

Logrotate verstehen

Das Dienstprogramm logrotate wird täglich ausgeführt (normalerweise über cron) und übernimmt die Rotation, Komprimierung und Löschung von Protokolldateien. Konfigurationsdateien befinden sich in /etc/logrotate.d/. Apache- und Nginx-Protokollrotation ist typischerweise standardmäßig konfiguriert.

Für das Verzeichnis var/logs von PrestaShop müssen Sie möglicherweise eine benutzerdefinierte logrotate-Konfiguration erstellen:

/var/www/html/var/logs/*.log {
  daily
  missingok
  rotate 14
  compress
  delaycompress
  notifempty
  create 0640 www-data www-data
}

Diese rotiert Protokolle täglich, behält 14 Tage Historie, komprimiert alte Protokolle und erstellt neue Protokolldateien mit korrekten Berechtigungen.

Manuelle Protokollbereinigung

Wenn eine Protokolldatei extrem groß geworden ist und Sie sie leeren müssen, ohne den Datei-Handle zu verlieren (wichtig, wenn ein Prozess aktiv in die Datei schreibt):

truncate -s 0 /var/www/html/var/logs/prod.log

Löschen Sie die Datei nicht und erstellen Sie sie neu, denn jeder Prozess, der die Datei geöffnet hat, schreibt weiterhin in den Inode der gelöschten Datei, bis er neu gestartet wird. Der truncate-Ansatz leert den Inhalt und bewahrt gleichzeitig den Inode.

PrestaShop-spezifische Fehlerkontexte verstehen

PrestaShop-Fehler enthalten oft Kontext, der für die Plattform einzigartig ist. Das Verständnis dieses Kontexts hilft Ihnen, Probleme schneller zu finden und zu beheben.

Hook-bezogene Fehler

Wenn ein Fehler innerhalb eines Hooks auftritt, enthält der Stack Trace Verweise auf Hook::exec() und Hook::coreCallHook(). Der Hook-Name sagt Ihnen genau, an welchem Punkt des Seitenrendering-Prozesses der Fehler auftritt. Zum Beispiel treten displayHome-Fehler auf der Startseite auf, actionValidateOrder-Fehler treten während des Checkouts auf, und displayBackOfficeHeader-Fehler treten beim Laden einer beliebigen Back-Office-Seite auf.

Wenn ein Hook-Fehler eine Seite zum Absturz bringt, können Sie das verursachende Modul vorübergehend über die Datenbank deaktivieren:

UPDATE ps_module SET active = 0 WHERE name = 'somemodule';

So erhalten Sie Zugang zum Back Office, um das Problem ordnungsgemäß zu diagnostizieren und zu beheben.

Override-Konflikte

Das Override-System von PrestaShop ermöglicht es Modulen, Kernklassen zu erweitern, aber Konflikte entstehen, wenn zwei Module dieselbe Klasse überschreiben. Der Fehler erscheint typischerweise als Methodensignatur-Konflikt oder unerwartete Verhaltensänderung. Überprüfen Sie das Verzeichnis override/, um zu sehen, welche Overrides aktiv sind, und prüfen Sie die Datei cache/class_index.php, die Klassen ihren Override-Dateien zuordnet. Das Löschen dieser Cache-Datei zwingt PrestaShop, die Override-Zuordnung neu zu generieren.

Cache-bezogene Fehler

Viele PrestaShop-Fehler werden durch veraltete Cache-Dateien verursacht. Wenn Sie Fehler sehen, die nicht zum aktuellen Code passen (zum Beispiel ein Fehler, der auf eine Zeilennummer verweist, die in der Datei nicht existiert), ist der Cache wahrscheinlich veraltet. Leeren Sie ihn, indem Sie den Inhalt von var/cache/prod/ und var/cache/dev/ löschen. Bei PrestaShop 1.6 leeren Sie stattdessen cache/smarty/compile/ und cache/smarty/cache/.

Modulinstallations- und Upgrade-Fehler

Modulinstallationen können stillschweigend fehlschlagen und das Modul in einem teilweise installierten Zustand hinterlassen. Prüfen Sie var/logs/prod.log auf Einträge zum Zeitpunkt der Installation. Häufige Probleme sind fehlende Datenbanktabellen (die SQL der install()-Methode des Moduls ist fehlgeschlagen), fehlende Hooks (der registerHook()-Aufruf ist fehlgeschlagen) und Fehler durch doppelte Einträge in der Tabelle ps_authorization_role bei der Neuinstallation eines Moduls, das nicht vollständig deinstalliert wurde.

Eine Debugging-Checkliste erstellen

Wenn Sie auf einen PrestaShop-Fehler stoßen, folgen Sie dieser systematischen Checkliste, um die Ursache effizient zu finden:

Erstens, identifizieren Sie den Fehlertyp. Handelt es sich um einen weißen Bildschirm (500-Fehler), eine spezifische Fehlermeldung, ein defektes Layout oder unerwartetes Verhalten? Jeder Typ verweist auf unterschiedliche Protokolldateien.

Zweitens, überprüfen Sie zuerst das spezifischste Protokoll. Für PHP-Fehler prüfen Sie das PHP-Fehlerprotokoll. Für HTTP-Fehler prüfen Sie das Webserver-Fehlerprotokoll. Für Anwendungsfehler prüfen Sie var/logs/prod.log.

Drittens, aktivieren Sie den Debug-Modus, wenn die Protokolle nicht genügend Informationen liefern. Ändern Sie _PS_MODE_DEV_ auf true und reproduzieren Sie den Fehler.

Viertens, verwenden Sie tail -f auf den relevanten Protokollen und reproduzieren Sie den Fehler in Ihrem Browser. So erhalten Sie einen Echtzeitblick auf genau das, was passiert.

Fünftens, lesen Sie den Stack Trace von oben nach unten. Finden Sie den Frame, der auf Ihren Modul- oder Theme-Code verweist. Dort muss die Korrektur erfolgen.

Sechstens, suchen Sie nach der Fehlermeldung in PrestaShops GitHub-Issues und Foren. Die Chancen stehen gut, dass jemand dasselbe Problem bereits erlebt und gelöst hat.

Siebtens, nach Anwendung einer Korrektur leeren Sie alle Caches und überwachen Sie die Protokolle, um zu bestätigen, dass der Fehler behoben ist. Eine Korrektur, die kein sauberes Protokoll erzeugt, ist keine vollständige Korrektur.

Zusammenfassung

Das Lesen von PrestaShop-Fehlerprotokollen ist keine geheimnisvolle Kunst, die erfahrenen Entwicklern vorbehalten ist. Es ist eine praktische Fähigkeit, die darauf aufbaut zu wissen, wo Protokolle gespeichert sind, wie man sie filtert und wie man interpretiert, was sie enthalten. Die Protokolle unter var/logs/, das PHP-Fehlerprotokoll und das Webserver-Fehlerprotokoll dienen jeweils einem anderen Zweck und geben zusammen ein vollständiges Bild jedes Problems. Das Aktivieren des Debug-Modus liefert detaillierte Fehlermeldungen. Stack Traces zeigen Ihnen die exakte Kette von Funktionsaufrufen, die zum Fehler geführt hat. Werkzeuge wie grep und tail -f ermöglichen es, Fehler auch in großen, stark frequentierten Protokolldateien effizient zu finden und zu überwachen. Beherrschen Sie diese Techniken, und Sie werden Probleme schneller lösen, mit weniger Frustration und deutlich weniger Abhängigkeit von externem Support.