新規インストール時の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の923行目で接続がタイムアウトしました

^{これはもちろん、開発サーバーで実行されているWP_DEBUGためtrue、フラグがに設定されています。}

これは断続的に発生するため、に問題があるようwp-cronです。

これはおそらくWordPressのエラーか、私のサーバーの何か問題ですか？心配する必要がありますか？

サーバーは、LAMPスタックを備えた新しいUbuntu Server 12.04 VMです。

グーグル検索は私がこれを経験している唯一のものではないことを示しています。（実際のエラーを確認するには、リストされているページのバッファバージョンまたはインデックスバージョンを参照してください。）

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

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

一般的な設定ミス：

1. サーバーにはDNSがないため、「example.com」がそれ自体であっても、だれが「example.com」であるかを判別できません。
2. サーバー管理者は、セキュリティの見当違いの試みで「ループバック」リクエストをブロックしているため、実際にはそれ自体にコールバックすることはできません。
3. サーバーは "mod_security"などと呼ばれるものを実行しており、頭の悪い設定のために呼び出しをアクティブにブロックしています。

私の場合の問題は、実際にはファイアウォール（pfSense）が原因でした。ファイアウォールには、デフォルトで「NATリフレクションを無効にする」（一般的な理由2として記載）があります。

サーバー自体で、私はtelnetを使用して自分に到達しようとしましたが、結果は次のとおりです。

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

これを修正するには、ファイアウォールで[ NATリフレクションを無効にする]をオフにする必要がありました。私の場合、これはpfSenseのWebインターフェイスのSystem-> Advanced-> Firewall / NATにありました。
^{出典：http : //forum.pfsense.org/index.php?topic=3473.0}

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

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

そして、もうwp-cronに関するPHPの警告を受けていません。

についてのこの詳細な回答を読んだ後、私はこれを理解し、それがどのように機能するかを説明しました。wp_cron

短い答え：これをwp-config.phpファイルの定義に追加します：define（ 'ALTERNATE_WP_CRON'、true）;

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

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

動作方法は非常に簡単です。WordPressページが読み込まれるたびに、内部的にWordPressはwp-cronを起動する必要があるかどうかを確認します（現在の時刻を最後にwp-cronを実行した時刻と比較して）。wp-cronを実行する必要がある場合は、wp-cron.phpファイルを呼び出して、自分自身へのHTTP接続を確立しようとします。

それ自体へのこの接続は、理由があります。wp-cronにはやるべきことがたくさんあり、その作業には時間がかかります。たくさんのことをしている間、ユーザーに自分のウェブページを表示するのを遅らせるのは悪い考えです。そのため、その接続をそれ自体に戻すことにより、別のプロセスでwp-cronプログラムを実行できます。WordPress自体はwp-cronの結果を考慮しないため、1秒だけ待機してから、ユーザーの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ファイルで定義します。

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ファイル内。