『サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル』

事前にレビューする機会を与えられた書籍『サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル』が発売されました。

タイトルのとおり「プラグイン開発」に焦点を当てたもので、これまでの WordPress 関連書籍と一線を画しています。

まえがきに「開発者をターゲットとした WordPress の専門書」とあり、WordPress 固有のプラグインの仕組みの解説はもちろん、WordPress プラグイン開発に適した環境の構築から、コーディング規約、テスト方法まで、懇切丁寧に書かれています。これらをまとめて一瞥できるのは大変ありがたいことです。

WordPress の特徴としての GPL についてもひとつの章を充ててじっくりと説明されています。その上でのビジネスモデルにも言及されており、一読の価値があります。

そして開発したプラグインを公式ディレクトリで公開する方法も紹介されています。評者はこの本の出る少し前に初めて公開を前提としてプラグインを書き、公式ディレクトリに登録してみました。まったく大したものではありませんが、「公開」を念頭に置くと適当なことはできないので、ウェブであちこち検索して回ってできるだけきれいに、間違いのないようにとあらためて勉強することになりました。そのときにこの本があればかなり近道ができたはずです。

さて発売前のレビューの際に、細かな用字の指摘のほかにもやや大きな修正や加筆を必要とするようなコメントを著者に返しました。前者はともかく後者については、たぶん時間的にも分量的にも制約が大きかったのでしょう、残念ながら反映してもらうことができなかったものがありました。

そのひとつが、第8章「管理画面」の特に8-3節「管理画面を使って独自の設定を保存する」についてです。著者たちがあまりにプラグイン開発の経験に富んでいて、ずっと以前から WordPress に精通しているためか、旧来の手法による記述になっています。古いプラグインを読んで理解するにはいいかもしれませんが、これから新たに開発する場合にはこの箇所の記述のようにする必要はありません。WordPress の現在のバージョンには、より簡便で安全な手法 (Setteings API) が用意されています。せっかくこの年になって出版される日本語で初めて(たぶん)のプラグイン開発の解説書ですから、ぜひ Settings API に触れてほしかった—というか現状の8-3節と差し替えてもいいくらいでは—と思います。

そういった点はあるにしても、全体にこの本から受けることのできる恩恵は大きなものがあります。

評者は WordPress の単なるユーザーとなってから数年の時間が経過していますが、実際にプラグインを作ってみること、それも公開しても恥ずかしくないように書いてみることをやってみてはじめて、それまで適当にしか理解していなかったことについてもきちんと知る必要が出てきて、学ぶことが非常に多くありました。その経験をとおして WordPress そのものについての理解、ほかの人たちが作った便利なプラグインについての理解がかなり深まりました。

そういった意味で、この本が「ターゲットはプラグイン開発者」と謳っていても、一般のユーザーも手にとって読んでみるといいと思います。そして簡単なものでもいいので(最終的には公式ディレクトリに登録はしないにしても)「正しい」作法でプラグインを書いてみると、 WordPress をより理解し活用することにつながるでしょう。

WordPress プラグインやテーマの翻訳でうまく手を抜く(いい意味で)

WordCamp Kansai 2014 に行ってきました。2日め“コントリビューターデイ”、プラグイン・テーマ翻訳の世話役だったのですが、可搬 PC は持っていないし、子連れだし、遠方まで帰るために途中で抜けなければならないし、さらに、「Mac/Win で Poedit というアプリケーションを使う」というのが最も一般的と思われるのに自分では使っていないため[1]に操作方法を即答できない……、という幾重もの役立たずぶりですみませんでした。こどもの相手やら何やら、こちらのほうがお世話になりっぱなしで、ありがとうございました。

そういう中で質問を受けたことを、今さらながらここに書いておこうと思います。

翻訳作業のステップ

WordPress のプラグインやテーマの翻訳をやってみようという記事はあちこちにたくさんあります。ここでは細かく書きませんので、それらを参照してみてください。「POT ファイルとは何か」「PO ファイルとは何か」「それらはどこにあるか」などは既に知っているという前提で進めます。

