Studio Drummer と Kontakt のマルチアウト設定

Komplete 7 から Komplete 9 にアップデートしました。 久々の Komplete 関連記事となりますが、初めて使うことになった Studio Drummer と Kontakt パラアウト (マルチアウト) 設定を取り上げます。

Komplete 9 へのアップデートの動機となったのは (某楽器店のポイントが 5,000円分ほどたまっていたというのもありましたが) この Studio Drummer と Session Strings です。 私はどちらかというと生ドラムの音が好きなので、あれこれドラム音源を使うよりもこの Studio Drummer だけ使う方が幸せになれそうな気がしたのです。

カブってるよ!

Kontakt に Studio Drummer をロードして触ってみて、まず面白いと感じたのは Bleed というカブリを再現するパラメータの存在です (ただし、スネアのみ)。 この値を上げるとスネアのチャンネルから微かにタムなどの音が聞こえてきます。 他のソフトでも備えている機能のようですが、カブらないように苦労していたはずがこんなことになっているのですね。

それとグルーブパターンがたっぷりあって、これをドラッグ&ドロップして DAW ソフトに取り込むことができるのも特徴的でした。 再生するときにシャッフル (ハネ具合) の調整ができるのですが、きちんとこのシャッフル設定が反映されたパターンが DAW 上で再生されるのです。

ランダム化の設定もあるのですが、こちらは DAW にドラッグ&ドロップしたパターンには反映されません。 こちらの値を調整したいのであれば Control Change (CC) で行います。 CC を使うには、ツマミの上で右クリックしてから CC ナンバーを覚えさせます。 ランダム化を使えばパターンを組み合わせて再生するだけでも人間っぽくなる、ということです。

やはり一番嬉しいのは生らしい音がすることですね。 気になる人は公式サイトでデモやチュートリアルビデオをチェックしてみましょう。

Kontakt のパラアウトの設定

さて、そのチュートリアルビデオでもさらっと紹介されていますが、Kontakt の出力をフルに生かしたパラアウト設定方法 (Cubase 編) を紹介します。 Studio Drummer 自体もミキサーとエフェクトを持っているのでそれを使っても良いのですが、Cubase のような DAW と組み合わせて使ったときは DAW ソフト側で音作りをしたくなる人もいると思います。 そんなときのためのセッティングです。

まず、Cubase 側は MIDI トラックと VST インストゥルメントチャンネルを組み合わせて使います。 インストゥルメントトラックではチャンネル数がステレオ 2ch までなので VST インストゥルメントのラックから Kontakt を呼び出すのです。

ところで、例えば VST インストゥルメントラックから「Kontakt 5 16out」を選択し、出力を確認すると以下のように表示されます。 初期状態ではこのようにステレオ× 5 で残りがモノチャンネルに設定されています。

Kontakt Output

実はこの Kontakt からの出力のステレオ/モノの組み合わせは変えることができます。 どうやるかというと Kontakt のミキサーで望むチャンネルを「Add Channels」で足していき、最後に「Save current section state as default for」を選ぶのです。 (ただし、元の設定を保管しておきたい場合は、操作の前にこの記事の最後を読んでバックアップを取っておきましょう)

では実際にやってみましょう。まず、Add Channels を使って以下の図のようにします。 チャンネル名はテキスト部分をクリックしてから変更できます。

Kontakt Mixer

その後「Save current output section state as default for」を選びます。 今回は Cubase の VST インストゥルメントラックから 16チャンネル仕様を選んだときのデフォルトとするので「VST Plugin (16 out)」を選択します。

Kontakt Output

すると VST インストゥルメントトラックから「Kontakt 5 16out」を選び直すと以下のような出力となります。 ステレオ× 4 + モノ× 8 となって Studio Drummer 仕様となりました。 あとは「全出力を有効化」すればパラアウトの設定完了です。

Kontakt Output

Studio Drummer の方は MIXER で INIT を選んで余分なエフェクトなどをオフにしておきましょう。

ここで紹介した設定はチュートリアルビデオを参考にしています。 チュートリアルビデオを埋め込んでおきますので、どうぞ。

なお、Kontakt のアウトプット設定に関して若干制限があるので説明しておきます。 この Kontakt からの出力設定は Cubase のプロジェクト単位に変えることはできません。 「VST Plugin (16 out)」を選んだときの共通設定となります。 設定ファイル自体は以下のフォルダにあります。(ただし Windows 7 で確認してます)

