WordPress.orgプラグイン公開のためのSVN実践ガイド｜assets配置からTortoiseSVNまで

前編ではSVNの基本概念とブランチ戦略について解説しました。後編となる本記事では、WordPress.orgへのプラグイン公開に特化した実践的な手順を解説します。

WordPress.orgのプラグインディレクトリは、2024年現在もSVNで運用されています。GitHubで開発していても、公式ディレクトリへの配布にはSVNの知識が必要です。「SVNなんて触ったことない」という方も、この記事の手順に沿えばスムーズに公開できるはずです。

WordPress.org SVNの特殊性

まず理解しておくべき重要なポイントがあります。

WordPress.orgのSVNは「配布用リポジトリ」であり、開発用ではありません。

GitHubのようにプルリクエストを出したり、細かいコミットを積み重ねたりする場所ではないのです。完成したプラグインを置き、バージョンをタグ付けし、ユーザーがダウンロードできるようにする——それが主な役割です。

したがって、開発段階の中間コミットを大量にアップロードするのは避けてください。リリース単位でまとめてコミットするのがベストプラクティスです。

WordPress.org SVNのディレクトリ構成

プラグインが審査を通過すると、以下のようなSVNリポジトリが自動的に用意されます。

https://plugins.svn.wordpress.org/your-plugin-slug/
  trunk/
  tags/
  branches/
  assets/

それぞれの役割を確認しましょう。

trunk/ — プラグインの最新コードを置く場所。次回リリース予定のバージョンを配置します。

tags/ — リリース済みバージョンを保存する場所。tags/1.0.0/、tags/1.0.1/のようにバージョンごとのディレクトリを作ります。

branches/ — 開発用ブランチを置く場所。WordPress.orgでは通常使いません。

assets/ — プラグインページに表示されるバナー、アイコン、スクリーンショットを置く場所。ここがWordPress.org特有の重要ポイントです。

assetsの配置場所に要注意

最も多い間違いが、assetsの配置場所です。

❌ trunk/assets/banner-772x250.png    ← 間違い
✅ assets/banner-772x250.png          ← 正しい

バナーやアイコンはリポジトリ直下のassets/に配置します。trunkの中やtagsの中ではありません。これを間違えると、プラグインページに画像が表示されません。

初期セットアップ：checkoutから最初のコミットまで

Step 1：リポジトリをチェックアウト

審査通過後に届くメールに記載されたSVN URLを使って、作業コピーを取得します。

svn checkout https://plugins.svn.wordpress.org/your-plugin-slug/ wporg-svn
cd wporg-svn

チェックアウトが完了すると、trunk/、tags/、branches/、assets/の空ディレクトリ（または既存の構成）が見えるはずです。

Step 2：trunkにプラグインファイルを配置

プラグインのコードをtrunkに配置します。

wporg-svn/
  trunk/
    your-plugin.php      ← メインファイル
    readme.txt           ← 必須
    includes/            ← 必要に応じて
    css/
    js/
  assets/                ← バナー・アイコン用（後述）
  tags/
  branches/

Step 3：addとcommit

