Назад | Перейти на главную страницу

200 OK, пустая страница, настраивающая Wordpress при восстановлении тестовой ВМ

Я тестирую частичное резервное копирование откровенно устаревшего (устаревшего, что вы можете сделать?) Сервера CentOS / Apache / MySQL / PHP / Wordpress, выполняя восстановление на виртуальную машину со свежей копией соответствующих пакетов. После многих испытаний и невзгод я дошел до того, что смог успешно wget хороший ответ 200 OK от http://<site-domain-name>/ (который просто переходит на localhost в силу махинаций с файлом hosts). К сожалению, тело имеет нулевую длину, а журналы в основном пусты.

phpinfo() сообщает, что display_errors, display_startup_errors, и log_errors все включены, и error_log установлен на /var/log/php_error, которого не существует; error_reporting - хорошая приборка 32767. Сообщенные версии MySQL, PHP и Apache более или менее соответствуют ожиданиям: 5.0.95, 5.3.29, 2.2.23; Wordpress - это 3.9.2.

httpd.conf смехотворно длинный и беспорядочный, но /etc/httpd/logs/error_log, /etc/httpd/logs/defSite_error_log (зависит от виртуального хоста) и /etc/httpd/logs/defSite_access_log (также зависящие от виртуального хоста) все существуют и записываются через определенные промежутки времени; Насколько я могу судить, ничего интересного не обнаруживается ни по времени, ни по содержанию, хотя журнал ошибок настроен на уровень отладки.

Все файлы PHP в каталоге (и подкаталогах) принадлежат пользователю apache, от имени которого, как я убедился, работают рабочие процессы httpd, и все они -rwxr--r--.

Я проверил, что информация о соединении MySQL верна в wp-config.php. mysql, mysqli и pdo_mysql включены в phpinfo() вывод.

xdebug + WinCacheGrind говорит, что PHP тратит 2001 мс на wp-blog-header.php и на то, что он вызывает (1830 мс из этого в wp-settings.php и его друзьях), что кажется немного чрезмерным для в основном статической страницы, хотя одна из них визуализируется в виртуальной машине на медленном ноутбуке; ничего не звонит die().

/wp-admin/options.php 302-перенаправляет на /wp-admin/upgrade.php, который затем говорит, что обновление не требуется (?) и имеет ссылку Продолжить, указывающую на корень сайта. /wp-login.php, с другой стороны, выглядит правдоподобно, за исключением того, что он использует IP-адрес действующего сайта. Исходя из этого, я вошел в базу данных и переключил числовой IP-адрес на доменное имя (т.е. siteurl и home в wp_options). Сейчас /wp-admin/upgrade.php говорит, что перед продолжением необходимо обновить базу данных.

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

Просто столкнитесь с почти такой же проблемой сегодня. Отследил код, а затем нашел причину. Это потому, что один из плагинов не выдает ошибок и просто ВЫХОДИТ !!

Вы можете определить, какой это плагин, по var_dump каждого из элементов wp_get_active_and_valid_plugins () в wp-setting.php.

Последний показанный здесь плагин вызвал проблему.

Так что ошибок вообще не было.