/ programing

WordPress.orgにプラグインを投稿してみる

movabletype.orgはデビュー済みだったんだけど、wordpress.orgにもプラグインを投稿してみた。
http://wordpress.org/extend/plugins/profile/makoto_kw

いろいろ勉強になったり試行錯誤したのでまとめてみる。

WordPress.orgのプラグインディレクトリの仕組み

プラグインのリリースはblogだけに作者が自分のブログで紹介していることが多い。Movable Typeではプラグインの投稿フォームがあって基本的に自分のサイトへナビゲートする仕組みだったがWordPressの方は結構ちゃんとしたシステムがある。ただ以下の理由であんまり使っている人いないんじゃないかと思われる。

  • 英語しかない
  • Subversionに依存している

英語なので世界で使ってもらいたいという意欲がないとしんどい。また英語なので自分の日本語のブログで集客するので十分な気もする。まともなプログラマならソース管理はしていると思うが、そういったツールになじみがないサイト管理者やデザイナーな人がSubversionを理解してプラグインを投稿するのはしんどい。

一方で下記のようなメリットがある

  • 集客効果
    • wordpress.orgで検索する人が使ってくれるようになる
  • トラフィックの削減
    • wordpress.orgで公開できるため自宅サーバやレンタルサーバのトラフィックを削減できる
  • 更新コストの削減
    • パッケージングが不用
    • Subversionにcommitするだけで.zipにするのはwordrpress.orgがやってくれる
    • バージョンの更新を通知できる
    • 古いバージョンの公開ができる
  • フィードバック
    • WordPressユーザからの評価が受けられる
    • WordPressとのバージョンの互換性をWordPressユーザに投稿してもらえる

英語やSubversionを乗り越えて使うかどうかはこのあたりに価値を見いだせるかになる。自分の場合は更新コストの削減にメリットを感じた。

プラグインの投稿の方法

Subversionの説明から入るのは自分もしんどいのでそこはすっ飛ばして簡単にプラグインを投稿するまでの流れを書いてみる

  1. wordpress.orgにアカウントを登録する
  2. wordpress.orgにログインしてformからプラグインの申請をする
  3. しばらくするとメールが来てsubversionのリポジトリが用意される
  4. 開発中のコードはtrunkの下にプラグインのファイルをコミットする
  5. プラグインの説明などをreadme.txtに書いてtrunkにいれる
    • readme.txtはこのファイルが実質プラグインのページをつくる元であり超重要ファイル。
    • ファイルはwikiのような独自のフォーマットで作成する。テンプレートやチェックツールが用意されている。
  6. リリースできる準備が整ったらバージョンを決めてプラグイン内のphpとreadme.txtを更新する
    • phpの内のVersionを更新する
    • こいつとtrunk/readme.txtのバージョンを比較して更新の通知をするものだと思われる
    • readme.txt内のStableを更新する
    • こいつとSubversion内のタグがあってないと多分プラグインをダウンロードできない
  7. バージョン番号でタグを作成する

Subversionに依存しているが逆にいうとSubversionでコミットしたりタグをつくるだけであとはwordpress.orgが良きに計らってくれるので頻繁に更新する場合は楽だと思う。

プラグインの開発とテスト

リリースする手順は書いたが実際にはその間に開発やテストが入る。しかし、実際には 間 に入れるには下記のような理由で難しい場合があると思った。

  • そもそもリリースするかどうかわからない
    • 自分しか使わないかもしれない
    • やりたいことが実現できないかもしれない
    • 他のプラグインで代用できるかもしれない
  • プラグイン名が決まってない、まだ決めたくない
    • プラグイン名が決まらないと申請できない
    • 作りながらやりたいことや機能を固めていく過程で名前を決めたい

何が問題になったかというと名前が決まってない、リリースするかわからないプラグインでも自分は基本的にリポジトリ管理をしたいのである。ところがwordpress.orgでリポジトリ管理するにはプラグイン名を先に決めて登録しないといけない。鶏が先か卵が先か問題である。

さて自分はウェブサイトをプライベートなsubversionでソース管理していたので最終的に下記方法で管理し、開発とテストを行うことにした。

  1. 自分のブログとは別にプラグイン開発用のwordpressブログを用意する
    • 自分のブログはあくまでプラグインのユーザとし、そこで開発はしない
  2. 開発用のwordpressブログを自宅サーバのSubversionでソース管理する
    • wordpress.orgに投稿前のプラグインはここでソース管理する
  3. wordpress.orgで公開するようになったらsvn externalsを設定する
    • いったん自宅サーバのSubversionからはそのディレクトリは消してしまう
export SVN_EDITOR="vi"
cd /path/to/wordpress/wp-content
svn propedit svn:externals plugins

your-plugin1 http://plugins.svn.wordpress.org/your-plugin1/trunk
your-plugin2 http://plugins.svn.wordpress.org/your-plugin2/trunk
...

とりあえず、これで公開する前は自宅サーバ、公開後はexternalsでwordpress.orgでリポジトリ管理できるようになる。面倒なので公開するまでのリビジョンはwordpress.orgへは引き継がない。見ようと思えば自宅サーバで追えるしリリース前の履歴はそれほど重要じゃないことが多いと思うので。

gitで開発しようとして挫折

余談だが、現在の自分ポリシーではなるべくgitを使うことにしているので開発テストは常に(wordpress.org公開後も)gitで開発し、git svnを使ってwordpress.orgにpushしようと思って手順を考え実施したのだけど挫折した。

挫折した理由はgit svn cloneに尋常じゃなく時間がかかるから。git svnを使った人は知ってると思うけど階層化のディレクトリと同期しようとしてもsvnのルートから全部のrevisionを舐めるのよね。で、ルートってplugins.svn.wordpress.orgなわけで世界中のプラグイン開発者のコミットが含まれているのよね。ちなみに自分がプラグインをコミットしたときのリビジョンは18万を超えてるのよね。ギニュー隊長がチェンジするレベルなのよね。まぁcloneしないで直接リモートリポジトリを入れて、rebaseしないと直接commitしたらできるのかもしれないけどそこまでして頑張る意味もないのであきらめた。

ちなみにやろうとした手順

  1. gitで普通にバージョン管理をする(Git local repo A)
  2. plugins.svn.wordpress.orgのができたらgit-svnでcloneする(Git local repo B)
  3. Git repo BからGit repo Aのコミットをpullする
  4. Git repo Aはさようなら
  5. Git repo Bからdcommitする
Markdown with by ❤ wp-gfm