Twitterでの議論に続いて、wordpress.orgにはプラグインのセキュリティアップデートを自動プラグインアップデートの受信にオプトインしていないサイトにもプッシュする機能があるようです。誰もがその合理的な理由を説明できますか、そしてどうやってこの種の更新をブロックできますか?
一方で、この機能はwordpress.orgの「魔法」によって制限されているのでしょうか、それとも私自身のサーバーから配布されているプラグインやテーマを更新するのと同じメカニズムを使ってもよいのです。コア(明らかに私のコードでは更新を引き起こすためにすべてを迂回することができます。問題は、定数の設定やさまざまな更新関連のフィルタの使用によって表現されるように、ユーザーの期待にどのように最もよく合わせるかです。).
WP_Automatic_Updater
にあるwp-admin/includes/class-wp-upgrader.php
クラス内を見ると、自動更新が許可されているかどうかを判断するためにメソッドis_disabled
によって使用されるメソッドshould_update
に注意してください。
is_disabled
メソッドは以下の条件下でtrueを返します。
DISALLOW_FILE_MODS
定数が定義されていてtrue
である場合WP_INSTALLING
定数が定義されている場合AUTOMATIC_UPDATER_DISABLED
定数がtrue
として定義されている場合ただし、後者の定数AUTOMATIC_UPDATER_DISABLED
はフィルタautomatic_updater_disabled
にも関連付けられているので、定義されている場合でも、値を他の場所でフィルタ処理することが可能です。その場合は、次のフックを宣言することで対処できます。
add_filter( 'automatic_updater_disabled', '__return_true' );
これがWP_Automatic_Updater
クラスからの抜粋メソッドです。
wp-admin/includes/class-wp-upgrader.php:1730
/**
* Whether the entire automatic updater is disabled.
*
* @since 3.7.0
*/
public function is_disabled() {
// Background updates are disabled if you don't want file changes.
if ( defined( 'DISALLOW_FILE_MODS' ) && DISALLOW_FILE_MODS )
return true;
if ( defined( 'WP_INSTALLING' ) )
return true;
// More fine grained control can be done through the WP_AUTO_UPDATE_CORE constant and filters.
$disabled = defined( 'AUTOMATIC_UPDATER_DISABLED' ) && AUTOMATIC_UPDATER_DISABLED;
/**
* Filter whether to entirely disable background updates.
*
* There are more fine-grained filters and controls for selective disabling.
* This filter parallels the AUTOMATIC_UPDATER_DISABLED constant in name.
*
* This also disables update notification emails. That may change in the future.
*
* @since 3.7.0
*
* @param bool $disabled Whether the updater should be disabled.
*/
return apply_filters( 'automatic_updater_disabled', $disabled );
}
私はさらに読むために次のリンクを提案するでしょう:
http://codex.wordpress.org/Configuring_Automatic_Background_Updates
...これは、アップデートに対して無効にするコンポーネントを細かく制御するために利用可能な定数とフィルタのリストを詳細に提供します。
自動プラグインの更新を無効にするだけの場合は、次のようになります。
add_filter( 'auto_update_plugin', '__return_false' );
...など.
(私が間違っているなら誰かが私を直す)
読者のためにいくつかの文脈を加えてみましょう。この質問全体は、それ自体YoastのWP SEOプラグインの強制自動更新に対する応答であるこの{ Twitter status の結果としてのものです。詳しくは https://yoast.com/wordpress-seo-security-release/ をご覧ください。
同じファイル内に含まれるwp-includes/update.php
関数内から起動される同じ名前のdo_action('wp_maybe_auto_update')
を持つフックで起動されるwp_maybe_auto_update
という名前のwp_version_check
内の関数があります。
それで、私がWordPress.orgがしたと思うのは、Yoast WP SEOプラグインに関連するセキュリティ上の欠陥の明らかな深刻さのために自動更新がユーザに強制されるように内部的にWordPressのバージョンをインクリメントしたことです。
_ { quote _自分自身を叫ぶために:
問題の深刻さのため、WordPress.orgチームは強制的な自動更新を公開しました(ありがとう!)
実際にこれがWordPress.orgリポジトリに新しいバージョンを持っている他のプラグインも自動的に更新したのか、それともWordPress.orgがどのプラグインを最後から自動更新できるかを決定できるかどうかは100%確信できない。コード内で、この種の判断を可能にするものもあります。
WordPress.orgリポジトリ内でホストしているプラグインに対しても、同じメカニズムを自分で使用できるかどうかに関しては、もちろん、公式リポジトリの外部にあるものについては、まったくわかりませんが、可能であるかもしれません。 WP_Automatic_Updater
クラスをインスタンス化し、それをチェックするためのコンテキストを提供しますが、最終的にはwp_update_plugins
内のwp-includes/update.php
という関数に入り、公式のWordPressリポジトリAPIをチェックします。
私は間違っているかもしれませんので、誰かがさらに何か追加するものがあれば、チャイムしてください。