おさらいです。WordPress のプラグインやテーマの翻訳作業のステップは

  1. プラグインやテーマのプログラムの中の翻訳されるべきメッセージに __() や _e() などのマークを付ける
  2. マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成する
  3. POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイル を準備する
  4. PO ファイルを編集する (これがほんとうの翻訳作業)

です。作業のスタート地点が後ろに近いほど、とっかかりやすいです[2]

最も始めやすい状態: ステップ4から

たくさんある記事のひとつ、Nao さんの「2014年版: WordPress プラグイン・テーマの翻訳を始めてみよう」を見てみます。

その記事にありますように、最も手軽に始められるのが、既に全部または一部翻訳がなされているものに対して、誤訳を修正するとか、別の訳語にするとか、訳の抜けている部分を補う、というものです。これなら最初のハードルがぐっと低く、ともかく「やってみよう」という気になれます。

Poedit なら、書き換えたい PO ファイルを開き、当該箇所を修正・加筆するだけです。

その次に楽な状態: ステップ3から

プラグインやテーマそのものは翻訳可能 (POT ファイルが用意されている) だが日本語訳 (name-ja.po) がない状態というのが、その次にとっつきやすい状態です。

公式ディレクトリに登録されているプラグインテーマなら「translation-ready」というタグが付けられているでしょう。ここでいうステップ1や2の処理が既にされているという意味です。

Poedit なら、「ファイル」-「POT ファイルを元に新しいカタログを作成…」で、「言語」に ja を指定して適切な名前 (name-ja.po の形) で保存します。

コマンドラインを使えるなら Poedit を使わずに、

msginit -i name.pot -o name-ja.po -l ja 

です。意味はなんとなくわかりますね。

この時点で、翻訳率0% の日本語翻訳ファイル name-ja.po ができます。

ステップ3をステップ4に

「0%」……嫌な響きですね。これだけでやる気が削がれてしまいます。なので、過去の資産から使えるものは少しでも流用します。

たとえばテーマの翻訳をしようとしているとします。その最初に、既存の、たとえばデフォルトテーマの twentyfourteen の翻訳を取り込んでしまおうというのです。

もしステップ3をコマンドラインでできたようなら、これまたコマンドラインで

msgmerge -o name-ja.po -C wordpress/wp-content/languages/themes/twentyfourteen-ja.po name-ja.po name.pot

のように、msgmerge を使います。-C で参考とする PO ファイルを指定します。-C はひとつのコマンドラインの中に何度でも指定できるので、WordPress 本体の ja.po や admin-ja.po も追加するといいかもしれません。

Poedit ではこれに相当する操作が簡単にできないようです。そこでステップ3の代わりに、次のようにします。name-ja.po がまだ存在しない状態で、参考とする PO ファイル (たとえば twentyfourteen-ja.po) を name-ja.po という名前でコピーします。これを Poedit で開き、「カタログ」-「POTファイルでカタログを更新…」します。

すると、英文が合致する分の翻訳がそのまま取り込まれます[3]。プラグインでは参考にする似たものを見つけてくることが難しいかもしれませんが、テーマの場合は、デフォルトのテーマを参考にしてうまくいけば80%ほども翻訳済みにしてしまうことができます。

これで、スタート地点をステップ3からではなく、ステップ4からにすることができます。

翻訳メモリ

Poedit には翻訳メモリという機能があります。データベースに登録しておけば、それを自動的に参照して、英文が合致する分を埋めてくれます。まずは WordPress 本体の ja.mo や admin-ja.mo それにデフォルトのテーマの twentyfourteen-ja.mo を登録しておきましょう。

これによってもスタート地点をステップ3からではなく、ステップ4からにすることができます。

前節の方法と翻訳メモリの方法は同時に使うこともできますので、積極的に翻訳メモリを使うのがいいでしょう。

といっても私自身が Poedit 自体(ということは翻訳メモリも)使っていませんので詳しく書けません。かなり古い記事ですが Tai さんの「poEditの翻訳メモリ機能を使う」や Miyoshi さんの「poEdit で翻訳ファイルを作る 」の「翻訳メモリを活用する」の節などを参考にしてください。

手抜きの効果

