WordPressにはリビジョン管理機能があります。
リビジョン管理 – WordPress Codex 日本語版.
しかしこの機能、必要としていない人には余計なオーバーヘッドで、編集画面もちょっと重くなるような感じがします。そしてもちろん、データベースには公開データとは別にリビジョン情報が格納されるわけで、僅かではあるけれど無駄に容量を食うし検索も非効率になる。まー、本当に僅かだから、よっぽど容量が逼迫していなければ気にしなくていいと思うけどね。
で、まー、うちは別に逼迫してないんだけど、リビジョンを無効化してリビジョン情報の削除もしてみた。
とりあえずリビジョン管理を無効化してみる。wp-config.php にて wp-settings.php を読み込む前に以下の設定を追加。
define('WP_POST_REVISIONS', false);
ちなみに数字を設定すると保存するリビジョンの数を指定できるらしい。0でも無効になる。
リビジョンを無効にすると投稿の編集画面で変化がある。公開ウィジェットにあったリビジョンのメニューが消える。そして本文の下にあったリビジョンの一覧も消える。これで編集画面が少し軽くなるかも。
インストール直後ならこれで完了。だけど、しばらく運用した後だとリビジョン情報がけっこうたまっているはず。MySQLに入って確かめてみる。
mysql> SELECT post_type, count(*) FROM sh_wp_posts GROUP BY post_type; +---------------+----------+ | post_type | count(*) | +---------------+----------+ | attachment | 495 | | nav_menu_item | 8 | | post | 921 | | revision | 723 | +---------------+----------+ 4 rows in set (0.00 sec)
post_type が revision になっているデータがたくさんある。記事と同じぐらいになっている。うちのブログはNucleusからの移行なのでWordPressになってからの記事が全てではない。ということは、最初からWordPressだったらリビジョン数が記事数を超えていたかもしれない。そうなると、あんま僅かでもないのかな。
というわけで、こいつらを消します。まずは件数を確認。
mysql> SELECT count(*) FROM sh_wp_posts WHERE post_type = 'revision'; +----------+ | count(*) | +----------+ | 723 | +----------+ 1 row in set (0.00 sec)
消す。
mysql> DELETE FROM sh_wp_posts WHERE post_type = 'revision'; Query OK, 723 rows affected (0.02 sec)
消えた。
mysql> SELECT count(*) FROM sh_wp_posts WHERE post_type = 'revision'; +----------+ | count(*) | +----------+ | 0 | +----------+ 1 row in set (0.00 sec)
うむ。
さて、これでもうリビジョン情報は生成されないはず。編集画面を開いて適当に書き込んで置いといてみる。「下書きを保存しました」の表示を確認して、MySQLの方で状況を確認してみる。うん、出来ていない。自動保存は単に自動保存になっていて、リビジョンではなくなっている。
しかし、公開済みや予約済みの記事の場合は違った。リビジョンが生成されてしまう。公開されているデータを更新せずにリビジョンを持たせる場合、そういう仕様になるのは仕方がない。そう、仕方がないのだ。
というわけで、今日はここまで。