【第4回】ファイル権限と日本語設定を整えてWordPress開発環境を仕上げる

画像をアップロードできなかった原因

WordPressでは、管理画面からアップロードした画像などを、通常はwp-content/uploadsへ保存します。

さらに、設定によっては、その下に年と月のディレクトリを自動的に作成します。

wp-content/uploads/2026/07

前回の確認では、親となるuploadsディレクトリにはApacheが書き込める権限が設定されていました。

しかし、WordPressが新しく作成した2026と07には、グループの書き込み権限がありませんでした。

親ディレクトリに書き込み権限があっても、新しく作成される子ディレクトリへ、同じ権限がそのまま引き継がれるとは限りません。

今回は、WordPressがディレクトリを作成した際に適用される初期権限によって、グループの書き込み権限が外れていました。

Linuxの所有者とグループを確認する

Linuxのファイルやディレクトリには、主に次の三つの区分があります。

所有者

そのファイルやディレクトリを所有するユーザーです。今回は、開発作業を行うstudio317を所有者とします。

グループ

複数のユーザーやサービスへ共通の権限を与えるための単位です。Apacheが所属するwww-dataを利用します。

その他

所有者にもグループにも該当しないユーザーです。開発サイトのファイルへ不要なアクセス権限は与えません。

今回の開発環境では、Visual Studio CodeやCodexからファイルを変更するのはstudio317です。

一方、ブラウザから実行されたWordPressは、ApacheやPHPの実行ユーザーであるwww-dataとしてファイルへアクセスします。

そのため、WordPressが実行中に保存するディレクトリについては、studio317とwww-dataの両方が利用できるようにする必要があります。

uploadsの所有者と権限を整える

まず、uploads以下の所有者とグループを統一しました。

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

sudo chown -R studio317:www-data wp-content/uploads

続いて、既存のディレクトリには、所有者とグループが読み取り、書き込み、移動できる権限を設定します。

sudo find wp-content/uploads \
-type d \
-exec chmod 2770 {} \;

既存のファイルについては、所有者とグループが読み書きできるようにしました。

sudo find wp-content/uploads \
-type f \
-exec chmod 0660 {} \;

ディレクトリに設定した2770の先頭にある2は、setgidと呼ばれる設定です。

setgidを設定したディレクトリ内では、新しく作成されたファイルやディレクトリが、親ディレクトリのグループを引き継ぎやすくなります。

ただし、setgidだけでは、新しいディレクトリへグループの書き込み権限まで必ず引き継がれるわけではありません。

デフォルトACLで新しいディレクトリの権限を決める

年月別ディレクトリが作成されるたびに手作業で権限を変更するのは、実用的ではありません。

そこで今回は、ACLという仕組みを利用して、uploads内に新しく作成されるファイルとディレクトリの初期権限を設定しました。

ACLは、通常の所有者、グループ、その他という区分に加えて、特定のユーザーやグループへ、より細かな権限を設定する仕組みです。

最初に、既存のuploads以下へ、開発ユーザーとApacheの権限を設定します。

sudo setfacl -R \
-m u:studio317:rwx \
-m g:www-data:rwx \
wp-content/uploads

続いて、既存の各ディレクトリへデフォルトACLを設定します。

sudo find wp-content/uploads \
-type d \
-exec setfacl \
-m d:u::rwx \
-m d:u:studio317:rwx \
-m d:g::rwx \
-m d:g:www-data:rwx \
-m d:o::--- \
{} \;

これにより、WordPressが新しい年や月のディレクトリを作成した場合も、studio317とwww-dataが利用できる権限を引き継ぎます。

設定したACLを確認する

権限を変更した後は、設定内容を確認します。

getfacl wp-content/uploads

確認結果には、通常の権限に加えて、デフォルトACLが表示されます。

user::rwx
user:studio317:rwx
group::rwx
group:www-data:rwx
mask::rwx
other::---

default:user::rwx
default:user:studio317:rwx
default:group::rwx
default:group:www-data:rwx
default:mask::rwx
default:other::---

default:から始まる行が、新しく作成されるファイルやディレクトリへ引き継がれる設定です。

Apacheの実行ユーザーが書き込めることも、コマンドから確認しました。

sudo -u www-data \
test -w wp-content/uploads \
&& echo "Apache can write"

Apache can writeと表示されれば、www-dataから書き込み可能です。

画像アップロードを再確認する

権限を整えた後、WordPressの管理画面から、前回エラーになった画像のアップロードを再度行いました。

今回はエラーが発生せず、画像が年月別ディレクトリへ正常に保存されました。

メディアライブラリにも画像が表示され、WordPressから画像を参照できることを確認しました。

さらに、新しく作成されたディレクトリの所有者、グループ、ACLも確認します。

ls -ld wp-content/uploads/2026
ls -ld wp-content/uploads/2026/07
getfacl wp-content/uploads/2026/07

新しいディレクトリへwww-dataの書き込み権限が引き継がれており、今回の問題を解消できました。

トップページや管理画面が表示されるだけでは、ファイル保存を伴う機能まで正常に動作するとは限りません。

WordPressの開発環境を構築した際は、画像のアップロードも基本的な動作確認に含める必要があります。

Apacheが書き込む場所を限定する