「手抜き」というと負のイメージの言葉ですが、ここではまったくそういうことはありません。むしろ用語の統一という点でも、積極的にここに書いた方法をとるべきだと思います。

そこで、最初掲げたステップを修正して、

  1. プラグインやテーマのプログラムの中の翻訳されるべきメッセージに __() や _e() などのマークを付けておく
  2. マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成
  3. POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイル を作る
    1. 過去の資産を参照して自動的に、できるだけ翻訳を埋める
  4. PO ファイルを編集する (これがほんとうの翻訳作業)

の赤い字の項目を必ず実行するように意識することを強くお奨めします。

ざっと検索してみた Poedit の使い方、WordPress の翻訳や WordPress 翻訳祭りのような WordBench などでの解説でも「POT ファイルから PO ファイルを作りましょう。空っぽの ja.po ができましたね。さあ翻訳を始めましょう」と、このあいだのステップが飛ばされているように思います。

いまからやろうとしている翻訳は、単語レベルでは既に誰かがやっているかもしれません。WordCamp Kansai 2014 のキーワードは「Share 分かちあい」でしたね。share できるものは share して、抜ける手はなるべく抜いて、その余力は別のところで活かしましょう。

これくらいの下調べは前もってやっておくべきでした。すみません。今後の各地のイベントや、あるいは個人で、翻訳やってみようかなというときには、前に書いた「WordPress 翻訳祭り—今さら注意してもらえない「日本語」について 」と併せて参考にしてもらえればと思います。

  1. ふだんは Debian 上の Emacs の po-mode で作業しています。
  2. このあと、それを開発者に送るとか、開発者の側では送られてきたものを最新版に合わせてからパッケージに同梱するとかの作業もありますが、ここでは省略します。それらとステップ2については以前「プラグインやテーマの国際化を少し楽に」に書きました。
  3. 合致しなかった部分を掃除するには Poedit では「カタログ」-「Purge Deleted Translations」です。

チャットサポートを構築する (その4) 連絡先の設定とまとめ

共有名簿 (shared roster)

ふつうの XMPP では、相手先名簿 (roster) は JID に紐付けられ、サーバーに保持されています。ところが匿名サーバーの場合、接続要求があった際にそのアカウントが新たに一時的に生成されるため、その JID には相手先名簿がありません。そこで、XMPP の共有名簿(shared roster)という機能を使うことにします。

ejabberd の設定ファイル ejabberd.cfg では

{modules,
 [
  ...
  {mod_shared_roster,[]},
  ...
]}.

とモジュールを有効化しておきます。

ejabberd のウェブ管理画面の「ヴァーチャルホスト -> anonymous.example.net -> 共有名簿グループ」の画面で、まずひとつのグループを作成します。たとえば

  • 名前: support
  • 説明: サポート窓口
  • メンバー: support@example.net
  • 表示グループ: (空欄)

のようにします。ここで support@example.net は、窓口側(問い合わせを受ける側)の JID です。

さらにもうひとつグループを作成します。

  • 名前: all
  • 説明: 全ユーザー
  • メンバー: @all@
  • 表示グループ: support

ここで @all@ は、「全ユーザー」を意味します。

これで、「anonymous.example.net の全ユーザーの名簿に support グループのメンバー(ここでは support@example.net のみ)を自動的にセットする」ことができ、上述の(3)をクリアできました。

チャットサポート構築のまとめ

ここまでで、どうにかチャットサポートを構築できました。まとめますと、「チャットサポート」に求められる要件、

  1. アプリケーションの事前インストールが不要
  2. アカウント(JID)の登録が不要
  3. 連絡先が登録済み

に対して、(1)は Converse.js を導入することで、(2)はクッキーを利用し匿名サーバーを設定することで、そして(3)は共有名簿 (shared roster) を使うことでクリアして、一応「チャットサポート」的なものができました。そしてこれらを WordPress のサイトに導入するために プラグイン化しました。試しにこのサイトに設置してみました。画面の右下に小さなタブが見えると思います。

とりあえずはできたものの、課題も残っています。

