web-dev-qa-db-ja.com

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_のsiteurlhome)に切り替えました。 _/wp-admin/upgrade.php_は、続行する前にデータベースを更新する必要があると言っています。

私はおそらく誤っていくつかのものを省略しましたが、実行する必要がある他のチェックを教えてください。私に何ができるかを見ていきます。

2
Nathan Tuggy

今日、ほぼまったく同じ問題に遭遇しました。コードをトレースして、原因を見つけます。プラグインの1つがエラーをスローせず、ただ終了するためです!!

Wp-setting.phpのwp_get_active_and_valid_plugins()の各要素をvar_dumpすることで、どのプラグインであるかを知ることができます。

ここに示されている最後のプラグインは、問題の原因となったプラグインです。

したがって、エラーはまったくありませんでした。

enter image description here

2
Jasper