年明けの夜、私は初めて svn checkout を打ちました。きっかけは、WordPress.org からの差し戻しメールです。バナーをプラグイン本体の ZIP に同梱して出したら、画像は ZIP ではなく SVN に上げてください、と返ってきた。普段はずっと Git で、WordPress.org の公開がいまだに SVN だということを、そこで初めて知りました。
この記事は、その初めての SVN 公開でつまずいた記録です。先に初回リリースのコマンドを置きます。Git に慣れていれば、詰まるのはだいたい3か所なので、そこを後ろで一つずつ書きます。審査そのものは別記事「WordPress.org に初めて出したプラグインが2回差し戻された話」にまとめました。本記事はその続き、審査に通ったあとの公開作業です。
初回リリース、まず何を打つか
承認メールに SVN リポジトリの URL が載っています。それを使って、初回はこの順で打ちます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# ① 承認メールの SVN URL でチェックアウト svn checkout https://plugins.svn.wordpress.org/your-plugin/ wporg-svn cd wporg-svn # ② プラグイン本体を trunk/ にコピー cp -r /path/to/plugin-source/* trunk/ # ③ assets/ にバナー・アイコン・スクリーンショットを配置 # ★ここがリポジトリ直下。trunk/assets/ ではない cp /path/to/banner-772x250.png assets/ cp /path/to/icon-128x128.png assets/ # ④ SVN 管理対象に追加 svn add trunk/* --force svn add assets/* --force # ⑤ commit 前に必ず status で確認 svn status # ⑥ commit（この瞬間に世界へ配布される） svn commit -m "Initial release: version 1.0.6" # ⑦ tags/ にリリース版を固定 svn copy trunk tags/1.0.6 -m "Tag version 1.0.6" |
初回 commit で、WordPress.org のユーザー名とパスワードを聞かれます。macOS のキーチェーンに保存すれば、2回目から省略されます。詰まりやすいのは、このあとの3点でした。
バナーとアイコンは、どこに置く?
答えは、リポジトリ直下の assets/ です。trunk/assets/ ではありません。ここに置いた画像だけがプラグインページに反映されます。リポジトリ構造はこうなります。
|
1 2 3 4 5 6 7 8 9 |
your-plugin/ trunk/ ← プラグイン本体（次に出してよいコード） tags/ 1.0.6/ ← リリースごとの固定版 branches/ ← 個人開発では空のまま assets/ ← バナー・アイコン・スクリーンショット（リポジトリ直下） banner-772x250.png icon-128x128.png screenshot-1.png |
私が最初に間違えたのが、ここでした。Git で開発していると assets/ フォルダは見慣れているので、画像も本体と同じ感覚で ZIP に同梱してしまった。WordPress.org が画像を本体と別に管理している、という発想が無かったのです。承認後に自分で触り始めてから画像が表示されないと悩んでいたら、もっと長く詰まっていたと思います。
この矢印の場所を、私は最初に間違えました。
commit はやり直せる?
やり直せません。SVN の commit は、Git と違って、打った瞬間に中央リポジトリへ反映され、そのままプラグインページの更新になります。Git の commit はローカルへの記録で、push するまで手元に留まり、あとから書き換えもできます。SVN にその猶予はありません。
初回の commit を打って数秒後、プラグインページに行ったら、もう Version 1.0.6 として表示されていました。バナーも説明文もダウンロードボタンも動いている。commit した瞬間に世界へ配布される感覚は初めてで、少し怖くなりました。それ以来、SVN は気軽に試す場所ではなく、リリース済みのものを置く棚として扱っています。commit 1回が、だいたい1リリースです。
開発用ファイルは、どう除く?
除外リストを書いた rsync で同期します。GitHub からまるごとコピーすると、.git/ や CLAUDE.md、node_modules/、.DS_Store が trunk/ に紛れ込みます。SVN は利用者へ直接配布される場所なので、これらを入れてはいけません。手作業の cp だと、うっかりが必ず出ます。
|
1 2 3 4 5 6 7 8 9 10 |
# SVNリリース用 rsync（除外リスト付き） rsync -av --delete \ --exclude='.git' \ --exclude='.github' \ --exclude='CLAUDE.md' \ --exclude='.cursor*' \ --exclude='node_modules' \ --exclude='.DS_Store' \ --exclude='tests' \ "$SOURCE/" "$DEST/" |
commit 前に、何を見る?
svn status と svn diff の2つです。9回リリースしたいまも、commit 前に毎回見ます。
svn status では、? の記号（未管理）が残っていないかを確認します。SVN では新規ファイルを svn add で明示的に足さないと commit に入りません。Git の git add . の感覚でいると、新しいファイルが取り残されます。M は変更あり、A は追加予定、D は削除予定、? は未管理、C は競合です。
svn diff では、意図しない修正が混ざっていないかを見ます。エディタが勝手に整形した、改行コードが CRLF になった、という類を拾えます。
バージョンを上げるとき、どこを合わせる?
3つの値を必ず一致させます。readme.txt の Stable tag、メイン PHP ファイルの Version、そして tags/ に作るディレクトリ名です。
1.0.7 を出すなら、readme.txt が Stable tag: 1.0.7、PHP が Version: 1.0.7、SVN が tags/1.0.7/。WordPress.org はこの Stable tag を見て、どのバージョンを配布するかを決めます。3つが合っていれば、利用者の管理画面に更新がありますと出て、正しいコードが落ちます。ここがずれると配信が壊れます。2回目以降のリリースは、この順で機械的に進みます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# ① 最新化 svn up # ② GitHub から trunk/ に同期（rsync スクリプト） ./scripts/sync-to-svn.sh # ③ readme.txt の Stable tag を更新 # ④ メインPHPファイルの Version を更新 # ⑤ 最終確認 svn status svn diff # ⑥ trunk を commit svn commit -m "Release 1.0.7" # ⑦ tags にリリース版を作成 svn copy trunk tags/1.0.7 -m "Tag version 1.0.7" |
慣れると10分で終わります。それでも Stable tag の更新忘れが一番怖いので、リリース直前に readme.txt とメイン PHP の Version を声に出して読んで確認しています。
なお、Stable tag には trunk も指定できて、手順は1つ減ります。ただ個人開発では tags/1.0.7/ 形式を勧めます。trunk が即配布だと、開発用ファイルのうっかり混入が、一発で利用者に届く。固定版を配る形にしておけば、trunk に何か事故的に入っても、利用者が受け取るのは tags/ の固定版だけです。公式ドキュメントも tags/ 運用を勧めています。
画像のサイズとファイル名は?
バナーとアイコンは、ファイル名と画像サイズがピクセル単位で決まっています。
| 種類 | ファイル名 | サイズ |
|---|---|---|
| バナー（標準） | banner-772×250.png | 772 × 250 |
| バナー（Retina） | banner-1544×500.png | 1544 × 500 |
| アイコン（標準） | icon-128×128.png | 128 × 128 |
| アイコン（Retina） | icon-256×256.png | 256 × 256 |
| スクリーンショット | screenshot-1.png … | 横幅1200px前後 |
スクリーンショットの番号は、readme.txt の == Screenshots == に書いた説明と対応します。番号と説明がずれると、ページ上で画像と文章が噛み合いません。画像を差し替えても、反映には commit から15分から数時間かかります。反映されないと思って何度も commit し直すと履歴が荒れるので、待つのが正解です。
結局、SVN は配布の棚
振り返ると、どのつまずきも、公式ドキュメントには書いてあったのに最初は読み流していたから引っかかった、という類でした。WordPress.org の SVN は、開発の場所ではなく、配布する棚です。trunk/ には次に出してよいものだけ、tags/ にはリリース済みの固定版、assets/ はリポジトリ直下にバナーやアイコン。開発用ファイルは除外リストで弾く。commit 前に svn status と svn diff を見る。それだけで、初回公開で大事故になることはまずありません。開発は GitHub、配布は SVN。この2つを分けてからは、迷わなくなりました。
参考にした公式ドキュメント
- Using Subversion（Plugin Handbook）
- How Your Plugin Assets Work
- Detailed Plugin Guidelines
- Version Control with Subversion（SVN公式書籍）
確認日：2026年5月5日
関連記事
- WordPress.org に初めて出したプラグインが2回差し戻された話｜審査で実際に指摘された8項目と直し方。SVN 作業の前段にあたる、審査の落とし穴です。
- Rapls PDF Image Creator｜WordPress PDFサムネイル生成プラグイン。実際に SVN で公開したプラグインです。
コメント