前にも書いたとおり、事前接続のところがよく理解できていないこともあって、匿名サーバーだと使えますが、特定の JID を事前設定しようとするとうまくいきません。また、ページ遷移に対応できていません。

匿名サーバーの場合、共有名簿を使ってみましたが、多重に読み込んでいるのか、同じ相手先が増殖することがあります。どういうことなのかよくわかりません。また、これは匿名サーバーの宿命なのですが、接続した時点で相手先からは認証されていないので(その時点で生成された ID なので当然)、その相手先の在席状況が不明で「オフライン」と表示されてしまいます。印象が悪いので、WordPress のプラグインではこれを隠すようにしてみました。

今回、恥を忍んで中途半端な状態でも公開してこのような文を書いたのは、誰か能力のある人がちゃんとした実装を教えてくれることを期待してのことです。XMPP ならまだしも、Strophe.js や Converse.js で検索しても、とにかく日本語での情報は非常に少なく、どこで聞いたらいいかもわからないほどです。

何かわかる方がありましたら、教えてください。または情報をぜひ公開してください。お願いします。

チャットサポートを構築する (その3) Converse.js を WordPress で使うプラグイン ConverseJS for WordPress

(その1)テストのページに示したように、Converse.js は、css と設定のための script を読みこめば簡単に設置できます。ということは、WordPress のサイトにも設置できます。これを実現するプラグインを作り、公開しました。

GitHub にも置いています

Converse.js を同梱しているので、このプラグインをインストールするだけで済みます。

ダッシュボード -> 設定 -> Converse.js で、主な設定値の変更ができるようにしています。設定値の詳細は Converse.js のマニュアルを参照してください。

設定項目の最初の Converse.js URL は、空白にすると、プラグイン同梱の converse-min.js を読み込みます。ただのファイル名 converse.jsconverse-no-otr.min.jsconverse-no-locales-no-otr.min.js と書くと、やはりプラグイン同梱のものを読み込みます。外部のものを使いたい場合は、正しい URL を設定してください。

2番めの BOSH Server URL は、空白にすると、Converse.js が用意しているテストのための https://bind.opkode.im を使います。なるべくほかの BOSH サーバーを指定してください。

(その2)にも書きましたように、事前接続はまだよく理解していないので、正しい実装ができていません。設定の prebind (事前接続)にチェックを入れ、JID とパスワードを入力しておくと、正しく接続できて名簿も取得できるように見えるのですが、会話ができません。Converse.js の GitHub でのこの議論と同じだと思うのですが、具体的にどうしたらいいかわかりません。詳しい方がありましたら、ぜひ教えてください。下に述べるように、匿名サーバーに接続してチャットサポート的に使うことはできます。

設定例

オープンな XMPP クライアント

初期状態のままで、ふつうの XMPP クライアントのようになります。右下にウィンドウが表示されているはずです。JID とパスワードを入力すれば、そのまま使用できます。

チャットに使用するアカウント (JID と呼ばれます)を持っていなければ、公開サーバー(たとえば STEP.im)で作ることができます。あるいは WordPress.com のアカウントを持っていれば、name@im.wordpress.com の形で、JID として使うことができます。

facebook のチャットにも使えます(たぶん)。JID に (ユーザー名)@chat.facebook.com を入力します。facebook はその中で閉じているので、facebook 以外と会話することはできません。

チャットサポート

匿名サーバーに事前接続することで、チャットサポートの形にすることができます。

prebind にチェックを入れます。JID 欄には匿名サーバーのホスト名だけを入れます。パスワード欄は空のままにしておきます。これで、これが設置してあるページを開くと、自動的に匿名サーバーに接続し、IDを割り振られます。

一応これで使えるのですが、やはり事前接続の正しい理解と実装ができていないので、ページ遷移(WordPressの同一サイト内で別のページに移動した場合)に対応していません。いったん接続が切れて、また新たに接続する(匿名サーバーだと新しいIDになってしまう)ことになってしまいます。詳しい方がありましたら、ぜひ教えてください。

この項もう少し続く

チャットサポートを構築する (その2) サーバー ejabberd の準備

前回の「チャットサポートを構築する (その1)」は、Converse.js を設置し、(テストのページ)のように、普通の XMPP クライアントとして使えるというところまででした。

