カテゴリー: WordPress

WordPress のリビジョン機能は冷遇されているようで検索すれば無効化する方法がたくさん見つかります。 一方でこの機能が「使える」ものだったらやっぱり使いたいよなあ、という人も多いのではないでしょうか。 ブログ記事は書き捨てというやり方だけでなく、注目を集め反応が多かった記事に情報を追記していく場合もあるでしょう。 また、WordPress のビジネス利用も増えていますが、そうであればなおさらリビジョン管理は重要です。 そこで今回は現行のリビジョン機能の何が問題でどうすれば解決するかをまとめたいと思います。

まあ、リビジョン機能止めて別に困らないという人はそれでいいのですけれど。

まずは正しい認識を

まず、WordPress のリビジョン機能について正しい認識を持ちましょう。 あまり理解されていないように思われるのは以下の点です。

• 自動保存は 1世代のみ
• リビジョンが作成されるのはポストテーブル (wp_posts) 内容のみ。 wp_postmeta や wp_term_relationships などの関連テーブルは (プラグイン等を用いない限り) リビジョンが作成されない。

つまり、デフォルトの 60秒間隔自動保存でバンバンリビジョンが増えていくというわけではないです。 また、ポストテーブルのリビジョンのみ、すなわちカテゴリーやタグの付け替え履歴は残らないので、WordPress のリビジョン機能は、基本的に記事にしたテキストデータの変更履歴を取るための機能と捉えるのが良いと思います。

データベース関連についても一言言っておきます。

• 通常の一記事表示ではインデックスを使用した検索になるので、ポスト数が増えても検索時間は比例しない。 なので、個人ブログレベルであれば、リビジョンを作成したからといって (よほど作りの悪いテーマやプラグインを使っていない限り) パフォーマンスに影響が出ることはまずない。

まあ、データベースの容量に関しては確かにリビジョンを作成することでその分使用領域は増えます。 しかし、所詮テキストデータなので、画像に比べればたかが知れています。

あっ、まさかリビジョンを作成するとそのページで使った画像まで何世代も保管されちゃう、なんて思っていたりします？ 念のために言っておきますが、それはないです。 イメージデータそのものはデータベースに入らないですし。

もう一度書きますが、リビジョンが作成されるのはポストテーブルの内容のみです。 ポストテーブルの内容を知らなければこちらで確認しておきましょう。 タグやカテゴリーの情報はポストテーブルに入っておらず、別テーブルから post_id を使ってポストテーブルを参照するようになっています。

でもリビジョン多くね？

と、ここまで読んでも「実際には多数リビジョンが出来てるし、嘘書いてんじゃねーの？」と疑っている人もいるでしょう。 確かにリビジョンが多く作成されてしまうのは事実です。 これは WordPress の以下の動作によるものです。

1. 下書きの状態 (公開前も含む) でプレビューをするたびにリビジョンが作成される。
2. クイック編集や一括編集でもリビジョンが作成される。

1. については思い当たる方が多いのではないでしょうか？ 公開前はプレビュー操作を行って最終的な見栄えをチェックしながら文章を調整することがあると思いますが、そこでプレビューする度にリビジョンができてしまうのです。公開された記事のプレビュー操作では自動保存リビジョンとなるのでどんなにプレビューしても 1世代なのですが、公開前だと何世代ものリビジョンができてしまいます。 たいていの場合は公開初版のリビジョンだけあればよいですよね。

2 については更に不要です。 このような編集方法を採るときはタグやカテゴリーを直す場合が多いと思うのですが、そうなるとポストテーブルの項目に変更は発生しないことが多いにも関わらずリビジョンが作成されてしまうということになってしまいます。 ですので、リビジョン比較をしても「同じ内容です」というちょっと悲しいリビジョンばかりできてしまいます。

どうすりゃいいのさ？

さて、これらの不要なリビジョンを保存せずに、意味のあるリビジョンだけ残すにはどうすれば良いのでしょう？ ちょっと考えてもどうしようもなさそうですね。 でも簡単な解決策があるんです。 それは…。

(縦に長い空白地帯)

じゃーん。 リビジョン管理用のプラグイン「Thin Out Revisions」を使えばよいのです。 以下の手順で不要なリビジョンとおさらば！

1. あなたのサイトのプラグイン検索画面から Thin Out Revisions を検索してインストール、有効化する
2. 「設定」－「Thin Out Revisions」とメニューを選び 3項目全て ON にして保存する

えっ？ 作者が日本人っぽい？ どっかで見たアイコン？

…実は私がつくったのです。

ステマではありません。作者による告知です！ それとこんな機能もあります。 気に入ったら是非つぶやいたり、「いいね！」したりしてください。お願いします！ お願いします！

(後半雰囲気を変わってしまいましたが、同じ著者によるものです。セッティング項目の見出しは一応読んでね。)

WordPress のマルチサイト化について経験に基づきもろもろをまとめておきます。

