200OK空白ページの設定Wordpress復元テスト時VM
率直に言ってかなり時代遅れの（レガシー、何ができますか？）CentOS/Apache/MySQL/PHP/Wordpressサーバーの部分バックアップをVMの新しいコピーで復元することにより、テストしています。関連するパッケージ。多くの試行錯誤の末、_http://<site-domain-name>/_からのNice 200OK応答を正常にwgetできるようになりました（これは、ホストファイルのシェナニガンによってlocalhostに送信されます）残念ながら、本体の長さはゼロであり、ログは基本的に空です。
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ファイルは、httpdワーカープロセスが実行されていることを確認したApacheユーザーが所有しており、すべて_-rwxr--r--_です。
MySQL接続情報がwp-config.phpに正しいことを確認しました。 mysql、mysqli、およびpdo_mysqlはすべてphpinfo()出力で有効になります。
xdebug + WinCacheGrindによると、PHPはwp-blog-header.phpとそれが呼ぶもの（wp-settings.phpとその仲間の1830ms）で2001msを費やしていますが、これは少し過剰に思えます遅いラップトップではVM）でレンダリングされますが、ほとんど静的なページです。die()を呼び出すものはありません。
_/wp-admin/options.php_ 302 -_/wp-admin/upgrade.php_にリダイレクトします。これにより、アップグレードは不要（？）であり、サイトルートを指す[続行]リンクが表示されます。一方、_/wp-login.php_は、ライブサイトのIPアドレスを使用することを除けば、もっともらしいように見えます。これに基づいて、データベースにアクセスし、数値IPをドメイン名（つまり、_wp_options_のsiteurlとhome）に切り替えました。 _/wp-admin/upgrade.php_は、続行する前にデータベースを更新する必要があると言っています。
私はおそらく誤っていくつかのものを省略しましたが、実行する必要がある他のチェックを教えてください。私に何ができるかを見ていきます。
今日、ほぼまったく同じ問題に遭遇しました。コードをトレースして、原因を見つけます。プラグインの1つがエラーをスローせず、ただ終了するためです!!
Wp-setting.phpのwp_get_active_and_valid_plugins（）の各要素をvar_dumpすることで、どのプラグインであるかを知ることができます。
ここに示されている最後のプラグインは、問題の原因となったプラグインです。
したがって、エラーはまったくありませんでした。