BOSH サーバー

ここからしばらく、サーバー側の設定の話になります。

クライアントが Converse.js などウェブベースのもので内部状態を保持できないような場合、BOSHという仕組みを介することで、接続を維持します。XMPP サーバーの ejabberd の場合、設定ファイル ejabberd.cfg次のように書くことで、BOSH サーバーにもなります[1]

ポート 5281 (HTTPSの場合)を listen するところに http-bind と書き足します。

{listen,
 [
  ...
{5281, ejabberd_http, [
       ...
       http_bind,
       ...
       ]}
  ...
]}

モジュールの設定のところで

{modules,
 [
  ...
  {mod_http_bind, []},
  ...
]}

を読み込むようにします。

匿名サーバー

XMPP サーバーには匿名サーバーという機能を持つものがあります。一般にクライアントがサーバーに接続する場合、事前に登録して作成しておいた user@example.net という形をした JID と、パスワードが必要になりますが、匿名サーバーは、そのサーバー名だけを指定して接続を試みると、@ より前のユーザー名を乱数のようにそのつど生成して接続します。

サーバーアプリケーション ejabberd の場合、ejabberd.cfg につぎのように設定して SASL 匿名サーバー (anonymous.example.net という名前だとします) を設置します。

{hosts, [ ..., "anonymous.example.net"]}.

{host_config, "anonymous.example.net", [
                               ...
                               {auth_method, anonymous},
                               {anonymous_protocol, sasl_anon},
                               {s2s_default_policy, deny},
                               {{s2s_host,"example.net"}, allow},
                               ...
]}.

s2s_... は、匿名サーバーに接続したユーザーは特定のサーバー以外への通信を禁止するという設定です。

クライアント側の事前接続

ここからクライアント側の話です。

「チャットサポート」として利用できるためには

  1. アプリケーションの事前インストールが不要
  2. アカウント(JID)の登録が不要
  3. 連絡先が登録済み

であることが必要です。前回はこの最初の項目、Converse.js をごくふつうに設置する(テストのページ)ところまで行いましたが、このままでは客側にアカウント (JID) を入力してもらわなければなりません。

Converse.js のマニュアルに Server-side authentication という章があります。別の何らかの方法で事前にサーバーに接続しておき、その情報を引き継げば、上述の2番めの項目をクリアできます。接続先を匿名サーバにすればパスワードも不要になります。しかし、マニュアルには具体的な方法はありません。

次のような方法を考えてみましたがこれで正しいのかよくわかっていません。とりあえず(ある場合には)うまくいっています。もし詳しい方がありましたら、ぜひ教えてください。

Converse.js の初期設定を書く <script> のところの先頭に書き足します。

<script TYPE="text/javascript">
var BOSH_SERVICE = 'https://anonymous.example.net:5281/http-bind';
conn = new Strophe.Connection(BOSH_SERVICE);
conn.connect('anonymous.example.net', '', onConnect);

function onConnect(status)
{
     wpCookies.set('jid', conn.jid);
     wpCookies.set('sid', conn.sid);
     wpCookies.set('rid', conn.rid);
}

Strophe.js は Converse.js に同梱されているので、Converse.js を利用できるようにしていれば、使えます。接続すると JID、SID、RID が確定するので、それをクッキーとして書き出します。ここでは WordPress の wp-include/js/utils.js を利用した記述 wpCookies.set になっていますが、もちろんそれでなくてもかまいません。

それに続く Converse.js の設定では

require(['converse'], function (converse) {
    converse.initialize({
        ...
        bosh_service_url: BOSH_SERVICE,
        prebind: true,
        jid: wpCookies.get('jid'),
        rid: wpCookies.get('rid'),
        sid: wpCookies.get('sid'),
        ...
    });
});
</script>

と、bosh_service_url を指定し、prebindtrue とし、jid, rid, sid をクッキーから読み込みます。

この項まだ続く

  1. BOSH サーバーには2種類あります。local BOSH サーバーは、入り口はどこからでも接続できますが、ローカルのアカウントにしか接続できません。それに対して open BOSH サーバーは、他所のサーバーのアカウントにも接続できます。ejabberd の BOSH は local タイプです。