%USERPROFILE%\AppData\Local\Native Instruments\Kontakt 5\default\

「Save current section state as default for」を実行する前にこのフォルダにある *.cfg をバックアップしておきましょう。

いくつかの設定ファイルを用意して切り替えながら使うこともできなくはないですが、面倒ですね。 というわけで、当面は「Kontakt 5 16out」を Studio Drummer 専用の出力セッティングにして、それ以外のライブラリを選ぶときは「Kontakt 5」か「Kontakt 5 8out」を選ぶことにしました。

プロセッサーパワーに余裕がない環境でのミックス時は一旦マルチアウトした出力をオーディオ録音してそちらを加工すると幸せになれると思います。

EOS Digital でワイヤレスストロボ撮影

ちょっと (かなり?) 前にも書きましたが、最近の EOS とスピードライトであれば簡単にワイヤレスストロボ撮影ができます。 例えば昨日の記事の写真もワイヤレスストロボ撮影による作例です。 ただ、私の場合すぐに操作を忘れてしまうので、備忘録として設定をまとめておきます。 EOS 60D と 430EX II の組み合わせですが、恐らく他のモデルでもほぼ一緒の操作体系になっているのではないかと推測します。

スピードライト (430EX II) 側の設定

  1. 「ZOOM」ボタンを 2秒以上押します。
  2. チャンネル番号をボディ側と合わせます。 恐らく初期値のまま 1ch で使えると思いますが、必要に応じて「ZOOM」、「+」、「-」、「SET/SEL」ボタンを使って設定します。

430EX II はスレーブ機能しか持っていませんが、600EX-RT などではマスター機能も持つため、マスター/スレーブの選択が必要になると思います。

ボディ (EOS 60D) 側の設定

  1. 内蔵ストロボを上げます。
  2. メニューで「ストロボ制御」-「内蔵ストロボ機能設定」を選びます。(ここがいつもわからなくなって苦労します!)
  3. 発行モードを「E-TTL II」にします。
  4. ワイヤレス機能でスレーブの発光 flash を選びます。
  5. 必要に応じチャンネルを設定し、スレーブ側とチャンネル番号を合わせておきます。

あとはストロボの配置を考えてシャッターを切るだけです。 細かくやると内蔵ストロボも一緒に発光してそのときの光量比を設定したりもできますが、その辺はマニュアル参照ということで。

ちなみに最近ストロボ撮影時のボディの設定はマニュアル露出モードでやっています。

ヘッドホンアンプと Cubase の Control Room

きっかけは安価なヘッドホンアンプ付き雑誌が目に付いたことだったのですが、Cubase の Control Room 機能を使おうと思い立ちました。 自分で演奏する人はわかってくれると思いますが、ミックスのバランスを演奏のときだけ変えたくなることがあると思います。 そんなときに Control Room 機能を使えばメインミックスは残したままそれと独立してモニター音のバランスを設定することができるのです。 その分出力を複数用意しなければなりませんが、ヘッドホンアンプを追加すればヘッドホンを差し替えて使えると思ったのです。

またしても Behringer

結局雑誌を購入するのではなく、AMP800 というヘッドホンアンプを買ってしまいました。 先の記事に引き続きまたもや Behringer 製品です。 この AMP800 は 2系統 (A, B) のステレオ入力をもっています。 4つのヘッドフォン出力は A と B のどちらの音を聞くかそれぞれスイッチで選択することができます。

AMP800 and UA-101

HA400 という安価な製品もあるのですが、私は UA-101 という 10IN/10OUT のオーディオインターフェイスを持っているのでどうせなら入力を 2系統持っている方がよいと思い AMP800 を選びました。 UA-101 の OUT の方はエフェクトセンドぐらいしか使い道がなく、それすらも最近は使ってない状況だったのですが、これで有効活用できます。

AMP800 にゴム足はついていないので、重ねておくときは 100均で売ってたりする耐震マット (粘着マット) を使うとよいです。 写真にも写ってますね。

設定は結構簡単

