WordPressの構成を設計する｜Composer管理にすると得られる7つのこと

WordPressをサーバーの「簡単インストール」で入れている方は多いと思います。

数クリックで終わりますし、実際にそれで十分な案件もあります。

ただ、WordPressにはComposerで本体やプラグインなどの依存関係を管理する構成もあります。

いわゆるBedrockのような構成です。

この記事では、WordPressをComposerで管理すると何が変わるのかを、実際の運用を想定して整理します。

先に結論を書くと、Composer構成のメリットは「WordPressに新しい機能が増えること」ではありません。

構成を把握しやすくなり、同じ環境を再現でき、更新や移転に強くなること。

ここが本質です。

なお、サーバーの簡単インストールが悪いという話ではありません。

誰が、どのように、何年間運用するのか。

そこによって、向いている構成が変わります。

ComposerでWordPressを管理するとは？

Composerは、PHPで利用するライブラリやパッケージを管理するための仕組みです。

「何を使うのか」「どのバージョンを使うのか」を設定ファイルに記録し、コマンドで必要なものを揃えられます。

WordPressもComposerを使って管理できます。

代表的な方法の一つが、WordPress本体を公開ディレクトリの外側で管理し、公開領域を分離する構成です。

簡単インストールでは、一般的に次のような構成になります。

【一般的なWordPress構成】
public_html/
  wp-admin/
  wp-includes/
  wp-content/
  wp-config.php

Composerを使った構成では、例えば次のように分離できます。

【Composerを使った構成の例】
project/
  composer.json
  composer.lock
  .env
  vendor/
  web/
    wp/
    app/

この例では、Webサーバーが公開するのは web/ 以下だけです。

Composerの設定ファイルや依存パッケージ、環境設定などを公開領域から分離できます。

ただし、これはComposer単体が自動的に作ってくれる構成ではありません。

Bedrockなどの構成設計を利用したり、自分で公開領域を分離したりする必要があります。

使っているものとバージョンを管理しやすい

Composer構成の大きなメリットが、依存関係をファイルとして管理できることです。

composer.json には、WordPress本体やプラグイン、テーマなど、Composerで管理するパッケージの依存関係を記述します。

例えば、

「このプラグインを使っている」
「このバージョン以上が必要」
「このパッケージと組み合わせている」

といった情報をコードとして残せます。

これは引き継ぎのときに非常に便利です。

管理画面を開いて一つずつ確認しなくても、リポジトリや設定ファイルを見れば構成を把握できます。

さらに、Composerで管理しているパッケージについては、環境によっては composer audit を使って既知のセキュリティアドバイザリを確認できます。

もちろん、これですべてのWordPressの脆弱性が自動的に発見できるわけではありません。

それでも、依存関係をコードとして管理できること自体が大きな意味を持ちます。

同じ構成を別のサーバーで再現できる

Composerには、特に重要な2つのファイルがあります。

この2つを使うことで、別の環境でも同じ依存関係を再現できます。

composer install は、基本的に composer.lock に記録された内容を使って環境を構築します。

一方、

composer update

は、設定された条件の範囲で依存関係を更新し、lockファイルも更新します。

この2つを区別することが重要です。

本番環境を毎回その場で更新するのではなく、検証環境で更新・確認したものをlockファイルで固定し、本番ではその状態を再現する。

こうした運用がしやすくなります。

公開領域と設定ファイルを分離できる

Composer構成では、WordPressの公開領域をプロジェクト全体から分離できます。

例えば、

/project/ の中に設定ファイルやComposer関連ファイルを置き、 /project/web/ だけをWebサーバーのドキュメントルートにする構成です。

これにより、Webから直接アクセスする必要のないファイルを公開領域の外に置けます。

例えば環境変数を使う場合は、データベース接続情報などを .env に分離できます。

ただし、.env を使うこと自体はComposerの機能ではありません。

あくまで、公開領域とアプリケーションの設定を分離する設計の一部です。

セキュリティは「1つの対策ですべて守る」のではなく、公開しなくてよいものを最初から公開しない、という設計が重要です。

WordPressの管理画面とコード管理を分離できる

ここが、私がComposer構成を採用する大きな理由の一つです。

WordPressは管理画面からプラグインを追加できるのが便利です。

しかし、裏を返せば、WebサーバーからWordPressのコード領域を書き換えられる構成になっている場合があります。

もし管理者アカウントを不正利用された場合、管理画面からプラグインを追加するなど、コード変更につながる操作を許してしまう可能性があります。

Composerを中心とした運用では、コードの追加・更新をSSHやデプロイ環境など、別の経路に限定する設計ができます。

つまり、

「記事を更新できる人」と「コードを変更できる人」を分ける。

という考え方です。

これはWordPressに限った話ではありません。

Webアプリケーションを長期運用するなら、権限を分離することには大きな意味があります。

更新手順を固定できる

Composer構成では、更新作業をコマンドとして定型化できます。

