WordPress 自動アップグレードの処理内容を調べたのでメモを残しておきたいと思います。
別件で Git を使った WordPress の管理をやろうと思っているのですが、その中で WordPress の自動アップグレードは何をしているのかを知る必要が出てきたという具合です。
コードの細部までは追っていないですが大体わかったので以下のような事を書きます。
- WordPress のアップグレード処理の流れ
- アップグレード中のプラグイン停止について
- 手動によるメンテナンスモードへの切り替え方法
- DB 更新の手動テスト方法
- options.php は結構使える
目次
スポンサーリンク
WordPress のアップグレード処理の流れ
WordPress のアップグレード Q&A を元に必要な処理を確認してみます。
簡単にまとめると以下のような処理をやってるみたいです。
- 最新バージョンをチェック
- WordPress コアファイルをダウンロードし展開
- 整合性のチェック
- メンテナンスモードへ切り替え
- 新旧間でファイル差分をマージ
- DB バージョンのアップグレード
- 一時ファイルの削除
- メンテナンスモードを解除
項番 3 – 8 は wp-admin/includes/update.php が関係してる部分となっているようです。
簡単なメモとしては以下のような依存関係で動くみたい。
update.php → アップデート処理のファイル、class-wp-upgrader.php をインクルード。
class-wp-upgrader.php → class Core_Upgrader 内で update_core.php をインクルード。
update-core.php → update_core() でアップグレード処理。
1 番の最新バージョンのチェックは、以下の API にロケール情報だとか現在のバージョンを引数で渡しているようです。
API を叩くと json っぽいのが返って来るのでそれで確認している模様。他にどんな引数を渡しているか細かく見ていませんが、「locale」と「version」を渡せばそれっぽいデータが返ってきます。
http://api.wordpress.org/core/version-check/1.6/?locale=ja&version=3.6
また、目で確認するならバージョン 1.2 の API がわかりやすいと思います。
locale = ja, version = 3.6 を指定してます
ざっとですが、これでアップグレードの流れが掴めたと思います。
アップグレード中のプラグイン停止について
以下の Q&A によると、WordPress 2.7 以降より自動アップグレードではプラグインの停止は不要となったとのこと。
そもそも、プラグインを止める必要があった理由としては WordPress 本体のアップグレード中に、プラグインからの DB アクセスと衝突する恐れがあるからという事らしいです。後述の「メンテナンスモード」を実装したから今は不要になったのかなと思います。
ということは、メンテナンスモードに切り替えない場合はプラグインの停止は必要という事ですね。
スクリプトからメンテナンスするためにちょっと調べたのですが、管理画面以外からプラグインを一括停止するには以下の SQL を実行すれば行けます。(例は Akismet のみを有効化)
一括停止
mysql> SELECT * FROM wp_options WHERE option_name = 'active_plugins';
+-----------+----------------+---------------------------------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+----------------+---------------------------------------+----------+
| 35 | active_plugins | a:1:{i:0;s:19:"akismet/akismet.php";} | yes |
+-----------+----------------+---------------------------------------+----------+
mysql> UPDATE wp_options SET option_value='a:0:{}' WHERE option_name = 'active_plugins';
mysql> SELECT * FROM wp_options WHERE option_name = 'active_plugins';
+-----------+----------------+--------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+----------------+--------------+----------+
| 35 | active_plugins | a:0:{} | yes |
+-----------+----------------+--------------+----------+
- active_plugins の option_value の値をメモっておく
- option_value を初期値の a:0:{} でアップデート。
- 一括停止完了
一括再開
mysql> UPDATE wp_options SET option_value='a:1:{i:0;s:19:"akismet/akismet.php";}' WHERE option_name = 'active_plugins';
mysql> SELECT * FROM wp_options WHERE option_name = 'active_plugins';
+-----------+----------------+---------------------------------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+----------------+---------------------------------------+----------+
| 35 | active_plugins | a:1:{i:0;s:19:"akismet/akismet.php";} | yes |
+-----------+----------------+---------------------------------------+----------+
- active_plugins の option_value にメモった値でアップデート
- 一括再開完了
ただ、メンテナンスモードに切り替えればこの必要もなさそうなので次に移りたいと思います。
手動によるメンテナンスモードへの切り替え方法
メンテナンスモードに入ると以下のような画面が表示されます。
WordPressのメンテナンスモード
内容はともかく、これを表示するには WordPress のルートで以下のようにするとできます。
$ cd htdocs/wordpress/ $ echo '<?php $upgrading = time(); ?>' > .maintenance
これができると .maintenance を削除するまで、他のファイルへはアクセスができません。(管理画面も)
自動アップグレードにコケるとこれが残ったりもするようなので、その場合は落ち着いて SSH, FTP 経由で削除してやると良いと思います。
これは結構便利な仕組みですね。
手動によるアップグレードのテスト方法
WordPress のコアファイルをアップグレードすると、DB のアップグレードをしてください的な表示が出る場合もあります。
何をやっているかまで追えていませんが、コアファイルのバージョン毎に必要な DB バージョンもあり以下で確認できます。
ここも自動化したい所ということで、DB のバージョンをダウングレードしてちょっと実験しました。
mysql> SELECT * FROM wp_options WHERE option_name = 'db_version'; +-----------+-------------+--------------+----------+ | option_id | option_name | option_value | autoload | +-----------+-------------+--------------+----------+ | 52 | db_version | 24448 | yes | +-----------+-------------+--------------+----------+ mysql> UPDATE wp_options SET option_value=22442 WHERE option_name = 'db_version'; mysql> SELECT * FROM wp_options WHERE option_name = 'db_version'; +-----------+-------------+--------------+----------+ | option_id | option_name | option_value | autoload | +-----------+-------------+--------------+----------+ | 52 | db_version | 22442 | yes | +-----------+-------------+--------------+----------+
コアファイルは 3.6.1 ですが、DB バージョンのみをダウングレードしてみました。多分、アンマッチは良くないと思いますので、検証する場合は DB のバックアップもお忘れなく。
ログインした状態で、以下のような URL にアクセスしてみます。
http://example.jp/wp-admin/upgrade.php
DBの更新を促す表示
ボタンを押しても更新されますが、直接この処理を実行するには以下の URL にアクセスすれば OK です。
http://example.jp/wp-admin/upgrade.php?step=1&backto=
DBの更新後の表示
こんな感じでテストができました。
options.php は結構使える
ここはアップグレード処理とあまり関係しませんが、今回の情報収集中に options.php なる存在を知ったので合わせてメモしておきます。
ログインした状態で、以下のような URL にアクセスすると wp_options の設定値が一覧で見えちゃうという機能です。
http://example.jp/wp-admin/options.php
options.phpの表示例
しかも、設定値が UI から変更できたりもするので中々便利。
セットアップも自動化するために、option_name も後で調べたいと思ってたので手間が省けました。
SERIALIZED DATA と表示される部分は josn っぽいのが入ってます。ここは MySQL から直接弄るしかないみたいです。
長くなりましたが、WordPress のアップグレードについては以上です。