さて Control Room 機能の設定ですが、思ったよりも簡単でした。 使用するためにはまず VST コネクションを設定します。

  1. VST コネクションのスタジオタブを表示し、「Control Room」を有効化します (電源ボタンアイコン)
  2. ヘッドホンモニター用出力として「キュー」を 2系統追加します。
  3. メイン出力として「モニター」を 1系統追加します。通常の出力 (最初からある「Stereo Out」) は使いません。
  4. それぞれオーディオインターフェイスの適切なポートを設定します。

私の場合は以下の図の様になりました。

VST Connection

1+2 はこれまでと同様メインミックスの出力ですが、新たに 5+6 と 7+8 を AMP800 への出力としたのです。

使ってみよう

まずは MixConsole 画面で以下の図のように「キューセンド」ラック (左上) と「Control Room」ミキサー (右) を表示します。 Control Room ミキサーではそれぞれの出力に何を出すか選べますが、下の図ではキュー1、キュー2 はそれぞれのキュー出力とクリック音を聞くことができます (右上部)。 メイン出力は図ではメインミックスが選択されていますが、キュー1、キュー2 の音に切り替えることもできます (右下部)。

MixConsole

とここまで来て思ったのですが、VST コネクションの設定でキュー出力に物理ポートをアサインしなくてもこの Mix/キュー1/キュー2 ボタンで切り替えて使えば十分 (=ヘッドホンアンプ買わなくても良かった) なような気がしてきました。 もう買っちゃったので深く考えないことにします。

キューミックスは左上部にある CUES と表示されている部分のスライダーで調整しますが、下図のようにコンテキスト (右クリック) メニューを選ぶことでメインミックスのバランスを使って初期化することもできます。

Cue Send Menu

公式のチュートリアル動画もあるので参考にしてみてください。 英語が苦手でも日本語字幕を表示することができますよ!

Cubase iC Pro を使っている方は以下のように設定画面で「Switch View」の設定をモニターする Cue Mix にすることで iPad を使ってモニターバランスを調整することができます。

Cubase iC Pro

Control Room 機能は使ってみるとなかなか便利です。

Behringer の安いミキサー、ちゃんとしてるんですけど…

最近 WordPress 関連ブログっぽくなっていますが、そういうわけではありません。 音楽機材もいろいろ買ったりしてるので紹介していきます。 今回は Behringer XENYX 802 というミキサーです。 今まで Boss の BX-16 というミキサーを使っていましたが、もう少しコンパクトなものが欲しくなったのです。

Behringer 安っ!

この Behringer XENYX 802 は 8ch ミキサーです。 最近は円安なので価格が上昇しているようですが、私が昨年買ったときは 4千円弱でした。 ソフトウェアプラグイン関連のバーゲンセールを良く見かけましたが、ソフトだけでなくハードウェアも気が付いたらこんなに安くなっていたのですね…。

XENYX 802
XENYX 802

安くてもちゃんとしてるよ

簡単に仕様を紹介します。

  • 1ch、2ch はフォーンプラグだけでなく XLR コネクター (ファントム電源付き!) にも対応
  • 3ch/4ch と 5ch/6ch はそれぞれステレオ入力として扱われます
  • 1 ~ 6ch は EQ 装備
  • 1系統のエフェクト SEND/RETURN あり。この RETURN を入れて計 8ch なので 8ch ミキサーと謳われています
  • その他に CD 等再生用として外部入力ステレオ 1系統あり
  • 出力はメイン、Control Room、CD/tape の計ステレオ 3つ

何というか「この値段でこれだけの機能が手に入るのかぁ!」といった感じです。 ノイズなどが気になることもないですし、強いて言えば LED の電源ランプが妙に明るいのが気になる程度です。 それと私はパワーサプライを使っているので気にしないのですが、電源スイッチはありません。

しっかしモデルがたくさんあるなあ

「では、ちょっと Behringer のミキサーを買ってみるか」と思ったときにハードルになるのが種類の多さです。 私の場合は以下のように考え XENYX 802 に落ち着きました。

  • USB インターフェイス付き (型番末尾 USB) やエフェクト付き (型番末尾 FX) のモデルもありますが、それらの機能は不要
  • XENYX 502 だと入力が足りず、最後は XENYX 1002 と 802 で悩みましたが、8ch あれば足りるので EQ 機能を優先しました

細かくチェックしたい人はメーカーサイトからマニュアルをダウンロードすると良いと思います。 少なくとも XENYX 802 や 1002 については日本語版マニュアルも提供されています。