svn add trunk/* --force
svn commit -m "Initial commit: version 1.0.0"

--forceオプションにより、ディレクトリ内のすべてのファイルが再帰的に追加されます。

assets（バナー・アイコン・スクリーンショット）の設定

WordPress.orgのプラグインページを魅力的に見せるには、適切な画像アセットが欠かせません。

バナー画像

プラグインページのヘッダーに表示される横長の画像です。

アイコン画像

プラグイン一覧や検索結果に表示される正方形のアイコンです。

スクリーンショット

プラグインの動作画面を示す画像です。

スクリーンショットはreadme.txtの== Screenshots ==セクションと連動します。

== Screenshots ==

1. 設定画面の例
2. フロントエンドでの表示例
3. ウィジェットの設定

この番号とscreenshot-N.pngのNが対応します。

assetsの配置とコミット

wporg-svn/
  assets/
    banner-772x250.png
    banner-1544x500.png
    icon-128x128.png
    icon-256x256.png
    screenshot-1.png
    screenshot-2.png

svn add assets/* --force
svn commit -m "Add plugin assets: banner, icon, screenshots"

画像が表示されない場合のチェックポイント

1. ファイル名のスペルミス — banner-772x250.pngは正確に
2. サイズの不一致 — ファイル名と実際の画像サイズが一致しているか
3. 配置場所 — trunk/assets/ではなくassets/直下か
4. CDNキャッシュ — 反映まで数分〜数時間かかることがある

リリースの手順：Stable tagとtagsの関係

WordPress.orgでは、readme.txtのStable tagとtags/ディレクトリの組み合わせでリリースバージョンが決まります。この仕組みを正しく理解することが重要です。

Stable tagとは

readme.txtの先頭付近にある以下の行です。

Stable tag: 1.0.0

WordPress.orgは、この値を見て「ユーザーにダウンロードさせるバージョン」を決定します。Stable tag: 1.0.0と書かれていれば、tags/1.0.0/のコードが配布されます。

リリースの流れ

バージョン1.0.0をリリースする例で説明します。

1. trunkを最終状態に整える

バグ修正、機能追加、テストをすべて完了させます。

2. readme.txtのStable tagを更新

Stable tag: 1.0.0

3. trunkをコミット

svn commit -m "Release prep: version 1.0.0"

4. trunkからtagsへコピー

svn copy trunk tags/1.0.0 -m "Tag version 1.0.0"

これでtags/1.0.0/が作成され、WordPress.orgのプラグインページからダウンロードできるようになります。

次のバージョン（1.0.1）のリリース

# 1. trunkで修正作業
# 2. readme.txtのバージョン情報を更新
# 3. Stable tag: 1.0.1 に変更
# 4. コミット
svn commit -m "Release prep: version 1.0.1"

# 5. tagsを作成
svn copy trunk tags/1.0.1 -m "Tag version 1.0.1"

trunk vs tags：どちらが優先？

Stable tag: trunkと書くと、trunkの内容がそのまま配布されます。しかし、これは推奨されません。tagsを切ることで、特定のバージョンを明確に固定でき、問題が起きた場合のロールバックも容易になります。

Gitで開発、SVNで配布：現代的なワークフロー

実際の開発では、GitHubで開発してWordPress.orgのSVNにはリリース時だけ同期する、というワークフローが主流です。

このワークフローのメリット

• GitHubでプルリクエスト、コードレビュー、CIを活用できる
• WordPress.org側の履歴がクリーンになる（リリース単位のコミットのみ）
• 開発とリリースを明確に分離できる

具体的な手順

1. GitHubリポジトリで開発を進める

通常通りブランチを切り、PRをマージしていきます。

2. リリース準備ができたら、SVN作業コピーを更新

cd wporg-svn
svn up

3. trunk内を差し替え

既存のtrunk内ファイルを削除し、GitHubリポジトリから最新のビルドをコピーします。

rm -rf trunk/*
cp -r /path/to/github-repo/dist/* trunk/

4. 変更をaddしてcommit

svn add trunk/* --force
svn status  # 削除されたファイルがあればsvn deleteで処理

# 削除されたファイルを一括処理
svn status | grep '^!' | awk '{print $2}' | xargs svn delete

svn commit -m "Release 1.2.0"

5. tagsを切る

svn copy trunk tags/1.2.0 -m "Tag 1.2.0"

自動化ツール

手動での同期が面倒な場合、以下のツールが利用できます。

• GitHub Actions — リリースタグをプッシュしたら自動でSVNにデプロイ
• 10up/action-wordpress-plugin-deploy — WordPress.org SVNへのデプロイ用GitHub Action

TortoiseSVN：Windows向けGUIクライアント

コマンドラインが苦手な方には、TortoiseSVNがおすすめです。Windowsのエクスプローラーに統合され、右クリックメニューからSVN操作ができます。

基本的な使い方

1. 右クリック → SVN Checkout — 作業コピーを作成
2. 右クリック → SVN Update — 最新化
3. 右クリック → SVN Commit — コミット
4. 右クリック → TortoiseSVN → Diff — 差分確認
5. 右クリック → TortoiseSVN → Show log — 履歴表示

GUI操作とコマンドの対応表

TortoiseSVN運用Tips

コミット前にDiff — コミットダイアログで変更内容を確認してから実行すると、意図しない変更を防げます。

Cleanupを恐れない — 作業コピーがおかしくなったら、まずCleanupを試してください。

Check for Modifications — 現在の変更状態を一覧表示。svn statusのGUI版です。

よくある落とし穴と対処法

「assetsが表示されない」

原因の90%は配置場所の間違いです。trunk/assets/ではなく、リポジトリ直下のassets/に置いてください。

「svn addを忘れてコミットしようとした」

svn statusで?マークが付いているファイルは、SVNの管理対象外です。必要なファイルにはsvn addを忘れずに。

「画像が反映されない」

WordPress.orgはCDNを使っているため、画像の反映に時間がかかることがあります。数分〜数時間待ってみてください。

「間違ったバージョンが配布されている」

readme.txtのStable tagを確認してください。この値とtags/内のディレクトリ名が一致している必要があります。

「競合（C）が発生した」

WordPress.orgのSVNは基本的に自分だけが使うので競合は稀ですが、発生した場合は以下の手順で解決します。

svn update           # 最新状態を取得
# 手動でファイルを編集し、競合を解消
svn resolved FILE    # 解決済みとしてマーク
svn commit -m "..."  # コミット

コミット前チェックリスト（WordPress.org SVN用）

• svn upで最新化したか
• svn stで?（add忘れ）がないか
• 開発用ファイル（node_modules、.git、テストファイル）を含めていないか
• readme.txtのStable tagは正しいか
• assetsは正しい場所（リポジトリ直下）にあるか
• 画像ファイル名とサイズは仕様通りか

参考リソース

より詳しい情報は、以下の公式ドキュメントを参照してください。

WordPress公式

• Using Subversion（Plugin Handbook）
• How Your Plugin Assets Work

TortoiseSVN

• TortoiseSVN Commands（英語）
• TortoiseSVNのコマンド（日本語）

まとめ

WordPress.orgへのプラグイン公開は、SVNの基本を押さえれば難しくありません。重要なポイントを振り返ります。

1. WordPress.orgのSVNは「配布用」。細かいコミットは避け、リリース単位でまとめる
2. assetsはリポジトリ直下のassets/に配置する（trunk/assets/ではない）
3. Stable tagとtags/ディレクトリの組み合わせでリリースバージョンが決まる
4. GitHubで開発し、SVNにはリリース時だけ同期するワークフローが現実的

前編と合わせて、SVNの基礎からWordPress.org公開まで、一通りの知識が身についたはずです。ぜひ実際にプラグインを公開してみてください。

← 前編を読む：SVN（Subversion）完全入門｜Gitユーザーのための基礎知識とブランチ戦略