チャットサポートを構築する (その1)

ずっと頭の片隅にあっていつかはと思っていた話題ですが、あたためすぎて腐ってしまった感なきにしもあらずです。何しろ自分でプログラムを書くほどの能力がないので、道具が出揃うのを待っているうちに随分時間が経ってしまいました。

「チャットサポート」というものについて考えてみます。Wikipedia の記述をそのまま引用しますが、

文字通り、チャットによるサポートであり、閲覧中のWebページ内のチャットボタンをクリックするだけでリアルタイムに Web サイト運営者のサポートをリアルタイムに受けることが出来るシステム。……英語ではLive Chat Supportと呼ばれることが多い。

というものです。アメリカのネット通販サイトなどではよく目にしますが、日本ではあまり見かけません。それでも「チャットサポート」で検索すると、日本(語)でもそのようなサービスを提供するところが増えてきているようです。

しかし大手の販売サイトならともかく、月に数回程度の利用しかないと想定される規模では、月額数千–数万円のサービス料金がメリットに見合うとは、あまり思えません。

そこですべてオープンソースの個々の汎用アプリケーションを組み合わせて、無料でこの仕組みを構築することを考えてみました。プログラムを書く能力があれば自分で作れるのでしょうが、それができないために、あちこちのソフトを組み合わせることになりました。

基本はチャットですから、XMPP を使います。このプロトコル自体がオープンであり、Skype や LINE や twitter などとは異なります。

すべてオープンソースの組み合わせで構築すると

  • 費用が発生しない
  • 独占企業の都合によるサービスの変更や停止ということがない
  • 個々のアプリケーションを取り替えられる
  • カスタマイズできる
  • サーバーも自分で管理すれば他者を経由しないので情報の流出の不安がない

などのメリットがあります。

もちろん逆に、一定の労力が必要だったり、汎用アプリのため洗練されていないなどのデメリットもあります。

通常のチャットでは、話者のそれぞれが XMPP のアカウント(JIDといいます)を持ち、互いに相手先を名簿に登録しており、それぞれ手元の端末にインストールするなりした XMPP のアプリケーションを使って、サーバーを介して会話します。「チャットサポート」の場合、サポートする側(問い合わせを受ける側。以下、便宜的に「窓口側」と呼びます)は別として、一度きりかもしれない問い合わせを行う側(以下、「客側」と呼びます)に、そのためにアカウントやアプリケーションを用意してもらうことは非常に難しいでしょう。

Converse.js

まず XMPP クライアントアプリケーションですが、JavaScript で書かれたものをウェブページに設置することで、そのページにアクセスするだけで利用できるようにします。これで、客側が事前にアプリケーションをインストールしなければならないということがなくなります。

Converse.js というものを見つけました。2014年初頭現在、活発に開発されているようです。多言語化されているようですが、日本語はまだ対応していなかったので、翻訳して作者に送ってみました。この時点で日本語での情報はほとんどなく、見つけたのは「Ejabberd+Apache mod_proxy+converse.jsでXMPP(BOSH)なチャット環境を作ってみた」でした。

さて、マニュアルに従って設置してみます。<head>内に CSS と本体の js を読み込むように書き、またページ後半に初期設定を記した <script> を書きます。ここまでは簡単で、そのまま Converse.js が使えるようになりました。

テストのページで実際に見てみるとわかるように、素のままでは普通の XMPP クライアントとかわりません。すなわち、自分のアカウント情報を入力し、相手先のアカウントを指定して会話を開始する、というものです。

長くなりそうなので、この項続く

WordPress のプラグインを公式リポジトリと GitHub に公開する

昨年末に公開したプラグイン wp_mail to XMPP は、Git で管理しつつ作ってみました。ひととおりできたところで GitHub に公開。それから公式リポジトリを申請して、こちらは SVN なので、git-svn で送ろうとしてもなんだかうまくいかず、とりあえず手動で(ローカルの別の場所にコピーして、svn で。つまり Git とは完全に切り離して)作業しました。

それからゆっくり見なおしてみました。

