【第8回】シンボリックリンクでGitリポジトリとWordPressを接続する

ソースコードの正本を一つにする

今回のGitリポジトリは、次の場所へ保存されています。

/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

WordPressがプラグインを読み込むディレクトリは、次の場所です。

/var/www/studio317/wordpress-dev/public/wp-content/plugins

単純な方法として、Gitリポジトリの内容をpluginsへコピーすることもできます。

しかし、コピーした場合は、同じソースコードが二か所に存在することになります。

そこで、プロジェクト用ストレージにあるGitリポジトリをソースコードの正本とし、WordPressから同じファイルを参照する構成にします。

シンボリックリンクとは

シンボリックリンクは、別の場所にあるファイルやディレクトリを参照するための仕組みです。

Windowsのショートカットに似ていますが、Linuxでは多くのコマンドやアプリケーションから、リンク先のファイルを通常のファイルと同じように扱えます。

今回の構成では、WordPressのプラグインディレクトリ内にシンボリックリンクを作成し、プロジェクト用ストレージのGitリポジトリを参照させます。

wp-content/plugins/
└── studio317-report-drafts-google-analytics
    └── /mnt/studio317-data/development/projects/
        studio317-report-drafts-google-analytics を参照

Visual Studio CodeやCodexがGitリポジトリを編集すると、WordPressが参照しているファイルにも同じ変更が反映されます。

実際にはファイルを複製しないため、編集対象を一つに保つことができます。

リンクを作る前に既存のディレクトリを確認する

シンボリックリンクを作成する前に、同じ名前のファイルやディレクトリがすでに存在していないことを確認します。

cd /var/www/studio317/wordpress-dev/public/wp-content/plugins

ls -la

今回作成するリンク名は、WordPress.orgのスラッグと同じ次の名称です。

studio317-report-drafts-google-analytics

同じ名前のディレクトリがすでに存在する場合、そのままではシンボリックリンクを作成できません。

以前にZIPファイルなどからプラグインをインストールしていた場合は、内容を確認したうえで、削除するか別の場所へ退避します。

mv \
studio317-report-drafts-google-analytics \
studio317-report-drafts-google-analytics.backup

既存ディレクトリに未保存の変更や必要な設定ファイルが含まれている可能性もあるため、内容を確認せずに削除しないようにします。

シンボリックリンクを作成する

既存の同名ディレクトリがないことを確認した後、lnコマンドでシンボリックリンクを作成します。

ln -s \
/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics \
/var/www/studio317/wordpress-dev/public/wp-content/plugins/studio317-report-drafts-google-analytics

ln -sの最初のパスは、実際のGitリポジトリです。

二つ目のパスは、WordPressのプラグインディレクトリ内に作成するリンクです。

作成後、リンクの状態を確認します。

ls -la \
/var/www/studio317/wordpress-dev/public/wp-content/plugins

正常に作成されていれば、次のようにリンク先が表示されます。

studio317-report-drafts-google-analytics -> \
/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

シンボリックリンク自体は、リンク先のファイルをコピーしているわけではありません。

そのため、リンクを削除しても、プロジェクト用ストレージにあるGitリポジトリは削除されません。

リンク先へ正しく移動できることを確認する

シンボリックリンクを作成した後は、WordPress側のパスからリンク先へ移動できることを確認します。

cd /var/www/studio317/wordpress-dev/public/wp-content/plugins/studio317-report-drafts-google-analytics

pwd
pwd -P

pwdは、現在使用しているシンボリックリンクを含むパスを表示します。

pwd -Pは、シンボリックリンクを解決した実際の保存場所を表示します。

今回の構成では、pwd -Pの結果が次の場所になります。

/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

WordPress側のプラグインディレクトリから移動しても、実際にはプロジェクト用ストレージのGitリポジトリを参照していることが分かります。

Apacheがリンク先を読み取れることを確認する

シンボリックリンクが作成されていても、Apacheがリンク先のディレクトリへ移動できなければ、WordPressからプラグインを読み込めません。

Linuxでは、対象ファイルだけでなく、そのファイルへ到達するまでの各ディレクトリにも適切な権限が必要です。

今回のリンク先は、次の階層にあります。

/mnt
└── studio317-data
    └── development
        └── projects
            └── studio317-report-drafts-google-analytics

Apacheの実行ユーザーであるwww-dataが、リンク先のプラグインファイルを読み取れるか確認しました。

sudo -u www-data \
test -r \
/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics/studio317-report-drafts-google-analytics.php \
&& echo "Apache can read plugin file"

Apache can read plugin fileと表示されれば、Apacheから対象ファイルを読み取ることができます。

ファイルの読み取りだけでなく、途中のディレクトリを通過できることも確認します。

namei -l \
/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

namei -lを利用すると、パスを構成する各ディレクトリの所有者、グループ、権限を順番に確認できます。

マウントしたストレージを利用する際の注意

今回のGitリポジトリは、Ubuntuのシステムディスクではなく、後から追加したデータストレージに保存されています。

そのため、Ubuntuの起動時にストレージが正常にマウントされている必要があります。

