Wie Leopoldo sagte , scheint log_errors_max_len in dieser Situation ziemlich nutzlos zu sein, und das PHP-Handbuch gibt dies eindeutig an.
Die einzige Lösung, die ich bisher finden konnte, ist:
%Vor% Der zweite Parameter von error_log() ermöglicht das Umleiten von Nachrichten an eine benutzerdefinierte Datei. Der letzte Parameter sollte also ein Pfad zu einer benutzerdefinierten Protokolldatei sein.
Auf diese Weise bekomme ich die volle Fehlermeldung und, was für jemand wichtiger sein könnte, sind nicht-ASCII-Zeichen dort klar lesbar (nicht sicher, aber vielleicht meine schlechte, aber wenn ich sie mit Standard-Log-Datei protokolliere - Ich bekomme Dinge wie \xd0\xbf ).
PHP Manual sagt über die Einstellungen log_errors_max_len in php.ini :
Legen Sie die maximale Länge von log_errors in Bytes fest. (...) Der Standardwert ist 1024 und 0 erlaubt es überhaupt keine maximale Länge anzuwenden.
Einige schlagen vor, dass Sie es zum Beispiel ändern können:
%Vor%Aber das Handbuch fügt hinzu:
Diese Länge gilt für protokollierte Fehler, angezeigte Fehler und auch für $ php_errormsg, aber nicht explizit aufgerufene Funktionen wie error_log () .
Ich versuche eine Lösung zu finden. Wird bearbeiten, wenn ich das tue.
Wenn ich die obige Frage gelesen habe, habe ich mich gefragt, ob das Problem in Apache liegt. Ja, die Kürzung erfolgt innerhalb von PHP, denn Apache erlaubt sogar über 10.000 Zeichen. Hier ist ein Perl-Skript, das die Fähigkeit von Apache bewertet, lange Fehlermeldungen in sein Protokoll zu schreiben:
%Vor%Tags und Links php apache stack-trace error-logging error-log