悪夢の wp-cron.php

BY admin
|

私が WordPress で抱えている大きな不満は、デフォルトの wp-cron.php の実装についてです。 WordPress がデフォルトで wp-cron.php をどのように使用するかをご存知の方は、この記事の次のセクションに進んでください。

ファイル wp-cron.php は、WordPress サイト内のスケジュールされたイベントを処理する部分です。

wp-cron.phpが適切に動作するためには、1分間に1回を超えない頻度で実行する必要があります。 しかしながら、デフォルトの動作では、サーバー上で実際のシステムレベルのcronジョブを設定する必要はありません。 その代わりに、それはすべての着信リクエストに対してピギーバックメソッドを使用します。 サイトへのリクエストがあると、WordPressは自分からHTTP(S)経由でwp-cron.phpファイルへの追加リクエストを生成します。

なぜデフォルトの wp-cron.php の動作は悪夢なのでしょうか。

デフォルトの方法は、1 時間あたりの訪問者が非常に少ない小さなサイトではまったく問題なく機能します。 しかし、中規模以上のサイト、あるいはボットによってスキャンされているサイト (最近では非常によくあります) に実装すると、現在処理しているトラフィックの 2 倍を得ることになります。 これは、自分自身に対する初歩的なDDoS攻撃となるのです。 これは、クーロンがHTTPリクエストを使って1分間に何度も実行されるからです。 HTTPリクエストは、ネットワーク・ソケットを介した接続を生成、交渉、確立する必要があるため、追加のオーバーヘッドを発生させます。 さらに、Webサーバーの有効容量にも影響を与えます。 このソリューションは、ほとんどの状況でうまくいきません。正直なところ、通常のトラフィックからサーバー上で悪用されたり攻撃ベクトルになったりする傾向があるため、デフォルトの動作として削除される必要があります。 これは、スケジュールされたタスクがスケジュールされた時間に実際に実行されることを保証します。

Wp-cron.php のデフォルトの動作を無効にするにはどうすればよいですか？

これは非常に普遍的で、簡単に行うことができます。 wp-cronfig.php ファイルを更新して、次の設定を含める必要があります。

define('DISABLE_WP_CRON', true);
  • wp-config.php ファイルは通常、サイトの public_html ディレクトリで見つけることができます。
  • この新しい設定は、次のように見える DB_COLLATE データベース行のすぐ後のファイルに置かれるべきです。
define('DB_COLLATE', '');

システム cron ジョブはどのように設定するのですか？

これは cPanel で簡単です。 cPanel Cron Jobs Documentation に詳細が記載されていますが、基本的には次のように行います。

  1. あなたのドメインの cPanel にログインします: yourdomain.tld/cpanel
  2. ページ上部のクイック検索ボックスに「cron」を入力し、
  3. 表示される「Cron Jobs」アイコンをクリックします。
  • これが表示されない場合、あなたのアカウントではクーロン ジョブ機能が有効になっていないため、クーロンの設定またはクーロン ジョブ機能を含むパッケージへの切り替えについて、ホスティング プロバイダーに相談する必要があります。 ページ下部のコマンドボックスにそのパスをコピーし、PHPによって実行されるファイルを/home/username/public_html/wp-cron.phpファイルに変更する必要があります。 フルパスを使用します。
  • 各パラメータの最初のエントリ(“*”)を選択します。
  • cron を追加するボタンをクリックして完了です。

    • なぜこの行為にそんなに厳しいのですか、合理的で簡単に修正できそうですが。 WordPress は最近どこにでもあり、Softaculous のような自動インストーラー ソフトウェアにより、WordPress は非常に多くのサイトにインストールされています。 WordPressは、デフォルトの動作が有効な状態でインストールされるため、基本的にどのサーバーに対しても攻撃のベクトルが向いています。 ホスティング業界が私たちの生活に浸透している今、多くの人がWordPressのサイトを持っていますが、自分のサイトが不具合を起こすまでこの問題を知りません。 デフォルトの統合は非常に不十分であり、削除されるべきです。 今日、あるサーバーだけで、500以上の異なるWordPressのインストールを見つけ、ボットがサーバー上の各サイトを攻撃しているのを見ました。 これらのサイトのすべてが、突然、サーバーの安定性の障害となりました。

    私は、この問題がケースバイケースで処理されることを理解しています。 しかし、世界中に非常に多くのインストールがあるため、このソフトウェアが生成する穴から保護するためにサーバーに特別な条件を設定しなければならないホスティング プロバイダーよりも、WordPress によって対処する方がよいでしょう。 この動作を削除し、サイトオーナーにシステムクーロンを生成することを強制するコストは、ベースラインと、システムクーロンジョブが適切に作成されるまでスケジュールタスクが実行されないという通知をWordPress管理インターフェイス内に配置する必要があります。 これは私のプログラミング能力の範囲内なので、彼らの範囲内であることは分かっています。

    WordPressは使いやすさを目的としているので、ターゲット消費者は通常、ホスティングの注意点についてほとんど知らない人たちです。 私は、ここでの責任はすべて WordPress にあり、彼らはそれに対するスタンスを取っていると考えています。 一方、ホスティング業界のシステム管理者は、デフォルトの WordPress インストール上で動作するボットによって制御不能になったサーバーを調査する際に、このひどい「機能」に悩まされることになります。