Amazon のレビューでは発熱やぐらつきというのを見かけたこともありますが、少なくとも私のものは気になりません。 とても満足して使っております。

設定だけで Jetpack の二重 OGP 出力問題を解決するには

連休中に iPad に WordPress アプリを入れて、ついでにサイトに Jetpack プラグインを導入しました。 WordPress アプリに Jetpack プラグインを組み合わせることで統計情報が参照可能になります。 このとき、WordPress.com のアカウントが必要です。

さて、この Jetpack プラグインですが、他に OGP メタタグを出力するプラグインと組み合わせると二重に OGP メタタグを出力してしまうという記事をみかけました。 私も Facebook プラグインを使っているので慌てて調べると確かに二重出力しています。 そこで Jetpack の設定でこれを抑止できないかと管理画面を確認したのですが、特に設定はないようです。

よその記事をそのままうのみに出来ない (fb_xd_fragment の件もありました!) ので、コードを覗くと jetpack.php に以下のような関数がありました。 Jetpack のバージョンは 2.2.5 です。

    public function check_open_graph() {
        if ( in_array( 'publicize', Jetpack::get_active_modules() ) || in_array( 'sharedaddy', Jetpack::get_active_modules() ) )
            add_filter( 'jetpack_enable_open_graph', '__return_true', 0 );

        $active_plugins = get_option( 'active_plugins', array() );

        $conflicting_plugins = array(
            'facebook/facebook.php',                                                // Official Facebook plugin
            'wordpress-seo/wp-seo.php',                                             // WordPress SEO by Yoast
            'add-link-to-facebook/add-link-to-facebook.php',                        // Add Link to Facebook
            'facebook-awd/AWD_facebook.php',                                        // Facebook AWD All in one
            'header-footer/plugin.php',                                             // Header and Footer
            'nextgen-facebook/nextgen-facebook.php',                                // NextGEN Facebook OG
            'seo-facebook-comments/seofacebook.php',                                // SEO Facebook Comments
            'seo-ultimate/seo-ultimate.php',                                        // SEO Ultimate
            'sexybookmarks/sexy-bookmarks.php',                                     // Shareaholic
            'shareaholic/sexy-bookmarks.php',                                       // Shareaholic
            'social-discussions/social-discussions.php',                            // Social Discussions
            'social-networks-auto-poster-facebook-twitter-g/NextScripts_SNAP.php',  // NextScripts SNAP
            'wordbooker/wordbooker.php',                                            // Wordbooker
            'socialize/socialize.php',                                              // Socialize
            'simple-facebook-connect/sfc.php',                                      // Simple Facebook Connect
            'social-sharing-toolkit/social_sharing_toolkit.php',                    // Social Sharing Toolkit
            'wp-facebook-open-graph-protocol/wp-facebook-ogp.php',                  // WP Facebook Open Graph protocol
            'opengraph/opengraph.php',                                              // Open Graph
            'sharepress/sharepress.php',                                            // SharePress
        );

        foreach ( $conflicting_plugins as $plugin ) {
            if ( in_array( $plugin, $active_plugins ) ) {
                add_filter( 'jetpack_enable_open_graph', '__return_false', 99 );
                break;
            }
        }

        if ( apply_filters( 'jetpack_enable_open_graph', false ) )
            require_once dirname( __FILE__ ) . '/functions.opengraph.php';
    }

一瞬、「ここに挙げられているプラグインがアクティブならば、ちゃんと OGP タグ出力は抑止されるのでは?」と思ったのですが、よく見るとマルチサイトでネットワークレベルで他のプラグインをアクティベートしたときはこのチェックから漏れてしまいます。

従って (現行バージョンの Jetpack では) この二重出力問題はマルチサイト環境のみで生じます。 ワークアラウンドは、ネットワークレベルで他のプラグインをアクティブにするのはやめて個別のサイトでアクティブにすることです。 実際に私も Facebook プラグインをこの方法でアクティベートすると問題は解消されました。 ちなみに OGP 出力については fb_xd_fragment の件もあるので Facebook プラグインが私のお勧めです。

参考までに書くと、ネットワークレベルでアクティベートされたプラグインは以下のオプションの内容を参照することで確認できます。

get_site_option( 'active_sitewide_plugins') 

パッチをつくって送ってみようかな…。

WordPress での CSRF 対策