ストレージがマウントされていない状態では、シンボリックリンクの参照先が存在しないため、WordPressからプラグインを読み込めません。

現在のマウント状態は、次のコマンドで確認できます。

findmnt /mnt/studio317-data

ファイルシステムの種類や空き容量も確認しました。

df -hT /mnt/studio317-data

開発を始める前に、ストレージが予定した場所へマウントされていることを確認する運用としました。

WordPressがプラグインを認識するか確認する

シンボリックリンクとファイル権限を確認した後、WP-CLIからWordPressのプラグイン一覧を確認します。

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

wp plugin list

一覧に次のスラッグが表示されることを確認しました。

studio317-report-drafts-google-analytics

さらに、対象のプラグインだけを指定して状態を確認します。

wp plugin status studio317-report-drafts-google-analytics

WordPressがプラグインを認識していない場合は、次の項目を確認します。

• シンボリックリンクの参照先が正しいか
• リンク先のストレージがマウントされているか
• プラグインのメインPHPファイルが存在するか
• PHPファイルにWordPressのプラグインヘッダーがあるか
• Apacheがリンク先のファイルを読み取れるか
• プラグインディレクトリ名が意図したものになっているか

有効化する前にPHPの構文を確認する

WordPressがプラグインを認識した後、すぐに有効化するのではなく、最初にPHPの構文を確認しました。

プラグイン内のすべてのPHPファイルを対象にします。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

find . 
-type f 
-name '*.php' 
-print0 
| xargs -0 -n1 php -l

各ファイルについて、構文エラーがないことを示す結果が表示されることを確認します。

この確認では、プラグインの機能が正しいかまでは判断できません。

しかし、PHPの記述ミスによって、プラグインの有効化直後に致命的エラーが発生する可能性を減らせます。

プラグインの動作条件を確認する

今回のプラグインには、動作に必要なWordPressとPHPのバージョンが設定されています。

WordPressとPHPのどちらも、プラグインが必要とするバージョンを満たしています。

また、このプラグインは、AIによる文章生成にWordPress AI Clientを利用します。

AIプロバイダーが設定されていない場合でも、プラグインの有効化や管理画面の基本表示は確認できますが、AIレポートを生成することはできません。

Google Analytics 4のデータを取得するためには、Google Cloudで作成したOAuthクライアント情報と、Googleアカウントへの接続も必要です。

今回は、まずプラグイン本体が新しいUbuntu環境で正常に読み込まれることを確認し、外部サービスへの接続は別の段階で行います。

プラグインを有効化する

PHPの構文と動作条件を確認した後、WP-CLIからプラグインを有効化しました。

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

wp plugin activate studio317-report-drafts-google-analytics

有効化後、プラグインの状態を確認します。

wp plugin status studio317-report-drafts-google-analytics

有効なプラグインとして表示されることを確認しました。

あわせて、WordPress全体でPHPの致命的エラーが発生していないことを、トップページと管理画面から確認します。

• WordPressのトップページを表示できること
• 管理画面へログインできること
• プラグイン一覧を表示できること
• 対象プラグインが有効と表示されること
• 画面が真っ白にならないこと
• PHPの致命的エラーが表示されないこと

管理画面のメニューを確認する

プラグインを有効化すると、WordPressの管理画面に専用メニューが追加されます。

今回のプラグインでは、主に次の画面を使用します。

Report Builder

Google Analytics 4のデータを取得し、AIレポートの下書きを作成する画面です。

Current Status

Google接続、AIプロバイダー、言語、サイトURLなど、現在の設定状態を確認する画面です。

Settings

Google OAuthクライアント情報やGA4のレポート条件などを設定する画面です。

各メニューを開き、画面が正常に表示されることを確認しました。

設定がまだ完了していない項目については、未設定であることを示す案内や状態表示が出ます。

未設定をエラーとして隠すのではなく、現在不足している設定を確認できることも、管理画面の重要な役割です。

外部サービスへ接続しない範囲で確認する

今回の目的は、Ubuntu上でプラグイン開発を開始できる状態を確認することです。

そのため、Google OAuth、GA4 Data API、AIプロバイダーなど、外部サービスへの接続は行いませんでした。

外部サービスを利用しなくても、次の項目は確認できます。

• プラグインを有効化できること
• 管理画面のメニューが追加されること
• 各画面を表示できること
• JavaScriptやCSSが読み込まれること
• 未設定状態の案内が適切に表示されること
• WordPress全体に致命的エラーが発生しないこと
• プラグインを停止して再び有効化できること

OAuthや外部APIの確認は、認証情報、ネットワーク通信、外部サービス側のデータに関係します。

基本画面の確認とは分けて実施することで、問題が発生した際の原因を特定しやすくなります。

Visual Studio Codeから同じファイルを確認する

プラグインがWordPressから認識された後、GitリポジトリをVisual Studio Codeで開きました。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

code .

Visual Studio Codeで編集するファイルと、WordPressが実行しているファイルが同じであることを確認します。

確認のため、Gitリポジトリ内のメインPHPファイルと、WordPress側のシンボリックリンクを経由したファイルを比較できます。

