web-dev-qa-db-ja.com

PHP 新規インストールに関する警告（接続がタイムアウトしました）

私の新しいWordPress 3.4.1インストール（ノルウェー語）にアクセスすると、このPHP警告が表示されます。

警告：fopen（URL_TO_MY_WORDPRESS_PAGE/wp-cron.php？doing_wp_cron = 1341476616.7605190277099609375000）：ストリームを開くことができませんでした：接続はPATH_TO_MY_WP_FILES/wp-includes/class-http.php。23行目でタイムアウトになりました

開発用サーバーで実行されているので、これはWP_DEBUGフラグがtrueに設定されている場合はもちろんです。

enter image description here

これは断続的に起こるので、wp-cronに問題があるようです。

これはおそらくWordPressのエラーなのでしょうか、それとも私のサーバーで何か問題があるのでしょうか。 心配しないでください。

サーバーはLAMPスタックを持つ新しいUbuntuサーバー12.04 VMです。

Googleの検索によると、これを経験しているのは私だけではありません。 （実際のエラーを確認するには、一覧表示されているページのバッファ付きバージョンを参照してください。）

編集：私はこれと同じPHP警告をフロントページにも表示しています。それはWebサーバがNATにかけられているという事実に関連しているかもしれませんか？現在、開発用サーバーでポート19235から80を指すようにファイアウォールを設定しました。

wp-cronwarnings
10
ohaal

答えはどうやらはい、私は心配する必要があります。調査の結果、警告はWordPressがホストされているサーバーの設定ミスに関連しているようです（つまり、WordPressではなくサーバーの問題です）。 ）.

よくある設定ミス：

  1. サーバーにはDNSがないので、たとえそれ自体であっても、 "example.com"が誰であるかを特定することはできません。
  2. 誤ったセキュリティの試みでサーバー管理者が「ループバック」要求をブロックしたため、実際には自分自身にコールバックすることはできません。
  3. サーバーは "mod_security"などと呼ばれるものを実行しています。これは、ブレッドデッド構成のために通話をアクティブにブロックします。

私の場合の問題は実際には私のファイアウォール（pfSense）が原因でした デフォルトでは "Disable NAT reflection"を持っています （一般的な理由＃2として記載されています）。

サーバー自体で、私はtelnetを使って自分自身に連絡を取ろうとしました、そして、結果は以下の通りでした：

 $ telnet external.server.hostname.com 19235 
 XXX.XXX.XXX.XXXを試行しています... 
 telnet：リモートに接続できませんHost：接続がタイムアウトしました

これを修正するには、ファイアウォールでDisable NAT reflectionを無効にする）を選択しなければなりませんでした。私の場合は、pfSenseのシステム - >詳細設定 - >ファイアウォール/ NATです。
ソース： http://forum.pfsense.org/index.php?topic=3473.0

enter image description here

これで、ファイアウォールを介して（サーバー上で）自分自身に正常に接続できます。

 $ telnet external.server.hostname.com 19235 
 XXX.XXX.XXX.XXXを試しています... 
 external.server.hostname.comに接続しました。 ]エスケープ文字は '^]'です。

wp-cronに関するPHP警告が表示されなくなりました。

私は読んだ後にこれを考え出しました wp_cronに関するこの詳細な回答、それがどのように働くかを説明します

短い答え：これをあなたのwp-config.phpファイルのdefineに追加してください：define（ 'ALTERNATE_WP_CRON'、true）;

マゾヒストには本当に長い答えがあります：予定された投稿は今ではなく、「壊れた」ことも一度もありません。WordPressの開発者はこれを修正できません。

問題はあなたのサーバが何らかの理由でwp-cronプロセスを正しく実行できないという事実にあります。このプロセスはWordPressのタイミングメカニズムで、スケジュールされた投稿からXMLRPC pingへのpingbackの送信まで、すべてを処理します。

使い方はとても簡単です。 WordPressページがロードされるたびに、WordPressは内部でwp-cronを起動する必要があるかどうかを確認します（現在の時刻と前回のwp-cronの実行時刻を比較することによって）。 wp-cronを実行する必要がある場合は、wp-cron.phpファイルを呼び出して、HTTP接続を自分自身に戻します。

それ自体へのこの接続は、理由があります。 wp-cronにはやるべきことがたくさんあり、その作業には時間がかかります。ユーザーが自分のWebページを見るのを遅らせるのは悪い考えです。そのため、その接続を自分自身に戻すことで、別のプロセスでwp-cronプログラムを実行することができます。 WordPress自体はwp-cronの結果を気にしないので、ちょっと待ってからユーザーのためにWebページをレンダリングすることに戻ります。一方、起動したwp-cronは、完了するまで、または実行時間がなくなるまで作業を続けます。

そのHTTP接続は、設定が不適切なシステムが失敗するところです。基本的に、WordPressはWebブラウザのように機能しています。あなたのサイトが http://example.com/blog だった場合、WPは http://example.com/blog/wp-cron.php を呼び出してプロセスを開始します。しかしながら、いくつかのサーバは単に何らかの理由でそれを行うことができません。考えられる理由は次のとおりです。

  1. サーバーにはDNSがないので、たとえ自身であっても、 "example.com"が誰であるかを特定することはできません。
  2. 誤ったセキュリティの試みでサーバー管理者が「ループバック」要求をブロックしたため、実際には自分自身にコールバックすることはできません。
  3. サーバーは "mod_security"などと呼ばれるものを実行しています。これは、ブレッドデッド構成のために通話をアクティブにブロックします。
  4. 他に何か。

重要なのは、何らかの理由で、あなたのWebサーバーはWordPressがその仕事をするのを妨げている何らかの非標準的な方法で設定されているということです。 WordPressは単にそれを修正することはできません。

ただし、この状態にある場合は、回避策があります。これをあなたのwp-config.phpファイルのto定義に追加してください：

define（ 'ALTERNATE_WP_CRON'、true）;

この代替方法では、cronを実行する必要があるときにユーザーのブラウザがリダイレクトを取得するようにリダイレクトアプローチを使用します。これにより、ドロップした接続でcronが実行を続けながらユーザーは直ちにサイトに戻ります。この方法は時々少し不確かなので、それがデフォルトではない理由です。

ソース： http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282#post-1175405

この詳細で詳細な記事で述べたように、あなたがあなたのサーバーの設定、あるいは該当する場合には環境を制御することができない場合 - 回避策は

define（ 'ALTERNATE_WP_CRON'、true）;

あなたのwp-config.phpファイルに。

10
ohaal