nonce ってナンスか?

春だというのに寒いですねぇw

それはさておき、みなさんは nonce という言葉を聞いたことがあるでしょうか? 日本ではあまり馴染みがないように思いますが、コンピュータ (というか暗号) の世界では一度だけ使われる使い捨てのユニークな数 (英語版 Wikipedia の説明) のことを言います。

WordPress には CSRF 対策として nonce という機能が実装されています。 wp_create_nonce で nonce を生成し、wp_verify_nonce でこれを検証することができます。 リンク先の Codex にも例がありますが、wp_create_nonce で生成した nonce を HTML のフォームに埋め込み、サーバーで受けたその値を wp_verify_nonce で検証する、というような使い方ができます。

ただし、注意点が一つあります。 WordPress の nonce は本来の意味の nonce とは異なり、ワンタイムの使い捨てというわけではありません。 12時間ごとに変更され、検証に際しては 24時間有効です。 もっとも CSRF 対策として考えたとき、ワンタイムである必要はありません (例えば高木先生の記事)。 推測されないようにきちんとランダムであれば、そして有効期間が適切であれば CSRF 対策として十分です。

wp_verify_nonce は、現在の nonce の値と同じならば 1、1つ前の nonce と同じならば 2を返します。 つまりデフォルトでは 0-12時間で 1、12-24時間で 2が返されることになります (時間の数え方は後述)。 nonce が一致しなければ wp_verify_nonce は 0を返すので、通常はこれをそのまま真偽判定条件式として使用します。

有効期間の短縮

その有効期間ですが、デフォルトの 24時間を短縮したいときは add_filter することで変えられます。

add_filter( 'nonce_life', 'my_nonce_life' );

function my_nonce_life() {
    return 3600; /* 1 hour */
}

このテクニックはテスト時にも使えそうですね。

なお、この有効期間は wp_create_nonce を呼んだ時からカウントダウンが始まるわけではなく、time() の値を使って周期的に変えているだけなので、ちょうど変わり目 (GMT の 0時とか 12時とか) にあたると短時間で値が変化することになります。 それでも先述の通り一つ前の nonce まで有効と判定されるので通常は問題ないでしょう。

nonce の素

さて、この nonce ですが、以下の情報を元に生成されます。

  1. ユーザー ID
  2. 時刻 (といっても 12時間単位)
  3. wp_create_nonce に渡された引数 $action
  4. サイト毎に持っている秘密キーと Salt

これらが同一であれば同じ値になります。 ここで開発者にとって気になるのは 4. の秘密キーと Salt ではないでしょうか? そして自分の wp-config.php に以下のような記述を見つけて焦るわけです。

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

これを見ると「げっ、ウチのサイト、ヤバい??!」と思ってしまいますよね。

でも、安心してください。 実はこのような wp-config.php となっている場合は、自動的に秘密キーと Salt を生成してデータベースに保存し、それを使ってくれます。 このままでも「put your unique phrase here」をキーとして使うことにはなりません。

となると wp-config.php を書き換えたくなるのは定期的にキーを変更したい場合ぐらいでしょうか。 生成には https://api.wordpress.org/secret-key/1.1/salt/ を使いましょう。

学習のために

興味のある人は wp-include/pluggable.php の nonce 関連関数を読んでみましょう。

私が WordPress の nonce について知ったのは「Professional WordPress Plugin Development」という書籍によってです。 この書籍は WordPress のプラグイン開発に必要な情報が一通りまとまっており、分量も重くないのでお勧めです。 英語も難しくないですし。

英語ついでですが、こちらの WordPress の nonce についての記事も参考情報として挙げておきます。


2013.4.17 追記

nonce の変わり目の際の動作について訂正。(一つ前の値も有効なので変化してもすぐに verify エラーになるわけではない)

WordPress 3.6 と Thin Out Revisions

WordPress 3.6 のβ1がリリースされました。 今回はそれをとっかかりに近況をまとめる感じで書いてみます。

WordPress 3.6 のリビジョン画面

WordPress 3.6 ではリビジョン画面が刷新されます。 下のスクリーンショットを見てください! これまでのリビジョン選択用テーブルの代わりに上部にスライダーが用意され、Ajax でリビジョン選択を行なえるようになります。

WP3.6 revision screen

