У меня проблема с ошибками, генерируемыми в плагинах WordPress, что затрудняет разработку.Ошибки в плагинах делают ошибку сервера 500 без сообщения об ошибке на экране или в журнале
Если я вызвать ошибку в обычном PHP файле так:
trigger_error("an error occurred", E_USER_ERROR);
Он прекрасно работает, и я получаю сообщение об ошибке отображается на странице. Однако, если я попробую то же самое в коде плагина, сервер генерирует ошибку 500 в браузере и не отображает ошибку.
Кроме того, он также не регистрирует ошибок в файлах журнала PHP-FPM или Nginx при использовании кода плагина. Это делает разработку чрезвычайно сложной, поскольку, когда я получаю сообщение об ошибке, у меня нет никакой информации.
Поскольку это нормально работает в автономном PHP, я предполагаю, что это должно быть связано с WordPress.
У меня есть отладка включена в wordpress. Мой стек выглядит следующим образом:
- Ubuntu 16,04
- PHP 7.0.4
- Nginx 1.10.0
- MariaDB 10.0.24
Владение файл user:www-data. Каталоги - 775, а файлы - 664
Ошибки включены в файлы conf conf PHP, и я вижу ошибки с отдельными страницами PHP, это происходит только на сервере в контексте ошибок, происходящих на плагинах PHP WordPress.
Это очень неприятно, поскольку я не понимаю, почему это происходит. У кого-нибудь есть понимание, которое могло бы помочь мне понять это?
EDIT
Чтобы быть более ясными, вот что я имею в в.ч.-конфигурации для включения отладки:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
Других значений отладочного дефолта истину так что это должно быть все, что мне нужно.
Любопытно, что я только что заметил, что error_log() ничего не делает внутри файла WordPress, а trigger_error() вызовет ошибку 500.
Это похоже на какую-то ошибку, основанную на разрешении, но я не уверен, что. Мне действительно нужна помощь в этом, так как разработка в этом случае практически невозможна без текста ошибки.
ошибки в разрешении файлов обычно возвращают ошибку 403, ошибка 500 обычно означает, что сценарий сервера терпит неудачу, но если он не дает никаких диагнозов в журналах ошибок, возможно, вам нужно использовать старомодный анализ точки останова, чтобы увидеть, где он ломается сначала вниз. Более внимательно изучать бит кода, который ломается, проще, чем поиск игл в стоге сена. –
Ошибка не является ошибкой разрешения файла (я сам ее бросаю), но тот факт, что она не регистрирует ошибку или ее отображение, заставляет меня думать, что это ошибка разрешения с php/nginx в некотором роде. Это просто догадка. Если бы я знал, что это вызывает, тогда я бы это исправил, но я здесь пытаюсь найти помощь для этого. Мне действительно нужно иметь возможность получать сообщения об ошибках, отлаживать приложения по строкам и проверять значения, чтобы получить подсказку о том, что может быть ошибкой, и это не похоже на подходящее решение для меня. Мне просто нужно иметь возможность получать сообщения об ошибках, а не использовать обходной путь. – Guerrilla
Общие ошибки - это уловка для чего-то языка, авторы которого не ожидали, что разработчик попытается. Я бы использовал тесты ошибок/handers. Если nginx не предоставляет разрешение на ресурс, это звучит как неправильная конфигурация или нет, но трудно сказать. Вы не можете полагаться на пожарную сигнализацию, чтобы погасить огонь, и не исключает, что вы будете осторожны с открытым огнем. Сообщения об ошибках могут быть полезны, но предоставляют разработчику безошибочную систему безопасности. Ниже вы видите, что это ошибка в другом плагине. Плагины Wordpress слишком глобальны. –