Anzeigen von PHP-Fehlern von admin-ajax.php in WordPress 4.9+
Lesezeit: 4 Minuten
owenmelbz
Wir haben einige benutzerdefinierte Endpunkte eingerichtet, die verschiedene Dinge tun, auf die wir zugreifen /wp/wp-admin/admin-ajax.php?action=some_action
Wenn jedoch während der Entwicklung ein Fehler auftritt, z. B. Syntaxfehler, logischer Fehler, schwerwiegender Fehler usw., erhalten wir beim Anzeigen der Seite im Browser einfach „500 Internal Server Error“.
Jede andere Seite auf der Website, wenn es einen Fehler gibt, gibt uns den PHP-Fehler, um uns beim Debuggen zu helfen.
Wenn der Fehler jedoch von der admin-ajax.php müssen wir dann unsere PHP-Log-Datei öffnen, um den Fehler zu sehen – was bei aktiver Entwicklung eher lästig ist
Gibt es etwas in WordPress, das die Anzeige von Fehlern in diesem URL-Namespace deaktiviert? und wenn ja, wie können wir dies verhindern, damit die Fehler im Browser angezeigt werden?
Was meinst du mit PHP error im Vergleich zu einem 500? Meinen Sie Warnungen, die eine Ablaufverfolgung durchführen können, da der Fehler den Parser nicht unterbricht?
– Lawrence Cherone
26. März 2018 um 10:34 Uhr
Wie in, wann immer PHP aus irgendeinem Grund einen Fehler/eine Ausnahme auslöst – wenn das Skript admin-ajax.php durchläuft, gibt es die Apache 500-Fehlerseite anstelle einer weißen Seite mit einer Fehlermeldung darauf aus
– owenmelbz
26. März 2018 um 11:59 Uhr
Wenn Sie die PHP-Fehler bei der Verwendung von Ajax sehen möchten, öffnen Sie die Datei wp-includes/load.php und ändern Sie in Zeile 336 diese Zeile:
Sie können nun die Ajax-Fehler in Ihrer Browserkonsole sehen. Denken Sie daran, dies rückgängig zu machen, wenn Sie mit dem Debuggen fertig sind!
Ich bin mir nicht sicher, ob beide verwandt sind, weil es funktioniert, aber ich bekomme immer Fatal error: Allowed memory size of 134217728 bytes exhausted
– Salathiel Genese
4. Oktober 2018 um 4:18 Uhr
Schwer zu debuggender WordPress-Fehler hinter der Ajax-Anfrage (schlimmer: im Docker) … Ich habe endlich die Endlosschleife herausgefunden, die das Leck verursacht hat. Vielen Dank
– Salathiel Genese
4. Oktober 2018 um 4:53 Uhr
Ab Dezember 2018 ist die Zeilennummer jetzt 353.
– irgendjemand irgendwo
14. Dezember 2018 um 23:14 Uhr
Die Zeilennummern können sich ändern. Suchen Sie also nach der Funktion wp_debug_mode in der Datei. Die zu ändernde Zeile befindet sich innerhalb dieser Funktion.
– melwin
30. November 2020 um 6:57 Uhr
Für Juni 2021 lautet die Zeilennummer 471. Sie können den Text „display_errors“ durchsuchen und die gefundenen Übereinstimmungen durchlaufen, die leicht zu finden sind.
– Mark Okman
2. Juni 2021 um 14:02 Uhr
ABHi
Bessere Lösung
Aktivieren Sie die PHP-Fehlerausgabe, bevor der Fehler auftritt
Fügen Sie dies hinzu, um die PHP-Fehlerausgabe zu aktivieren
@ini_set( 'display_errors', 1 );
ZB: In diesem Fall zu Beginn der Ajax-Callback-Funktion
Tipp:
Du kannst den … benutzen Vorschau Reiter neben Antwort im Dev Tools Network, um den HTML-Code in der Fehlerausgabe zu rendern. Damit Sie den Fehler ohne HTML sehen können
Erläuterung
Ich weiß nicht, warum WordPress diese Fehlerausgabe nicht zulässt, aber ich denke nicht, dass das Bearbeiten der WordPress Core-Datei und das Rückgängigmachen nach dem Debuggen keine gute Idee ist, wie hier beantwortet
Aus dieser Antwort habe ich herausgefunden, dass wir nur die einstellen müssen display_errors PHP-Init-Einstellung auf true oder 1
um die Fehler auszugeben.
Also, warum setzen wir das nicht einfach dort, wo wir wollen, dass das funktioniert, damit das funktioniert display_errors wird nur für diesen Bereich aktiviert.
Es gibt kein Problem, wenn Sie dies im Gegensatz zu der anderen Antwort nicht rückgängig gemacht haben
Grzegorz Adam Kowalski
Bearbeiten wp-includes/class-wp-fatal-error-handler.php und ändere dies ein display_default_error_template( $error, $handled ) (Zeile: 193):
$message = sprintf(
'<p>%s</p><p><a href="%s">%s</a></p>',
$message,
/* translators: Documentation explaining debugging in WordPress. */
__( 'https://wordpress.org/support/article/debugging-in-wordpress/' ),
__( 'Learn more about debugging in WordPress.' )
);
zu
$message = sprintf(
'<p>%s</p><p><a href="%s">%s</a></p>',
$message . ' ' . json_encode($error),
/* translators: Documentation explaining debugging in WordPress. */
__( 'https://wordpress.org/support/article/debugging-in-wordpress/' ),
__( 'Learn more about debugging in WordPress.' )
);
Dann Vorschau der HTML-Antwort auf admin-ajax.php mit Dev-Tools.
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
Definieren Sie die folgenden Konstanten als solche. Sie werden sehen können debug.log unter wp-content. Normalerweise lasse ich die Debug-Anzeige auch ausgeschaltet, da dies zu Problemen mit den bereits gesendeten Headern führt.
BEARBEITEN:
Anscheinend ist die Fehlerberichterstattung für Ajax-Anforderungen in der letzten Zeile der Methode deaktiviert wp_debug_mode() in wp-includes/load.php
Was meinst du mit
PHP error
im Vergleich zu einem 500? Meinen Sie Warnungen, die eine Ablaufverfolgung durchführen können, da der Fehler den Parser nicht unterbricht?– Lawrence Cherone
26. März 2018 um 10:34 Uhr
Wie in, wann immer PHP aus irgendeinem Grund einen Fehler/eine Ausnahme auslöst – wenn das Skript admin-ajax.php durchläuft, gibt es die Apache 500-Fehlerseite anstelle einer weißen Seite mit einer Fehlermeldung darauf aus
– owenmelbz
26. März 2018 um 11:59 Uhr