PHP создает совершенно белую страницу, никаких ошибок, журналов или заголовков.

Запустите страницу с консоли, и вы получите сообщение об ошибке.

 // nix php yourFile.php // Windows c:\path\to\php.exe yourFile.php 

У вас может быть файл .htaccess в этом каталоге, который изменил отчет об ошибках.

Чтобы протестировать, попробуйте явно установить эти параметры в верхней части вашего php-скрипта, что дает вам проблемы.

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

Я также видел, что это вызвано чрезмерно усердными антивирусными пакетами. Некоторые из них содержат веб-прокси-программное обеспечение для фильтрации Интернета и электронной почты. В этом случае страница будет просто продолжать загрузку в бесконечность, но никогда не будет завершена.

Остерегайтесь оператора @ (подавления ошибок), если у вас есть синтаксическая ошибка в строке с @ PHP, будет тихо выйти.

Чтобы обнаружить это условие, используйте set_error_handler и напишите свой собственный обработчик ошибок, вам все равно будут вызваны ошибки, если используется @.

Вы говорите, что работают другие скрипты PHP, поэтому это означает, что это, вероятно, не проблема Apache. У вас также есть все правильные настройки ведения журнала, и ничего не регистрируется, поэтому вполне возможно, что PHP выходит нормально, прежде чем он выведет что-нибудь. Возможно, одно из следующего:

• Неуместное утверждение exit() ? Вы работали над кодом, возможно, вы добавили быстрый exit() чтобы что-то проверить, и забыл удалить его?
• Идея don.neufeld по проверке использования оператора @ , которая подавляет любые сообщения об ошибках, стоила мне часов от времени отладки в прошлом. Определенно, что-то искать.

В подобных ситуациях подход отладки бедных людей может дать некоторые быстрые результаты. Выбросить exit('wtf'); в качестве первой строки в рассматриваемом скрипте. Это работает? Результаты этого теста сразу же исключают всевозможные возможности независимо от результата. Если вы не получаете какой-либо вывод, то это, вероятно, проблема на уровне сервера (конфигурация, плохой модуль и т. Д.), Хотя будьте осторожны с буферизацией более высокого уровня. Если вы получаете выход, то вы знаете, что сервер в порядке, и проблема лежит глубже в вашем скрипте, и в этом случае вы можете переместить вызов exit() на несколько строк, полоскать и повторить. Не элегантный способ отладки, но он быстрый и грязный, и вы, вероятно, найдете проблему через пару минут.

Проверьте настройку php.ini для short_open_tag = Вкл. Или short_open_tag = Выкл.

Наиболее вероятно, что Apache рушится. Возможно, просмотрите журнал ошибок apache или присоедините отладчик.

Подробные сведения о поиске отладки процесса apache / php в Windows можно найти по адресу http://bugs.php.net/bugs-generating-backtrace-win32.php

Я угадал ответ на эту проблему – оказывается, что PHP 5.2.5 не может справиться с рекурсивной смертью.

 <?php class A { public function __construct() { new B; } } class B { public function __construct() { new A; } } new A; print 'Loaded Class A'; 

Нет заголовков, ошибок, содержимого, журналов, дампов xdebug, всплесков памяти, всплесков CPU, сбоев сервера или чего-либо еще. После примерно 150 мс PHP просто «кончается». Weird.

Чтобы включить отображение ошибок в вашем PHP-коде, если вы ничего не видите, вставьте

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

Пример, когда эта потенциальная возможность сэкономит вам много времени:

Этот код в файле шаблона joomla default.php отображает пустую страницу без сообщений об ошибках без строк 20 и 21

 17 <?php if ($params->get('title_article_linkable')) { ?> 18 <a href="<?php 19 $url = JRoute::_(ContentHelperRoute::getArticleRoute($item->id,$item->catid)); 20 ini_set('display_errors',1); 21 error_reporting(E_ALL); 22 echo $url; ?>"> 23 <?php echo $this->item->title; ?></a> // should be $item->title !! 24 <?phpLL000000 } else { ?> 25 <?php echo $item->title; ?> 26 <?php } ?> 

Вывод:

проверьте журнал событий.

Когда это происходит, обычно стоит вырезать как можно больше кода и видеть, можете ли вы получить что-то на странице, чтобы показать.

Это может быть связано с незакрытой цитатой где-то в вашем коде или незакрытой скобкой. Это может привести к тому, что оператор эха будет рассматриваться как текст или в другой функции и т. Д.

И, хотя все ошибки ДОЛЖНЫ сообщаться, я обнаружил, что на самом деле не все сообщения об ошибках, вероятно, из-за ini-настроек на общем хосте, который недоступен.

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

вы проверяли свои файлы для закрытия ?> тегов? Или, что более важно, любые пробелы после них …