【第3回】MariaDBとWordPressでローカル開発サイトを作る

今回構築するWordPress開発環境

今回の目標は、Ubuntu上に本番環境とは独立したWordPressサイトを作り、テーマやプラグインの開発に利用できる状態にすることです。

開発サイトは、次の構成で作成します。

wordpress-dev.testは、インターネット上へ公開するドメインではありません。

このUbuntuの中だけで利用する開発用の名前として設定します。

MariaDBを導入する

WordPressは、投稿、固定ページ、ユーザー、設定などの情報をデータベースへ保存します。

今回は、WordPressで広く利用されているMySQL互換のデータベースとして、MariaDBを導入しました。

導入後は、バージョンとサービスの状態を確認します。

mariadb --version
systemctl status mariadb

今回導入されたMariaDBは11.8.6で、Ubuntuの起動時に自動的に開始されるサービスとして設定されました。

さらに、MariaDBがどのネットワークで接続を受け付けているかも確認しました。

sudo ss -lntp | grep ':3306'

確認したところ、MariaDBは127.0.0.1:3306で待ち受けていました。

127.0.0.1は、そのUbuntu自身からの接続だけを受け付ける設定です。

今回のWordPressとMariaDBは同じUbuntu上で動作するため、データベースを外部のパソコンへ公開する必要はありません。

WordPress用のデータベースを作成する

MariaDB本体を導入しただけでは、WordPressが利用するデータベースはまだ存在しません。

そこで、WordPress専用のデータベースと接続用ユーザーを作成しました。

sudo mariadb

MariaDBへ接続した後、次のようなSQLを実行します。

CREATE DATABASE wordpress_dev
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

CREATE USER 'wordpress_dev'@'localhost'
IDENTIFIED BY '安全なパスワード';

GRANT ALL PRIVILEGES
ON wordpress_dev.*
TO 'wordpress_dev'@'localhost';

FLUSH PRIVILEGES;

実際に設定したパスワードは、blogやGitリポジトリには記録しません。

データベース名とユーザー名は、用途が分かりやすいように、どちらもwordpress_devとしました。

WordPress専用のユーザーを作成し、必要なデータベースだけに権限を与えることで、他のデータベースへ影響する範囲を限定できます。

開発ファイルの保存場所を作る

WordPressのファイルは、Apacheが標準で利用するディレクトリへ直接置くのではなく、今後複数の開発プロジェクトを管理できる構成にしました。

開発用の基準ディレクトリは、次の場所です。

/var/www/studio317

その中に、今回のWordPress開発プロジェクトを作成します。

/var/www/studio317/wordpress-dev
/var/www/studio317/wordpress-dev/public

wordpress-devはプロジェクト全体のディレクトリで、publicをブラウザから公開されるドキュメントルートとします。

将来、設定ファイル、開発用ツール、ドキュメントなどを追加する場合も、ブラウザから公開する必要がないファイルをpublicの外へ置けます。

ディレクトリの所有者はUbuntuへログインしている開発ユーザーとし、グループにはApacheが利用するwww-dataを設定しました。

sudo chown -R studio317:www-data /var/www/studio317
sudo chmod 2750 /var/www/studio317
sudo chmod 2750 /var/www/studio317/wordpress-dev
sudo chmod 2750 /var/www/studio317/wordpress-dev/public

先頭の2はsetgidと呼ばれる設定です。

このディレクトリ内で新しく作成したファイルやディレクトリへ、親ディレクトリのグループを引き継ぎやすくするために設定しています。

ApacheのVirtualHostを作成する

Apacheの初期状態では、通常は/var/www/htmlがドキュメントルートとして使用されます。

今回はwordpress-dev.testへアクセスしたときに、先ほど作成したpublicディレクトリを表示するようにVirtualHostを設定しました。

VirtualHostは、一台のWebサーバーで複数のWebサイトを扱うための仕組みです。

Apacheの設定ファイルとして、次のファイルを作成します。

/etc/apache2/sites-available/wordpress-dev.conf

基本となる設定内容は次のようになります。

<VirtualHost *:80>
ServerName wordpress-dev.test
DocumentRoot /var/www/studio317/wordpress-dev/public


AllowOverride All
Require all granted