readlink -f \
/var/www/studio317/wordpress-dev/public/wp-content/plugins/studio317-report-drafts-google-analytics

結果がプロジェクト用ストレージのGitリポジトリを示していれば、WordPressはVisual Studio Codeで開いているものと同じソースコードを利用しています。

これにより、Visual Studio CodeやCodexで保存した変更を、ファイルのコピーを行わずにWordPress上で確認できます。

Codexにも現在の構成を確認してもらう

Codexへ実際の修正を依頼する前に、現在のプロジェクトとWordPress環境の関係を確認してもらいました。

このリポジトリは、
/mnt/studio317-data/development/projects/
studio317-report-drafts-google-analytics
にあります。

WordPress側では、
/var/www/studio317/wordpress-dev/public/wp-content/plugins/
studio317-report-drafts-google-analytics
からシンボリックリンクで参照しています。

まずはファイルを変更せず、次の内容を確認してください。

・Gitの現在のブランチと作業ツリー
・WordPress側のリンク先
・プラグインのバージョン
・PHP構文エラーの有無
・変更した場合にWordPressへ直接反映される構成であること

コミット、push、外部API接続、
データベース変更は行わないでください。

Codexが認識しているリポジトリ、WordPressの参照先、作業範囲を確認してから、今後の変更を依頼します。

同じ名前のプラグインが複数の場所にある環境では、AIが異なるコピーを編集する可能性があります。

最初に絶対パスとシンボリックリンクの関係を共有することで、作業対象を明確にできます。

Gitの状態が変化していないことを確認する

プラグインの有効化や管理画面の確認が終わった後、Gitリポジトリに意図しない変更が発生していないことを確認しました。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

git status --short --branch
git diff
git diff --check

今回の作業では、シンボリックリンクの作成とWordPress上での有効化だけを行っているため、プラグインのソースコードには変更がない状態が正常です。

作業ツリーがクリーンなままであることを確認し、前回作成した基準点が維持されていることを確かめました。

WordPressがプラグインを有効化すると、データベースへ設定が保存される場合があります。

しかし、ソースコードの変更ではないため、通常はGitの差分には表示されません。

Gitが管理しているものと、WordPressのデータベースに保存されるものを区別して確認する必要があります。

シンボリックリンクをGitへ登録しない

今回作成したシンボリックリンクは、WordPress開発環境側の構成です。

プラグインのGitリポジトリ内に作成したものではないため、プラグインの変更履歴には含まれません。

このリンクは、Ubuntu上の保存場所に依存しています。

/mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

別のパソコンでは、ユーザー名、マウント先、プロジェクトの保存場所などが異なる可能性があります。

そのため、環境固有の絶対パスをプラグインのGitリポジトリへ含めるのではなく、各開発環境で必要に応じてリンクを作成します。

再構築に備えて、リンクの作成方法と確認手順はblogや開発用ドキュメントへ記録します。

リンクを削除する方法

プラグインをWordPressから切り離す場合は、シンボリックリンクだけを削除します。

rm \
/var/www/studio317/wordpress-dev/public/wp-content/plugins/studio317-report-drafts-google-analytics

削除対象がシンボリックリンクであることを、実行前にls -laで確認します。

シンボリックリンクを削除しても、リンク先のGitリポジトリは残ります。

ただし、コマンドの末尾や指定方法を誤ると、意図しないファイルを操作する可能性があります。

特にrm -rや管理者権限を使用する場合は、削除対象の絶対パスを十分に確認します。

今回整った開発の流れ

今回の構成により、Ubuntu上での実案件開発は次の流れになります。

1. GitリポジトリをVisual Studio Codeで開く

   プロジェクト用ストレージにあるソースコードを直接編集します。

2. ChatGPTで方針を整理する

   変更目的、影響範囲、確認項目、Codexへの依頼内容を検討します。

3. Codexが同じGitリポジトリを調査・編集する

   指定した範囲でファイルを変更し、構文確認やテストを行います。

4. WordPressで変更結果を確認する

   シンボリックリンクを通じて、変更したソースコードがすぐに反映されます。

5. 人間がGit差分と画面を確認する

   コードと実際の動作の両方を確認します。

6. 確認済みの変更だけをコミットする

   意図した変更だけをGitへ記録し、必要に応じてGitHubへ送信します。

ソースコードをコピーする作業が不要になり、Visual Studio Code、Codex、Git、WordPressが一つのプロジェクトを共有できるようになりました。

今回の到達点

今回は、プロジェクト用ストレージにある「Studio317 Report Drafts for Google Analytics」のGitリポジトリを、シンボリックリンクによってWordPressの開発サイトへ接続しました。

Apacheがリンク先のファイルを読み取れること、データストレージが正常にマウントされていること、WordPressがプラグインを認識することを確認しました。

PHPの構文と動作条件を確認した後、プラグインを有効化し、管理画面の各メニューを表示できることも確認しました。

また、Visual Studio CodeとCodexが編集するGitリポジトリと、WordPressが実行するプラグインが、同じソースコードであることを確認しました。

これにより、ソースコードを複数の場所へコピーせず、一つのGitリポジトリを基準として実案件の開発を行えるようになりました。