例えば検証環境で依存関係を更新し、動作確認を行ったあと、その状態をlockファイルに固定します。

本番環境では、そのlockファイルを使って同じ状態を再現します。

この流れを手順書にできます。

「管理画面を開いて、プラグインAを更新して、次にプラグインBを更新して……」

という属人的な作業から、

「この手順を実行する」

という作業に変えられます。

複数サイトを運用する場合、この差はさらに大きくなります。

サイトごとの構成を独立させたまま、同じルールで更新できます。

サーバー移転と検証環境を作りやすい

サーバーを移転するとき、WordPress一式を丸ごとコピーするだけの構成では、「これはWordPress本体なのか」「自分で追加したものなのか」が分かりにくくなることがあります。

Composer構成なら、コードの構成を定義ファイルから再構築できます。

もちろん、データベースやアップロードした画像などは別途移行が必要です。

それでも、

「環境をコピーする」のではなく「環境を再構築する」

という考え方に変えられます。

検証環境も同じです。

本番と同じ composer.lock を使えば、コード側の依存関係を揃えやすくなります。

「検証環境だけ違う」という問題を減らせるわけです。

WordPress以外のシステムとも組み合わせやすい

実際のWebサイトでは、すべてをWordPressで作る必要がない場合があります。

例えば、

/ は静的ページ
/blog/ はWordPress
/service/ は別のWebアプリケーション

といった構成です。

最初から公開領域とアプリケーションを分離しておけば、こうした構成変更にも対応しやすくなります。

Webサイトは公開した瞬間が完成ではありません。

3年後、5年後に何を追加するか分からないのであれば、最初から変更できる余地を残しておくことには価値があります。

ただし、Composer構成にも代償がある

ここは重要です。

Composer構成は、すべてのWordPressサイトに適しているわけではありません。

SSHやコマンド操作が必要になる。

利用するサーバーによっては、必要な環境を用意できない場合があります。

管理画面から自由にプラグインを追加する運用とは相性が悪い。

Composerでコードを管理する方針なら、プラグイン追加もComposer側で管理する必要があります。

顧客が自由に変更できなくなる。

「新しいプラグインを入れたい」という要望が出た場合、制作・保守側の作業が必要になることがあります。

構築する側にも知識が必要。

WordPressだけでなく、Composer、PHP、サーバー、権限、デプロイなどを理解する必要があります。

つまり、簡単インストールより「難しい」のです。

その代わり、長期運用では得られるものがあります。

実際にComposerで構築した記録は、エックスサーバーにDrupal 11をインストールする手順｜SSH＋Composerで構築にあります。Drupalの例ですが、Composerの扱い方は共通です。

Composer構成が向いているサイト、向いていないサイト

特に重要なのは、最後の項目です。

顧客が「自分で好きなプラグインを入れたい」という案件にComposer構成を押し込むと、便利だったWordPressをわざわざ不便にしてしまいます。

技術的に高度な構成が、必ずしも良い構成とは限りません。

何を誰が更新するのかを先に決めてから、構成を選ぶべきです。

そもそもWordPressを使い続けるかどうかで迷っている場合は、WordPressをやめるべきか？｜他のCMS・静的サイトへの移行を迷ったときの判断基準も参考になります。

「簡単インストール」と「Composer」の違いは、初期構築より運用で出る

簡単インストールの最大のメリットは、最初が簡単なことです。

数分でWordPressを立ち上げられます。

一方、Composer構成のメリットは、最初よりも後から効いてきます。

つまり、10分の初期構築を短縮することより、数年後の運用コストを下げることを優先する構成です。

公開後に実際どれくらいの費用がかかるかは、ホームページは公開してからいくらかかる？｜5年間の維持費・保守費とCMS選びで試算しています。

まとめ

WordPressをComposerで管理する最大のメリットは、WordPressそのものが高機能になることではありません。

構成を把握できる。
同じ環境を再現できる。
更新手順を固定できる。
将来の変更に対応しやすい。

この4つです。

一方で、SSHやComposerなどの知識が必要になり、顧客が管理画面から自由にプラグインを追加する運用とは相性がよくありません。

だからこそ、

「Composerで作る方が上」ではなく、「そのサイトの運用にComposerが必要か？」

という順番で考えるべきだと思っています。

弊社ではブログをDrupalのComposer構成で運用しています。

WordPressについても、案件の運用方法や将来的な拡張を考えたうえで、通常の構成とComposer構成を使い分けています。

WordPressの構築を依頼するときは、「WordPressを入れてください」だけではなく、

「このサイトを誰が、何を、どのくらいの期間更新するのか」

まで伝えることをおすすめします。

そこが決まれば、必要な構成も変わります。

WordPressの構成やサーバー環境について、どの構成が自社サイトに合うのか分からない場合はご相談ください。

必ずしもComposer構成を勧めるわけではありません。

必要のないものまで導入しないことも、Webサイトの設計です。