これまで雑記ブログに記事を積み上げ、特定テーマの記事がたまってきたら別ブログに切り出す方針でやってきた。副サイトが増えるにつれて、WordPressの管理がわずらわしくなってくる。
新サイトを立ち上げるごとに、テーマやプラグインのインストール、カスタマイズ…と同じ作業を延々と繰り返す。そしてWordPressやプラグインの更新があると、サイトの数だけアップデートしないといけない。
賛否両論のマルチサイト機能
こういう悩みを解決するために、WordPressには「マルチサイト（サイトネットワーク）」という機能がそなわっている。1つのディレクトリにインストールしたWordPressからサブドメイン・サブディレクトリの複数サイトを制御する方法だ。
一見便利そうだが、かえって管理が煩雑になるとか、処理が遅くなるという噂も聞く。何かトラブルがあったときに、関連サイトが全滅するのも大きなリスクだ。
しばらく導入をためらっていたが、実験的にブログをひとつマルチサイト化して、サブディレクトリに他の小ブログを突っ込んでみた。移行作業は思った以上に簡単に終わり、期待通りテーマやプラグインを共通利用できて便利になった。
大量のミニサイトやアフィリエイトサイト運営には、おおいに役立つと思うマルチサイト機能。現在最新のWordPress5.0と、ConoHa WINGのレンタルサーバー環境で成功した事例を紹介しようと思う。今回はサブドメインでなく、サブディレクトリ型の方を選んだ。
マルチサイトの導入手順
既存のWordPressをマルチサイトに変える方法は、ほかのチュートリアルが充実しているので調べてもらえればと思う。一応、公式マニュアルの日本語訳がここにあるが、たいしたことは書かれていない。対象バージョンがWordPress3.0～と古そうだが、おおまかな流れは5.0でも変わらなかった。
概要だけ整理すると、
- wp-config.phpに
define(‘WP_ALLOW_MULTISITE’, true);
を1行追加。 - 管理画面＞ツール＞ネットワークの設置でサブドメインかサブディレクトリを選択（一度設定すると、やり直せない）。同時にサイトネットワーク名も設定。
- 表示されたコードをwp-config.phpと.htaccessに書き込む。前者は上記の1行のあとにでも追記すればOKだが、.htaccessの方は内容を完全に書き換える。
- 管理画面の上位メニューに「サイトネットワーク管理」が出現。ここから任意の子サイトを新規作成。
ConoHa WINGのサーバーでは、マニュアルどおりやれば特に不具合は出なかった。一か所だけ手間取ったのが、子サイトのトップページがForbidden表示されてしまった点。どうやら子サイトのサブディレクトリを自分で作っていたのが原因で、これを削除したら直った。
子サイトの表示内容はWordPress側で動的生成されるようなので、特にフォルダやファイルを用意する必要はない。上記の流れでwp-config.phpと.htaccessだけ編集・更新すれば、それ以外はFTPソフトで何か作業する必要はない。
管理画面の変化
ワードプレスのマルチサイト化に成功すると、管理画面のダッシュボードが変化する。「サイトネットワーク管理」という上位の階層が加わり、ここから新規サイトを追加したり、全体に適用するテーマやプラグインの編集もできる。
子サイトのディレクトリ名はあとから変更できるが、変更後のURLに自動で転送は行われないようだ。もし気が変わってサイトの構成を変えたら、記事ごとに別途301リダイレクトを設定する必要があるだろう。
サイトごとの個別設定ではタイトル変更やユーザー追加だけでなく、Siteurl、Home、Blogname、Blogdescritionといったwp_optionsのテーブル内容を編集できる。各サイトの管理ページやphpMyAdminからも設定できるが、上位の管理画面から一括でいじれるのが便利だ。
テーマ内のCSSやPHPファイルは、「基本のサイト」で設定した内容が各サイト共通に反映される。一方、サイトごとにテーマを変えることは可能なので、個別にCSSを設定してデザインを調整することは可能だろう。今のところ全サイト同じ見た目で構わないと思っているので、細かいところは特にいじっていない。
一元管理できる部分
サブディレクトリに複数のWordPressを個別インストールする場合に比べて、子サイトに1個ずつテーマやプラグインを入れなくて済むのが便利だ。テーマが共通なら、スタイルシートをはじめとして、functions.phpやheader-insert.php、プラグイン設定用のamazonjs.jsのようなファイルまで親サイトから一元管理できるのがうれしい。
WordPress5.0でなじめなかった新エディターのGutenbergをClassic Editorのプラグインで置き換えたら、各サイトに自動的に適用されるようになった。プラグイン一覧の下に「サイトネットワークで有効」と表示され、逆に子サイトからはON/OFF制御できない。
こういう管理画面系のプラグインは、サイトネットワークで設定すると全サイトに一律適用されるようだ。その他のプラグインは、新サイト追加時にすべてオフになっている。例えばAmazonJSのプラグインで、サイトごとに別のアソシエイトタグを設定したりすることも可能だ。
DBは共通だがテーブルは別管理
マルチサイトにするとデータベースの中がごちゃまぜになるのではと危惧していたが、サイトごとにテーブルが分けて管理されるようだ。例えば親サイトがwp_○○というテーブル名なら、wp_2_○○、wp_3_○○…という風に、子サイトを追加するたびテーブル名の数字がインクリメントされていく。
そのため、あとから子サイトをエクスポートして別のWordPressで管理したいと思っても融通がきく。当該サイトのテーブルだけ書き出せば、どうにでもできるだろう。
さいわい、WordPress間の記事移行でよく使うDeMomentSomTres Exportというプラグインがマルチサイトに対応していた。これを使って画像も含めて記事をエクスポートすれば、DBをいじらなくても中身を書き出せる。
同様に、このプラグインを使って他のWordPressサイトから既存記事をインポートしたら、まったく問題なく処理できた。記事のインポート/エクスポートに関しては、今のところマルチサイト化してもトラブルは出ていない。将来的に気が変わってマルチサイトをやめたくなっても、保険がきくといえる。
アップロードした画像の保存先
DeMomentSomTres Exportプラグインで他ブログの記事をインポートすると、画像は以下のようなパスで保存される。
○○/wp-content/uploads/sites/2/2018/12/○○
子サイトが増えていくと、sites/番号/の部分が繰り上がっていく。サイトごとに画像も個別管理されるので、バックアップやエクスポートにも便利。DB内のテーブルと同じく、画像も各サイトごちゃまぜになる心配はなかった。
子サイト側で、できなくなること
各サイトの管理画面では、プラグインの新規インストールと、テーマの編集ができなくなる。それ以外は従来のスタンドアローン運用とまったく同じ。プラグインはサイトごとに有効化/停止できて、記事・カテゴリーやウィジェット設定は独立して行うことができる。
新規プラグインの導入など、ネットワーク全体に関わる作業は上位の管理画面から行うことになる。マルチサイトでは子サイトごとにユーザーや管理者を分けて運用するシーンが想定されているようで、ユーザーごとの権限設定も柔軟に行える。
すべて一人で運用するなら、親サイトのユーザーを子サイトにも割り当てればいいだろう。マルチサイト化すると「特権管理者」という名称に変わり、一度ログインすればすべてのサイトの管理画面に入れる。
速度低下は気にならない程度
今のところマルチサイト化に期待したとおりの挙動で満足している。DBの共通化にともなう速度低下も、体感的にはまったく気にならない。子サイトを動的生成するオーバーヘッドは、ConoHa WINGの処理速度に比べればたいしたことなさそうだ。
各サイトを別デザインにしたくなったら工夫が必要だが、この機能の趣旨からすれば柔軟に対応可能だろう。テーマやプラグインといったインフラ的なパーツを複数サイトで共有し、見た目に関わるパラメーターやウィジェットは個別に設定できる。この利便性と自由度のバランスがちょうどいいと思った。
似たような仕様で複数のWordPressサイトを運用している人は、マルチサイトの導入を検討してもいいと思う。最近はやりのテーマ特化型ミニサイトや、数ページ程度のアフィリエイトサイトを量産するには、うってつけの便利機能だ。