そして、この画面のプログラミングには Underscore.jsBackbone.js が使用されています。 私は JavaScript 界隈に詳しいわけではないのでアレですが、どちらも人気のあるライブラリのようです。 で、私は Thin Out Revision というリビジョン画面に機能を追加するためのプラグインをリリースしているのですが、jQuery で画面に機能追加するような動作なのでそのままでは WordPress 3.6 で動かないわけです。 「ああ、困ったなあ」と思ったのがβ1 前のα版を触っていた 3月下旬のことでした。

Backbone.js

Backbone.js は MVC フレームワークです。 WordPress 3.6 のリビジョン画面も Model と View を使ってプログラミングしています。 そうすると画面ロード時に jQuery でちょっといじる程度では対応できないのです。 もしそれをやったとしても、画面が動的なのでボタンを押したりスライダーを使うとすぐに効果が消えてしまいます。 ああ、困った。

そこで Backbone.js を学習せねば、ということになるのですが、結局本家マニュアルと WordPress の wp-admin/revision.php と wp-admin/js/revisions.js が一番の材料でした。 その他に役に立ったのは以下のチュートリアルです。

あと、Waviaei さんの記事で紹介されている WordPress 3.5 関連動画で Underscore.js と Backbon.js が結構な時間を使って紹介されていて何ができるかを知るのには良いと思います。 結構早口な英語ですが。 ちなみに私はこの動画を見て JavaScript コンソールを使用するために Chrome をインストールしました。 まだそんなレベルです。

Prototypal inheritance