WordPress公式プラグインリポジトリに登録しているプラグインをGitHubで管理する」や「公式リポジトリのWordPressプラグインをGitHubでバージョン管理できる『wp-plugin-in-github』使ってみたよ」を見て、これは便利そうだと思ったのですが、tai さんと同じく readme と本体のバージョンが合わないエラーとか、

  • 手元で、勉強がてら git flow を導入していたので、そのままでは構成が合わない
  • 翻訳ファイルの作業は自前の Makefile と重複する

など、そのままでは使えませんでした。そこでその中身を個々にやるような形ですが、次のようにやってみました。参考にしたページは

です。

手順

出発点は

  • 既に公式リポジトリに何らかがある状態
  • 公式リポジトリの branches は使っていない
  • 手元では git-svn がインストールされている状態

という中途半端なところなので、どれほど意味があるのかわかりませんが、自分のメモとして。そのため、例とするプラグインは wp_mail to XMPP です。

公式リポジトリと連携

まず、trac で見るなどして、はじめと終わりのリビジョン番号を調べておきます。

それと、内容が

mako09 = Mako N <mako@pasero.net>
plugin-master = Mako N <mako@pasero.net>

というファイル(名前は何でもいいですが、ここではauthor.txt とします)を作っておきます。

次に、ローカルの何もない場所で、

git svn clone --no-minimize-url -s -A author.txt -r829275:829448 http://plugins.svn.wordpress.org/wp-mail2xmpp/

を行います。-r(はじめ):(終わり)を付けます。この -r ではじめと終わりを指定すれば膨大な時間がかかることもありません。-r(はじめ) だけでは、はじめのリビジョンは申請によって向こうで(plugin-masterに)場所だけ作ってもらったものなので、空っぽのディレクトリだけになります。

手元で作業していた git リポジトリで、このコマンドを実行してもうまくいきませんでした。これ自体はうまくいっているように見えるのですが、後段の git svn rebase が “Unable to determine upstream SVN information from working tree history” と言うのです。何もない場所でやるとうまくいきます。

git の設定

git config user.name などの設定を行います。git flow を使うため、

git flow init

も行います。

ブランチの作成

git checkout -b svn

で、svn という名前のブランチを作ります。

svn → 公式、master → gitHub で、develop は手元、という構成です。svn と master の違いは、今回の例では公式には置かないファイル(Makefile, LINGUAS)だけです。

git svn fetch
git svn rebase

で、同期させておきます。

ローカルから取り込み

既に作業していたローカルのリポジトリから

git checkout master
git remote add temp file:///...
git pull temp master
git checkout develop
git pull temp develop
git remote remove temp

で、取り込みます。

GitHub との連携

git checkout master
git remote add origin git@github.com:mako09/wp-mail2xmpp.git

として、

git pull origin master

で、同期させておきます。GitHub には何もなくてこれからという場合は、むしろ git push することになります。

以上で、GitHub とも公式リポジトリとも連携した git リポジトリが手元に出来ました。これまで作業してきた手元の git リポジトリは不要になります。

その先に作業してきた git リポジトリに、git-svn で svn リポジトリを連携させることができればよかったのですが、上述したようにうまくいきませんでした。このへんの仕組みはよく理解できていません。そのため、このようなとてもまわりくどい手順になってしまいました。

以後の作業

以後は、手元の git リポジトリで作業します。master が完成したら(git checkout master の状態)、GitHub に送ります。以下、まだその場面ではないので十分試していませんが、

git push           # GitHub に送られる

続いて、ブランチ svn に移って、svn に送ります。

git checkout svn
git merge master   # --squash をつけるか、merge ではなく個々のファイルを checkout のほうがいいかも
git svn fetch      # 念のため
git svn rebase
git svn dcommit    #公式リポジトリに送られる

git のタグは(ブランチ master で)

git tag 0.9

のようにします。これを GitHub に送るには

git push origin 0.9

です。

svn にタグをつけるのは(ブランチ svn で)

git svn tag 0.9

のようにします。メッセージは自動的に “Create tag 0.9” のようになります。このコマンドで公式側にタブができます。