После отладки приложения codeigniter, которое было установлено в новую среду разработки, я начал волноваться, увидев белые экраны, которые больше не доступны. Я смог решить каждую из ошибок, вызвавших это, но это заняло слишком много времени.
PHP error_reporting(E_ALL) и display_errors", 1 Я даже установил Xdebug в надежде получить больше выходных данных, но нет. Мои параметры ведения журнала также работают, но ничего не записывается в журнал.
Есть ли способ получить что-то информативное, напечатанное вместо полного белого экрана? Это, безусловно, сократит мое время, затрачиваемое на решение возможных ошибок, вызывающих это?
Большое спасибо!
Ссылка: Почему Code Igniter дает мне белую страницу?
Если есть фатальная ошибка компиляции, тогда вы можете получить пустую страницу. Попробуйте сделать
php -l <filename.php>
против вашего скрипта
Посмотрите на вершину /index.php для вызова error_reporting() – и убедитесь, что он не меняет вашу конфигурацию php.ini на что-то еще (кроме E_ALL ).
И поскольку вы не error_reporting = E_ALL свою конфигурацию php.ini , убедитесь, что у вас есть error_reporting = E_ALL .
С момента моего вопроса я выяснил, что ничто не гарантирует, что ошибки всегда выводятся с помощью PHP, который, кажется, бросает белые экраны здесь и там. Независимо от встроенных настроек PHP.
Я выяснил, что наилучшим обходным решением является использование следующей строки для обеспечения того, чтобы протоколирование ошибок помещалось в файл, который легко доступен и контролируется приложением:
ini_set('error_log', MYPATH .'logs/errorlog.log');
Насколько я тестировал, когда появляются белые экраны – он также попадает в этот журнал ошибок. Кажется, это самый простой способ узнать, что происходит, когда что-то идет не так.
Grep файлы для 'error_reporting' и 'display_errors', приложение может отключить его где-нибудь.
Кроме того, чтобы иметь возможность видеть ошибки синтаксического анализа, вам нужно установить error_reporting / display_errors в файле php.ini или файл .htaccess, установив его в файлах сценариев, и не приведет к тому, что вы укажете белую страницу есть ошибки синтаксического анализа.
Лучше всего иметь контрольный список общих проблем, которые могут вызвать это, поскольку по умолчанию CI
error_reporting(E_ALL);
список продолжается ..
Помимо всего прочего, также убедитесь, что что-то, замаскированное оператором @ (оператор подавления ошибок), не вызывает фатальную ошибку.
Рассмотрите возможность установки переменной конфигурации PHP error_log – это может быть полезно, если у вас есть установка кода error_reporting() без вашего ведома. Затем вы можете проверить журнал ошибок и посмотреть, какие ошибки произошли, если они есть.
Убедитесь, что ваши журналы и папка с кешем внутри / система chmod'ed до 777.
У меня была эта проблема на моем недавно установленном сервере. Debian 7. Я включил ведение журнала, отчеты об ошибках, отключил gzip и т. Д.
Однако моя PHP-установка не включала MySQL. Включение MySQL помогло мне.
Убедитесь, что в ваших файлах нет пробелов, выходящих за пределы буфера CI, особенно если включено сжатие. Вы можете проверить это, отключив сжатие в вашем файле конфигурации CI.
См. Второй шаг: http://codeigniter.com/user_guide/installation/upgrade_141.html (обратите внимание, что хотя это обновление, оно содержит фрагмент файла конфигурации, который объясняет эту проблему.)
Не случайно ли вы создали кешированный вывод для этого конкретного метода внутри вашего контроллера. Потому что если это так, то он может создать кешированную версию страницы и практически эта страница даже не работает. Появляется страница выхода из кэшированной ошибки. Проверьте папку кэша внутри приложения. Он должен содержать только файл index.html.