画像のアップロードを可能にするため、wp-content全体をApacheから書き込み可能にする方法もあります。

しかし、テーマやプラグインのソースコードまでWebサーバーから自由に変更できる状態にすると、どの操作によってファイルが変わったのか把握しにくくなります。

そこで、WordPressの各ディレクトリを用途ごとに分けて考えることにしました。

テーマやプラグインは、開発対象となるソースコードです。

管理画面から直接編集や更新を行うのではなく、Visual Studio CodeやCodexで変更し、Gitで履歴を管理する方針としました。

一方、uploadsはWordPressが実行中にデータを保存する場所なので、Apacheの書き込みを許可します。

実行中に変更されるデータと、開発者が管理するソースコードを分離することで、変更内容を追跡しやすくなります。

WordPress管理画面を日本語化する

ファイル権限を整理した後、WordPressの日本語言語パックを導入しました。

今回は、WP-CLIを利用して日本語をインストールし、そのまま有効化します。

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

wp language core install ja --activate

導入状態は、次のコマンドで確認できます。

wp language core list

日本語を示すjaがインストール済みで、有効になっていることを確認しました。

ブラウザで管理画面を再読み込みすると、メニューや各種設定画面が日本語で表示されます。

言語パックの導入にはwp-content/languagesへの書き込みが必要ですが、今回はApacheからではなく、開発ユーザーが実行するWP-CLIで管理します。

このため、言語パックを導入する目的だけで、管理画面からlanguagesへ常時書き込めるようにする必要はありません。

タイムゾーンを東京へ設定する

WordPressの日時は、投稿の公開日時、予約投稿、ログ、定期処理など、さまざまな機能で使用されます。

初期状態のままでは、協定世界時を基準とした設定になっている場合があります。

今回の開発環境では、日本国内での利用を前提として、タイムゾーンをAsia/Tokyoに設定しました。

wp option update timezone_string 'Asia/Tokyo'

単純にUTCからの時差を指定するのではなく、地域名でタイムゾーンを設定します。

設定後、WordPressが認識しているタイムゾーンを確認しました。

wp option get timezone_string

Asia/Tokyoと表示されれば、設定が反映されています。

日付と時刻の表示形式を設定する

続いて、管理画面やテーマで使用される日付と時刻の表示形式を設定しました。

wp option update date_format 'Y年n月j日'
wp option update time_format 'H:i'
wp option update start_of_week 1

今回の設定では、日付は「2026年7月18日」、時刻は「14:30」のように表示されます。

start_of_weekには1を設定し、週の始まりを月曜日としました。

設定後は、各項目をWP-CLIから確認しました。

wp option get timezone_string
wp option get date_format
wp option get time_format
wp option get start_of_week

管理画面の「設定」から変更することもできますが、WP-CLIを利用すると、設定値を正確に確認しながら作業できます。

コマンドと管理画面の両方で確認する

WP-CLIで設定が正常に更新された場合でも、最後はブラウザから管理画面を確認します。

今回は、次の項目を確認しました。

• 管理画面のメニューや説明が日本語で表示されること
• サイトのタイムゾーンが東京になっていること
• 日付と時刻が設定した形式で表示されること
• メディアライブラリへ画像をアップロードできること
• アップロードした画像がブラウザから表示されること
• トップページと投稿ページが引き続き正常に表示されること

コマンドの実行結果だけでなく、実際に利用する画面でも確認することで、設定漏れや想定との違いを発見しやすくなります。

Visual Studio CodeとCodexの編集範囲

今回の権限整理により、WordPress開発環境の中で、誰がどのファイルを変更するのかが明確になりました。

Visual Studio CodeとCodexは、Ubuntuへログインしているstudio317の権限で動作します。

そのため、開発対象となるテーマやプラグインはstudio317が所有し、Visual Studio Code、Codex、Gitから変更します。

Apacheは、それらのファイルを読み取って実行できますが、原則として書き換えることはできません。

ChatGPT

作業方針、権限設計、確認手順、問題発生時の原因を整理します。

Codex

プロジェクト内のファイルを調査し、コードや設定ファイルを編集します。

Visual Studio Code

人間がコードとCodexの変更内容を確認し、必要に応じて修正します。

Git

テーマやプラグインの変更履歴を記録し、差分を確認できるようにします。

ApacheとWordPress

ソースコードを実行し、アップロードファイルなど、実行時に必要なデータだけを保存します。

すべてのソフトウェアへ同じ権限を与えるのではなく、それぞれの役割に必要な範囲だけを許可します。

今回の到達点

今回は、WordPressが年月別のアップロードディレクトリへ画像を保存できなかった原因を確認し、所有者、グループ、setgid、ACLを利用して権限を整えました。

これにより、新しい年や月のディレクトリが作成された場合も、Apacheが画像を保存できるようになりました。

また、WordPressの管理画面を日本語化し、タイムゾーン、日付形式、時刻形式、週の始まりを日本で利用しやすい内容に設定しました。

テーマやプラグインはVisual Studio Code、Codex、Gitで管理し、Apacheからは原則として書き込めない方針も決めました。

WordPressが実行中に変更するデータと、開発者が管理するソースコードを分けたことで、ローカル開発サイトを安全に運用するための基本構成が整いました。