そして、もろもろ考慮した結果「リビジョン画面を拡張するにはそれ用の View を継承して手を入れるしかないでしょ」との結論に至りました。 現在は以下のようなコードを書いていて、何とか Thin Out Revisions を WordPress 3.6 に対応させることができそうです。

  TOR = {
    View: wp.revisions.view.Diff.extend({
      events: {},

      initialize: function() {
        _.bindAll(this, 'render');
        this.events = _.extend({'click #tor-thin-out': 'thinOut'},
                                wp.revisions.view.Diff.prototype.events);
      },

継承についてやってみてよくわからなかったのはやはり prototype 関連です。 JavaScript はクラスベースではなくプロトタイプベースの言語ということで、ここをしっかり理解せねばなりません。 これについては「JavaScript: The Good Parts」という本を読むのが良いと思います。 (私は自分の記事に従い洋書 Kindle 版を購入しましたが)

この部分についてはネット上にもきちんとまとめられた記事があります。私には今のところ __proto__ は必要なさそうですが。

その他

あと、関連する JavaScript ファイルは非同期に読み込まれているようなので SetTimeout (あるいは _.delay) で実行を遅らせねばなりません。 このあたりは色々な方が書いているのを参考にさせてもらいました。

それと WordPress 3.5 と 3.6 で動作を変えなければなりませんが、これについては PHP の方でクラスを階層化しました。 カレントバージョン用のベースクラスに対し 3.5 用サブクラスで必要な関数をオーバーライドするようにしています。

というわけで色々苦労していますが、JavaScript の経験値を積んでおり、プラグインのバージョンアップを WordPress 3.6 のリリースに間に合わせるのは何とかなりそうな気がしています。 後はもうちょっと利用者が増えたらなあ、という感じですね。

WordPress プラグインリポジトリの動作

ちょっとニッチな話題ですが (いつものことだ!)、プラグインを作って WordPress.org のリポジトリへプラグインをアップロードするときの Stable Tag 関連の細かい動作についてまとめておきます。 英文ドキュメントだけではわかりにくい気がするので。

trunk/readme.txt は原則 Stable Tag だけ参照される

プラグインのページからダウンロードできる安定バージョンを指定するには trunk/readme.txt の Stable Tag を使用します。 ここで注意が必要なのは、プラグインページの表示は trunk/readme.txt ではなく、Stable Tag で指定したバージョンの tags/安定バージョン/readme.txt の内容を元に表示されることです。 つまり、例えばプラグインページで typo があったりしたときに、それを訂正するにはわざわざそれ用の新バージョンを作って Stable Tag を更新しなければならないということです。

Stable Tag で指定したバージョンがなかったら?

例えば trunk の下のファイルを更新して開発を進めたところ、いい感じになったのでリリースしようと考え trunk/readme.txt の Stable Tag を 1.2 へ更新したとします。 しかし、タグ付けし忘れて、対応する tags/1.2 のディレクトリを作成し忘れていたらどうなってしまうのでしょう?

この場合は、プラグインページ上のダウンロードリンクの表示は「Download Version 1.2」となり、ダウンロードできるパッケージは trunk の内容を固めた Zip ファイルとなるのです。 問題ないですね。

であれば、プラグインページが枯れて (typo 等がなくなって) 安定するまでは trunk をダウンロードしてもらうというのも一つの手かなと思いました。 ともかく、Stable Tag 更新 → タグ付けの間に時間が空いても問題はないということです。

Stable Tag 更新とタグ付けは順番に実行

一度、trunk の更新 (含 Stable Tag 更新) と対応するバージョンのタグ付けを同時に check in したところ、「Download Version *」の表示が変化しないことがありました。 (ダウンロードできるパッケージは変化したように記憶しています)

というわけで Develop Center で紹介されている手順通り trunk (Stable Tag) の更新とタグ付けは別々に check in した方が良いようです。

ああ、何てニッチな話題なんだろう!

Standard Widget Extensions 1.0

拙作の Standard Widget Extensions がバージョンアップして 1.0 となりました。 このサイトのサイドバーの動きはこのプラグインを使用しています。 今回のバージョンアップでは派手な機能追加はないもののそれなりに変化しています。 私の書いた怪しい英語を英語の苦手な平均的日本人が読むと、きっと伝わらないような気がするので、要点を書いておくことにします。

主な変更点は以下の通りです。

  1. サイドバーに複数のウィジェットエリアをもつテーマに対応しました。これにより、スクロール動作に関してはサイドバー全体の大きさで計算させながらも一部のウィジェットエリアでのみアコーディオン動作をさせることができます。
  2. 設定された ID やクラスを元に見出しアイコン用の style タグが動的に生成されるようなりました。 これで非標準テーマでも使いやすくなったと思います。
  3. 管理画面が日本語表示されるようになりました。

1. に関連して新たに「次の ID を持つウィジェットエリアのみで有効」というオプションが増えているのでこれについて説明します。 このオプションは複数のウィジェットエリアを持つサイドバーに対し、アコーディオン動作をするウィジェットエリアを指定するときにに使います。 Twenty Twelve や Twenty Eleven のように 1つのウィジェットエリアがそのままサイドバーになっているテーマではこのオプションは空欄にしておき、「サイドバーの ID」にそのウィジェットエリアの ID を入れてください。

2. ですが、もし既に非標準テーマ + Standard Widget Extensions という組み合わせでお使いになっていて 1.0 へバージョンアップする場合は生成される style タグが余計なことをすることになるので、「デフォルト CSS を生成する」を無効にしてください。

このサイトのサイドバーと同じような動作をさせたいときは是非使ってみてください。

日本語で書くのは気楽だ…。

WordPress のリビジョンの作成者表示がおかしい件

すぐ忘れちゃうのでメモ書きしておきます。 Ticket #16215 の件。 現行バージョン 3.5.1 でおかしくて次期バージョン 3.6 で修正される予定。

現象

簡単に再現できます。

  1. 最初にユーザー admin で記事を作って投稿する
  2. 次にユーザー blogger323 でその記事を更新する
  3. リビジョン画面に行って作者欄を見る

こうなっているはずです。

  • 第 3版: 作者 = admin、内容 = blogger323 が更新した内容
  • 第 2版: 作者 = blogger323、内容 = admin の投稿した最初の内容
  • 第 1版: 作者 = admin、内容 = 空 (自動生成される初版!)

どうしてこうなった?状態なのですが、これは今のリビジョン操作が、更新時に現行の内容をコピーしてリビジョン用レコードを新たに作成するようになっているからです。 つまり、blogger323 が admin の内容をコピーしたリビジョン用レコード (= 第 2版) を作成するので、第 2版の作者は blogger323 としてデータベースに記録されます。 投稿として表示されるレコードには更新がかけられるのですが、作者フィールドは更新対象とならず最初に作成した admin のまま変わらないのです。

3.6 に向けて

日々更新されていくので、どのような対策をしようとしているか興味のある方は Ticket #16215 を参照してみてください。 私は自分のプラグインの処理に関係するかも知れないので気にしていますが、とりあえず 3/13 予定のβ1 待ちです。