ServerNameには開発サイトのURLを、DocumentRootにはWordPressを配置するディレクトリを設定します。

AllowOverride Allは、WordPressが使用する.htaccessの設定をApacheへ反映できるようにするための指定です。

設定ファイルを作成した後、VirtualHostとApacheのrewrite機能を有効にします。

sudo a2ensite wordpress-dev.conf
sudo a2enmod rewrite
sudo systemctl reload apache2

設定を反映する前には、Apacheの構文に問題がないことも確認しました。

sudo apache2ctl configtest

結果がSyntax OKであることを確認してから、Apacheを再読み込みします。

開発用URLをUbuntuへ登録する

wordpress-dev.testはインターネット上のDNSへ登録されていないため、そのままではアクセス先が分かりません。

そこで、Ubuntuの/etc/hostsへ開発用URLを登録しました。

127.0.0.1 wordpress-dev.test

この設定により、Ubuntu上でwordpress-dev.testへアクセスすると、自分自身を表す127.0.0.1へ接続されます。

設定後、まずは簡単なPHPファイルを配置し、ブラウザから表示できることを確認しました。

この時点で、Apache、PHP、VirtualHost、ファイルの読み取り権限が正しく連携していることを確認できます。

WP-CLIを導入する

WordPressは、ブラウザからインストールすることもできます。

今回は、WordPressをコマンドラインから管理できるWP-CLIを利用しました。

WP-CLIでは、WordPress本体のダウンロード、設定ファイルの作成、データベースへのインストール、プラグインやテーマの管理などをコマンドで実行できます。

導入後は、次のコマンドでバージョンを確認しました。

wp --version

今回導入されたWP-CLIは2.12.0でした。

WP-CLIは作業ディレクトリによって操作対象が変わるため、コマンドを実行する前に、現在の場所を確認することが重要です。

pwd

今回は、WordPressを配置する次のディレクトリへ移動して作業しました。

cd /var/www/studio317/wordpress-dev/public

WordPressをインストールする

WP-CLIを利用して、最初にWordPress本体をダウンロードしました。

wp core download

続いて、先ほど作成したデータベースへ接続するためのwp-config.phpを作成します。

wp config create \
--dbname=wordpress_dev \
--dbuser=wordpress_dev \
--dbpass='安全なパスワード' \
--dbhost=localhost

パスワードを含む実際のコマンドは、blogや共有用の作業記録にはそのまま掲載しません。

最後に、サイトURL、サイト名、管理ユーザーなどを指定してWordPressをインストールします。

wp core install \
--url='http://wordpress-dev.test' \
--title='WordPress Development' \
--admin_user='管理ユーザー名' \
--admin_password='安全なパスワード' \
--admin_email='管理用メールアドレス' \
--skip-email

インストール後、WordPressのバージョンとサイトURLを確認しました。

wp core version
wp option get siteurl
wp option get home

WordPress 7.0.1がインストールされ、サイトURLとホームURLの両方がhttp://wordpress-dev.testになっていることを確認しました。

パーマリンクを設定する

WordPressの初期状態では、投稿URLに番号を使用する基本形式が設定されています。

実際のWebサイトに近い状態で開発できるように、投稿名を使用するパーマリンクへ変更しました。

wp rewrite structure '/%postname%/'
wp rewrite flush --hard

この設定では、Apacheのrewrite機能と.htaccessが正常に動作している必要があります。

確認のため、一時的な投稿を作成し、投稿名を使用したURLへアクセスしました。

その結果、対象のページが正常に表示され、HTTPステータスコード200が返ることを確認できました。

トップページが表示されるだけでなく、WordPressのパーマリンクまで動作しているため、ApacheとWordPressの連携が正しく設定されています。

管理画面と基本設定を確認する

ブラウザから次のURLへアクセスし、WordPressの管理画面へログインできることを確認しました。

http://wordpress-dev.test/wp-admin/

また、WP-CLIから現在のWordPress設定を確認しました。

wp option get blogname
wp option get permalink_structure
wp language core list
wp user list

サイト名、管理ユーザー、パーマリンクなどが、予定した内容になっていることを確認しました。

WordPressのロケールは日本語を示すjaになっていますが、管理画面の日本語化や日時の表示形式などは、今後あらためて調整します。

画像アップロードで権限の問題が見つかる