はじめに

「マルチサイト」は 1つの WordPress インストレーションで複数のブログを運用するための機能のことです。 各ブログごとにドメインを分ける「サブドメイン方式」と、同じホスト名でディレクトリを分ける「サブディレクトリ方式」があります。

インストール完了直後に設定するのがお勧め

既に運用を始めている WordPress を後からマルチサイト化することもできますが、それなりの設定変更となるので運用を始める前にマルチサイト化しておくのが良いと思います。 一人でブログを書き始めるとしても、将来複数のブログ (例えば、日本語版と英語版とか、仕事用と趣味用とか) を運用したくなるときが来るかも知れないので、とりあえず失敗してもさほど痛くない運用開始前にやっておこうということです。 そもそも最初にやっておいた方が制限も少なくすんなり設定できるはずです。 最初からマルチサイト化しておけば「マルチサイト未対応プラグインを使ってしまい切り替えるときに困る」ということもありません。 マルチサイト機能を有効化しておいて 1つのブログで記事を書き始めれば良いのです。

運用開始後はサブドメイン方式一択

運用開始後にマルチサイト化する際の制限として、サブディレクトリ方式はできず、サブドメイン方式でやるしかないというものがあります。 公式情報には以下のようにあります。

You cannot choose Sub-directory Install (for a path-based network) if your existing WordPress installation has been set up for more than a month, due to issues with existing permalinks.

一か月経つとパーマネントリンクの何がかわるのかが今一つわからないのですが、基本的にはサブディレクトリ方式でマルチサイト化したいならばインストール直後に設定しなければならないと捉えておくべきでしょう。 その他にもサブドメイン方式を選ぶときは WordPress ディレクトリがドキュメントルートでなければならないと書かれています。 以下のような URL はダメということです。

http://example.com/wordpress/

あるいは下の様に標準ポートでない場合はそもそもマルチサイト化できません。

http://example.com:8000/

ハマらないために公式情報はきちんと読んでおきましょう。

サブドメイン方式の構成

実際のところ、私もマルチサイト機能を知ったのは運用開始後なので、選択の余地はありませんでした。 というわけでここからはサブドメイン方式の話です。 共用レンタルサーバでは仮想ホスト機能を使いホスト名とディレクトリを対応付けすると思いますが、使用するホスト名は全て同一の WordPress ディレクトリに対応するように設定を行います。 以下のようなイメージです。

example.com → wordpress ディレクトリ (最初のサイト)
sub1.example.com → wordpress ディレクトリ
sub2.example.com → wordpress ディレクトリ

もちろん DNS のレコードもドメインの数だけ登録して同じ Web サーバーを指すようにしておかねばなりません。

実際にやってみる

実際の手順は公式情報の通りです。 wp-config.php や .htaccess の修正、blogs.dir の作成といったあたりをこなさなければなりませんが、どのように変更するかは指示されるのであまり迷うこともありません。 あちらこちらのブログにやり方が書かれていますが、中途半端な記事を読むよりは公式情報を読んで作業する方がすんなり行くように思います。 英語も難しくないんで慣れましょう。

1点注意があるのですが、それは .htaccess の修正です。 これを失敗すると 2番目以降のサイトでアップロードした画像が表示されなかったりします。 私の場合、元の .htaccess は以下の様なものでした。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

その .htaccess に以下を追加するよう指示されました。 (少なくとも私にはそう読めました)

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

しかし、実際は後ろに追記しても動かず、正常動作のためには指示された内容に置き替えなければなりません。 このあたり WordPress バージョンや状況によって表示される指示が異なる可能性があるので Apache の Rewrite ルールをある程度把握しておかねばなりません。 元 .htaccess の最初の RewriteCond からの 3行で以下の置き換えが行われます。

「実体としてのファイルやディレクトリが無い URL は /index.php に書き替え処理を停止する ([L]フラグ)」

サブドメインサイトにアップロードされたファイルを表示するための書き替えは以下の行なのですが、実体がない URL の置き換えなのでここに来る前に先のルールが適用されると /index.php に変換され処理が終わってしまいます。

RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

ちなみに追記指示分の最初の RewriteCond からの 3行は以下の置き換えルールです。

「実体としてファイルかディレクトリが存在する URL は変換せず ("^ -" の部分) 処理を停止する」

ド・モルガンの法則でしたっけ？ 最終行は残り全て index.php に書き替えるので結局元の .htaccess の RewriteCond の部分と同じ結果になるんですよね。 なので、元のルールは必要なく、表示されたもので置き換えれば動きます。 Rewrite ルールは奥が深いです。 私も「^ -」と「. -」の差異とか / があったりなかったり等の細部は気にしないことにしましたが、ある程度は把握していないと動かずに苦労することになるのです。

ということもあったりなので、インストール直後のマルチサイト化がお勧めなのです。 まあ、この記事を目にする人の多くは既に WordPress を運用しているんだろうとは思いますが…。