自動アップデートをするWordPressの仕組み(アップデート編)

自動アップデートの関数がどうやって呼び出されているかに関しては、先に私が書いた記事を閲覧することをお勧めします。

さて、アップデーターが呼ばれた後については、おおむね以下のような処理を踏みます:

自動アップデートが多重実行されないようにロックを確保する
プラグインのアップデートを確認
- あればアップデート実行
- そのあとキャッシュを消去
テーマのアップデートを確認
- あれば上記のプラグインと同じような手順を踏む
WordPressのコアアップデートを確認
- アップデート後、アップデートの結果をアップデートチェックの関数に引数を渡してWordPress.org APIに報告
翻訳にアップデートがあるかを確認
- あればアップデート実行
- そのあとキャッシュを消す
- 再度コア・プラグイン・テーマのアップデートをチェック
アップデートがされたなら
- メール送信
- テーマあるいはプラグインがアップデートされていればafter_plugin_theme_update()を結果とともに実行
- コアがアップデートされていればafter_core_update()を結果とともに実行
- do_actionでautomatic_updates_completeアクションを呼ぶ
自動アップデートのロックを解除し、再度実行可能にする

このうち、似たような処理をしているところと、それぞれのアップデート項目で特有であるところを切り分けて紹介していきます。

自動アップデート時の共通事項

すべてのアップデートフローで共通な事項として以下のようになります。

アップデート確認関数の中では、アップデートがあるかどうかをチェックします。もし、アップデートがある場合は$this->updateが実行されます。そのメソッドはwp-admin/includes/class-wp-automatic-updater.php内部にあります。そして、その関数はすべてのもの(コア・プラグイン・テーマ・翻訳)の自動アップデートをつかさどっています。

基本的にこのメソッドでやっていることはファイルの置き換えの処理・アップデート完了の通知となっています。しかし、プラグインだけは特別な取り扱いがなされています。

プラグイン自動アップデート時の特殊処理

さて、ここまでは共通事項を解説しました。

プラグインのみ、自動アップデート時には特別な処理があります。それは、ループバックテストによる自動ロールバック機能です。これは、プラグイン以外には実装されていない機能です。

これは、自動でアップデートをした後に、

実際に自分のサイトへアクセスを試み
エラーが出ないかどうかをチェックし
万が一ある場合にはバックアップファイルからバージョンを巻き戻すことをしています。

この仕組みはWP_Automatic_Updaterのクラス内にhas_fatal_errorという関数から提供されています。ここでは、メンテナンスモードのままエラーチェックをする、特殊なリクエストをサイトへ送信しています。

ロールバックの基準

そして、サイトはエラーの有無を示すJSONを埋め込んだ特殊な応答を返します。ここでエラーとなる基準はwp-includes/load.php内部にあるwp_finalize_scraping_edited_file_errors関数内に詳述されています。そこから要約するとE_CORE_ERROR, E_COMPILE_ERROR, E_ERROR, E_PARSE, E_USER_ERROR, E_RECOVERABLE_ERRORの場合にロールバックが実行されることがわかります。これらのロールバックが実行されるエラーは