WordPressの表示と管理画面へのログインが確認できたため、動作確認として画像のアップロードも試しました。

ところが、約176KBのPNG画像をアップロードした際、アップロードされたファイルを保存先へ移動できないというエラーが発生しました。

確認したところ、wp-content/uploadsにはApacheが書き込める権限が設定されていましたが、その下に作成された年月別ディレクトリには、グループの書き込み権限が引き継がれていませんでした。

親ディレクトリへ書き込み権限を設定していても、新しく作成された子ディレクトリへ適切な権限が引き継がれるとは限りません。

WordPressのトップページや管理画面が表示された時点では気づけない問題でした。

実際の開発作業を想定して、画像アップロード、プラグインの操作、パーマリンクなどを試すことで、環境構築上の課題を早い段階で見つけられます。

WordPress本体をどこまで書き込み可能にするか

ローカル開発環境では、すべてのファイルをApacheから書き込み可能にすれば便利に見えることがあります。

しかし、WordPress本体、テーマ、プラグイン、アップロードファイルでは、必要な書き込み権限が異なります。

WordPress本体

通常の表示や実行では、Apacheから読み取ることができれば動作します。

uploadsディレクトリ

管理画面から画像などを保存するため、Apacheの書き込み権限が必要です。

themesとpluginsディレクトリ

管理画面からインストールや更新を行うか、GitやCodexでのみ変更するかによって必要な権限が変わります。

languagesディレクトリ

管理画面から言語パックを導入する場合は、Apacheの書き込み権限が必要になることがあります。

今回は、開発者がVisual Studio CodeやCodexで管理するファイルと、WordPressが実行中に書き込むファイルを分けて考える方針としました。

すべてを無条件に書き込み可能にするのではなく、用途ごとに必要な範囲だけを許可します。

別のパソコンからのアクセスについて

前回は、Ubuntu本体だけでなく、別のパソコンからも開発サイトへアクセスできる状態を目指す予定としていました。

今回は、まずUbuntu内部でWordPressが正常に動作するところまでを優先しました。

wordpress-dev.testはUbuntuの/etc/hostsだけに登録されているため、他のパソコンから同じURLへ直接アクセスすることはできません。

現時点では、WindowsからTailscaleを経由してUbuntuへリモートデスクトップ接続し、Ubuntu上のブラウザで開発サイトを確認できます。

他のパソコンからWordPressへ直接アクセスできるようにするには、名前解決、Apacheの待ち受け範囲、ファイアウォール、Tailscale上のアクセス方法などを整理する必要があります。

不要な範囲へ開発サイトを公開しないよう、安全な接続方法を確認してから設定することにしました。

今回の構成を確認する

今回の作業により、ブラウザからWordPressへアクセスするまでの流れは次のようになりました。

1. ブラウザがwordpress-dev.testへアクセスする

   /etc/hostsの設定により、Ubuntu自身の127.0.0.1へ接続します。

2. Apacheがアクセスを受け付ける

   VirtualHostの設定により、/var/www/studio317/wordpress-dev/publicを参照します。

3. WordPressがPHPで実行される

   アクセスされたURLをもとに、WordPressが必要な処理を行います。

4. WordPressがMariaDBへ接続する

   wp-config.phpの設定を使用し、ローカルのMariaDBから投稿や設定を取得します。

5. 生成されたページがブラウザへ返される

   Apacheを通して、WordPressの実行結果がブラウザへ表示されます。

Webサーバー、PHP、データベース、WordPressは、それぞれ別の役割を持っています。

一つずつ動作を確認することで、問題が発生した際に、どの部分を調べればよいか判断しやすくなります。

今回の到達点

今回は、MariaDBへWordPress専用のデータベースとユーザーを作成し、ApacheのVirtualHostと開発用URLを設定しました。

WP-CLIを利用してWordPress 7.0.1をインストールし、管理画面へのログインとパーマリンクの動作も確認できました。

これにより、Ubuntu上でWordPressプラグインやテーマの開発を始めるための基本的なローカルサイトが完成しました。

一方で、画像アップロードの確認から、年月別ディレクトリへ書き込み権限が適切に引き継がれていないことも分かりました。

環境構築では、画面が表示されたことだけで完了とせず、実際に利用する操作まで確認することが重要です。