Я тестирую частичное резервное копирование откровенно устаревшего (устаревшего, что вы можете сделать?) Сервера 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.
Последний показанный здесь плагин вызвал проблему.
Так что ошибок вообще не было.