error_reporting (E_ALL) терпит неудачу без журнала или сообщения об ошибке - PullRequest
Новая
       8

error_reporting (E_ALL) терпит неудачу без журнала или сообщения об ошибке

0 голосов
/ 26 февраля 2019

Я использую WordPress REST API и в своем основном файле плагина я установил: 

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

У меня странное поведение.Например, в функции / конечной точке у меня есть что-то вроде: 

function test($request){
    $request['id'] <- this works fine here

    but if I add another function like this I get a silent error

    $validID = check_id($request['id']);
}

Поэтому, когда я делаю это, мой возврат из конечной точки остается пустым, и я получаю эту ошибку: 

has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Теперь, еслиЯ установил error_reporting: 

error_reporting(E_ERROR | E_WARNING | E_PARSE);

Моя конечная точка работает нормально.Не уверен, что здесь происходит.Я не получаю никаких журналов ошибок php, и это делает его чрезвычайно трудным для устранения неполадок.Так я должен просто НЕ использовать E_ALL?

Я также проверил конечную точку, пропустив точку с запятой.Я получаю тот же результат, за исключением того, что теперь я получаю пустой ответ как для error_reporting (E_ALL), так и error_reporting (E_ERROR | E_WARNING | E_PARSE).Я хотел бы получить какой-нибудь журнал / возврат, чтобы сказать мне, что не так.

1 Ответ

0 голосов
/ 26 февраля 2019

К сожалению, большая часть кода WordPress написана без включенного WP_DEBUG, что означает без уровня E_ALL.В результате, он, как правило, полон уведомлений и проблем с устареванием, которые разработчики не видят и не пытаются исправить.

Таким образом, создание отчетов об ошибках часто может вызвать проблемы , совершенно не связанные с вашими собственнымиcode.

Поскольку вашей непосредственной проблемой является отсутствие очевидного сообщения об ошибке / журнала, вам следует поэкспериментировать с конфигурацией WP_DEBUG_DISPLAY и WP_DEBUG_LOG, чтобы посмотреть, поможет ли это.

Как правило, предпочтительнее использоватьконстанты для централизованного управления обработкой ошибок WP.Когда расширения начинают связываться с этим, это ... ну, беспорядок.:)

Еще одна вещь, которую вы можете попробовать - это специальный обработчик ошибок.Я сделал и использую плагин wps , который оборачивает обработчик whoops для контекста WP.В случае ошибок API он пытается переопределить вывод и вернуть значимый след того, что произошло.

...