Movable Type 6 にメッセージセンターという、各種アラート、メッセージ表示を行うための機能がついています。メッセージセンター機能についてのページに外観からコールバックを使った表示方法まですべてが集約されています。あらこれだけ？と思いますが、まあ確かにこれだけ。でも、メッセージセンターは CMS からのプッシュ通知であり、様々な面で CMS の利便性を高める可能性でもあります。最近記事書いてないけど大丈夫？とか、もうすぐエイプリルフールだけどネタの仕込みは進んでる？今日の 11:00 にこの記事が日時指定公開だからね、といったブロガー向けな内容から、システム管理者からのメンテナンス告知とか、特定ユーザに向けたメッセージ、TODO 機能なんかにも使えそうですね。

仕組み

メッセージセンターは「サイト情報」や「ようこそ、Loupeへ」と同じくメインカラムに表示されるダッシュボードウィジェットですが、テンプレートの書き方によりメッセージがある場合だけ表示されるようになっていることと、can_close="0" であるために非表示化ができないため、ユーザのコントロール外で強制的に表示される形になっています。

使われているテンプレートは /path/to/mt/tmpl/cms/widget/notification_dashboard.tmpl で、特別なハンドラはありません。テンプレートに記述された内容のとおり、テンプレート変数 loop_notification_dashboard にメッセージの情報をセットしておけば表示されます。メッセージセンターの機能紹介ページではコールバックを使った実装方法が紹介されていますが、notification_dashboard.tmpl を alt-tmpl し、テンプレートタグを使って変数に突っ込む、といったこともできますね。

コールバックでメッセージをセットする

公式の紹介ページに過不足ないソースコードのサンプルが記載されていて、書かれている通りです。config.yaml にコールバック set_notification_dashboard を定義します。

callbacks:
    set_notification_dashboard: $messagecenter::MessageCenter::Callbacks::_cb_set_notification_dashboard

そして、ハンドラを定義します。コールバックですから最初の引数は MT::Callback、二番目にメッセージの情報を格納した配列リファレンスが渡されます。メッセージのデータを作って、$loop_notification_dashboard に push することでメッセージが追加され、配列の順に表示されます。ダッシュボード以外の画面にも表示される通知「メッセージがN件あります。」の件数も配列数から自動的にカウントしてくれます。

sub _cb_set_notification_dashboard {
    my ( $cb, $loop_notification_dashboard ) = @_;

$loop_notification_dashboard に push するデータの形は公式の機能紹介ページを見ればわかりますが、level, text, detail をキーとしたハッシュリファレンスです。level はアイコンを表示する class になるので指定できるものが決まっており、指定しない場合は warning になります。アイコンを表示したくない場合は foo とか未定義の class をすればよいでしょう。text に指定するテキストはウィジェット内にデフォルトで表示され、クリックすると detail に指定するテキストが表示されます。detail には html タグを使うこともできるようです。このページおかしいんじゃないの、と言って編集画面へのリンクを張っておくこともできますね。

    my @notifications = (
        {
            level  => 'foo',
            text   => $plugin->translate( 'No icon' ),
            detail => '<a href="http://example.com/">' . $plugin->translate( 'Fooooooo!' ) . '</a>',
        },
    );
    push( @$loop_notification_dashboard, @notifications );

$app->user を使えば、ログインユーザ情報を使ってメッセージを表示することもできます。ログインしているユーザに対して「もっと仕事しろ」と通知する場合は以下のようになりますね。気軽に声をかけるフリをしつつ、詳細を見ると恐怖のメッセージが表示されるようにするには以下のように指定します。

    my $app = MT->instance();
    my @notifications = (
        {
            level  => 'error',
            text   => $plugin->translate( 'Hi, [_1]', MT::Util::encode_html( $app->user->nickname ) ),
            detail => $plugin->translate( 'Work harder.' ),
        },
    );
    push( @$loop_notification_dashboard, @notifications );

なお、コールバック set_notification_dashboard は戻り値に応じた Movable Type 側の処理はなく、die してもシステムログに残るだけで画面上の処理は進行します。

その他

メッセージセンターにメッセージを表示するときに使うコールバック set_notification_dashboard は、Listing Framework の __mode=filtered_list を含め、全てのユーザの全ての画面でコールされます(__mode=filtered_list では不要な気もしますが)。なるべく軽い処理にしておくほうがよいでしょうから、あくまでもメッセージセンターで表示する内容は概略に留めるのがよいでしょう。

個人的には、現在は単純に配列の順番に表示されるので、level => 'error' が上とか、もしくは priority を指定することで意図して上に表示させるなどの機能があってもいいんじゃないかなと思っていますが、おそらく今のところはそうたくさんの項目が表示される前提の機能ではない印象です。

メッセージセンターに関する所感

Data API が注目されがちな Movable Type 6 は全体的にデベロッパー向けの機能が強化されている印象を受けますが(もちろんそういう面も多分にあるのだと思いますが)、ユーザー体験の向上につなげやすそうなメッセージセンターや Chart API もいいですよね。

なお、今回、メッセージセンター機能について調べるのに使ったプラグインを GitHub に公開しています。

定期的に再構築を回す、という手段は、例えばランキングを反映したいとか RSS から取り込んで表示したいといったような積極的な目的から、何かしらの問題を回避するための消極的な目的まで含め、比較的便利なソリューションのひとつです。

Movable Type 6 では、Data API によって再構築を行う手段が提供されています。覚えておけば余計なプラグインを入れる必要もありませんね。

リクエストの形式

端的には以下のような形式でリクエストを送ります。MT::App::DataAPI::core_endpoints でハンドラを確認すると、「/path/to/mt/lib/MT/DataAPI/Endpoint/Publish.pm」の MT::DataAPI::Endpoint::Publish::entries が受け手の処理になるようですね。

ここでは特に触れませんが、ヘッダ情報に認証のための accessToken を含める必要があります。

http://example.com/mt/mt-data-api.cgi/v1/publish/entries?ids=1,2,3,4,5,6,7,8,9,10

パラメータ ids には再構築したいエントリー ID をカンマ区切りで指定します。再構築させるエントリーが決まっていればそれを指定しましょう。そうでない場合は事前にエントリーのリストを取得するリクエストを送り、ID を取り出して連結したものを指定しましょう。なお、指定する ID はブログ記事でもウェブページのものでもかまいません。

この ids パラメータは必須なので、指定しないと何もしてくれません。ただ、Movable Type は前後のエントリーも合わせて再構築するので、厳密にはすべてのエントリーの ID を付与する必要があるわけではないといえばないのですが、とはいえ間引く方が手間がかかるので、全部指定してしまう方が楽でしょう。また、エントリーの再構築に合わせてインデックステンプレートも再構築されます。このあたりの動きは Data API でなくとも同じですね。特定のインデックステンプレートだけを再構築するためのエンドポイントはないようですが、同じブログのどれかひとつのエントリーを再構築させておくことでカバーできそうです。

戻り値

指定した ID のエントリー全ての再構築が終わったか、そうでないかで戻り値が異なります。再構築が終わった場合は以下です。

$VAR1 = {
          'status' => 'Complete',
          'restIds' => '',
          'startTime' => '2013-08-10T01:13:55+09:00'
        };

再構築が終わっていない場合は以下のようになります。

$VAR1 = {
          'status' => 'Rebuilding',
          'restIds' => '6,7,8,9,10',
          'startTime' => '2013-08-10T01:13:55+09:00'
        };

このとき、レスポンスヘッダには「X-MT-Next-Phase-URL」という情報が含まれています。Complete になるまで「X-MT-Next-Phase-URL」にアクセスし、再構築を繰り返します。Perl でやるなら以下のような感じです。

&rebuilding( '/publish/entries?ids=1,2,3,4,5,6,7,8,9,10' );

sub rebuilding {
    my ( $path ) = @_;
    my $endpoint = $api_url . $path;
    my $request = HTTP::Request->new( 'GET', $endpoint );
    $request->header( 'X-MT-Authorization' => "MTAuth accessToken=$accessToken" );
    my $ua = MT->new_ua;
    my $res = $ua->request( $request );
    my $content = MT::Util::from_json( $res->content );
    print Dumper( $content );
    if ( my $next_url = $res->header( 'X-MT-Next-Phase-URL' ) ) {
        &rebuilding( $next_url );
    }
}

なお、MT::DataAPI::Endpoint::Publish::entries を見ると、再構築処理は MT::App::CMS::rebuild_these に渡されていることがわかります。再構築処理実行前のコールバック pre_build が実行されますし、環境変数 EntriesPerRebuild の値によって一回あたりの再構築件数を制御することもできます。

たとえば、ID が 1 のブログについて、デフォルトである 10 件ごとにエントリーを取得しつつ再構築を回すのであれば、以下のように行うことができます。もちろんエントリー取得の際の limit を増やして一回で取得してしまってもよいでしょう。

my @rebuit_ids = ();
rebuild_all_entries();

sub rebuild_all_entries {
    my ( $offset ) = @_;
    $offset ||= 0;
    my $endpoint = $api_url . "/sites/$blog_id/entries?fields=id,title&offset=$offset"; # specific fields
    my $request = HTTP::Request->new( 'GET', $endpoint );
    $request->header( 'X-MT-Authorization' => "MTAuth accessToken=$accessToken" );
    my $ua = MT->new_ua;
    my $res = $ua->request( $request );
    unless ( $res->is_success ) {
        if ( $res->code == 500 ) {
            my $content = MT::Util::from_json( $res->content );
            my $message = $content->{ error }->{ message };
            $message =~ s/\\x{([0-9a-z]+)}/chr(hex($1))/ge;
            die $message; # invalid request, and so on...
        } else {
            die $res->as_string;
        }
    }
    my $content = MT::Util::from_json( $res->content );
    my $total_results = $content->{ totalResults };
    my $items = $content->{ items } || [];
    my @entry_ids = map { $_->{ id } } @$items;
    push( @rebuit_ids, @entry_ids );

    print "rebuit num: " . scalar @rebuit_ids . "\n";
    print "total_results: " . $total_results . "\n";
    &rebuilding( '/publish/entries?ids=' . join( ',', @entry_ids ) );
    
    unless ( $total_results == scalar @rebuit_ids ) {
        &rebuild_all_entries( $offset + 10 );
    }
}

sub rebuilding {
    my ( $path ) = @_;
    my $endpoint = $api_url . $path;
    my $request = HTTP::Request->new( 'GET', $endpoint );
    $request->header( 'X-MT-Authorization' => "MTAuth accessToken=$accessToken" );
    my $ua = MT->new_ua;
    my $res = $ua->request( $request );
    my $content = MT::Util::from_json( $res->content );
    print Dumper( $content );
    if ( my $next_url = $res->header( 'X-MT-Next-Phase-URL' ) ) {
        &rebuilding( $next_url );
    }
}

Movable Type 6 に実装される Data API を試してみた人もいると思います。発表前に触れる機会をいただいていたにも関わらずインストールする時間すら取れない有様だったので、少しでも触れておくことと、まだドキュメントは親切と言える内容でもなさそうなので、多少なりとも自分と同じようなポジションの方々の役に立てればと...あと、僕のこと忘れ去られないようにと...

概要

まず、Data API においてリクエストを受け付けてくれる CGI は(デフォルトでは)mt-data-api.cgi です。処理の実体は MT::App::DataAPI で、/path/to/mt/lib/MT/App/DataAPI.pm がこれにあたります。

MT::App::DataAPI は MT::App を継承したアプリケーションで、その点は mt-comments.cgi や mt-search.cgi はもちろん mt.cgi とも変わることはありません。なので、以下のようなコールバックは mt-data-api.cgi にも実行されます。

• MT::App::DataAPI::init_request
• MT::App::DataAPI::init_app
• MT::App::DataAPI::pre_run
• MT::App::DataAPI::post_run
• MT::App::DataAPI::take_down

プラグインの registry に登録するときは「MT::App::DataAPI::」を省略することもできますが、その場合は mt-data-api.cgi だけでなく、mt.cgi や mt-comments.cgi でも動作します。

この他に、mt-data-api.cgi に特有のものとして、以下のコールバックも実行されます。

• pre_run_data_api(MT::App::DataAPI::pre_run の後)
• post_run_data_api(MT::App::DataAPI::pre_run の前)

mt-data-api.cgi については公式に各エンドポイントとその説明が上がっています。比較的ベーシックな、API に慣れた人には扱いやすい形式だと思います。エンドポイントについては MT::App::DataAPI::core_endpoints にデフォルトのエンドポイントの指定があります。対応するハンドラもここを見ればわかります。

リクエストの仕方についてはすでに様々な方が言及されていると思うので簡略化しますが、たとえば、ID が 1 のブログに記事を新規に作成する場合、このページのように、「https://example.com/mt/mt-data-api.cgi/v1/sites/1/entries」に POST します。Perl でやるなら以下のような感じです。
※ $accessToken は、認証によって得られるレスポンスの「accessToken」です

my $endpoint = $api_url . "/sites/1/entries";
my $params = {
    'entry' => MT::Util::to_json( { title => 'Hello by DataAPI: ' . MT::Util::log_time(),
                                    body => 'This is test',
                                    status => 'Draft',
                                  },
                                ),
};
my $request = HTTP::Request->new( 'POST', $endpoint );
$request->header( 'X-MT-Authorization' => "MTAuth accessToken=$accessToken" );
$request->content( join( '&', map { $_ . '=' . $params->{ $_ } } keys %$params ) );
my $ua = MT->new_ua;
my $res = $ua->request( $request );
unless ( $res->is_success ) {
    if ( $res->code == 500 ) {
        my $content = MT::Util::from_json( $res->content );
        my $message = $content->{ error }->{ message };
        $message =~ s/\\x{([0-9a-z]+)}/chr(hex($1))/ge;
        die $message;
    } else {
        die $res->as_string;
    }
}
my $content = MT::Util::from_json( $res->content );

公式ドキュメントにはステータスコード 500 は載っていませんが、たとえば送信したパラメータが正しくない場合等に「不正な要求です」という応答が返るようです。そういうケースへの対応の方が時間を要することが多いので、上記には参考までにエラーメッセージの取り出し方の記述を含めました。

上記では最低限のカラムしかデータを入れていません。カスタムフィールドや、プラグインによって拡張したカラムについては以下のようにします。

なお、返されるオブジェクトの情報について、以下のように fields パラメータで指定することにより、必要なフィールドのみに絞ることができます。この点は各エンドポイントに共通のようです。

/sites/$blog_id/entries?fields=id,title
/sites/$blog_id/entries/$entry_id?fields=id,title

カスタムフィールドを更新する場合

以下のように、customFields の指定を追加します。これは、/path/to/mt/addons/Commercial.pack/lib/CustomFields/DataAPI.pm の CustomFields::DataAPI::fields に記述があるのですが、より端的にはカスタムフィールドを作成した後で上記を実行すると得られる返却値の形を見る方が早いでしょう。

my $params = {
    'entry' => MT::Util::to_json( { title => 'Hello by DataAPI: ' . MT::Util::log_time(),
                                    body => 'This is test',
                                    status => 'Draft',
                                    customFields => [
                                        {
                                          basename => 'text',
                                          value => 'teeeeeeeeeeeeext',
                                        }
                                    ],
                                  },
                                ),
};

プラグインによって拡張したカラムを更新したい場合

こちらはカスタムフィールドと同じというわけにはいきません。以下では、「foo」カラムを追加し、それを mt-data-api.cgi 経由で更新できるようにする例です。

まず、config.yaml に以下のように記述します。

object_types:
    entry:
        foo: string(255)
applications:
    data_api:
        resources:
            entry:
                fields:
                    - name: foo
                      from_object_default: bar
                updatable_fields:
                    - foo

object_types はこれまでの Movable Type でも必要だったカラム拡張に関する指定です。合わせて schema_version を指定することでアップグレードが行われ、mt_entry にカラム foo が追加されます。

applications 以下の指定が今回必要になる指定です。entry に対して「fields」と「updatable_fields」を指定しています。「fields」はレスポンスに含めるために、「updatable_fields」は mt-data-api.cgi 経由で更新できるようにするための指定です。「field」の「from_object_default」に指定した値はデフォルト値になります。「updatable_fields」が指定されていない場合、foo カラムの値は常に「from_object_default」になります。
このあたりは、/path/to/mt/lib/MT/DataAPI/Resource/Entry.pm の MT::DataAPI::Resource::Entry::fields や MT::DataAPI::Resource::Entry::updatable_fields にデフォルトのものがあるので、これを参考に、プラグインから registry に指定していくことになります。

これを指定した上で、以下のようにリクエストを送ることで foo カラムにデータを投入することができます。

my $params = {
    'entry' => MT::Util::to_json( { title => 'Hello by DataAPI: ' . MT::Util::log_time(),
                                    body => 'This is test',
                                    status => 'Draft',
                                    foo => 'foooooooooooo!',
                                  },
                                ),
};

オブジェクトの保存、削除等に関連するコールバック

これまでもコミュニティ機能などで使われていた API 経由での保存に準じて以下のようなコールバックが実行されるようです。他にもあると思いますが、ベーシックなところだけ。

• data_api_save_filter.entry
• data_api_pre_save.entry
• data_api_post_save.entry
• data_api_post_delete.entry

Data API に関する所感

自分に関係がありそうなところを少し調べてみた、触ってみたという程度でまだ試せていないプロパティなどたくさんありますが、総じてスッキリとした形で扱いやすそうな印象を持っています。
なお、今回、Data API について調べるのに使ったプラグインを GitHub に公開しています。認証から、エントリーの作成、更新、削除、ログアウトまでを一連の動作として行うツールも入れてあります。参考になれば。

主に日本で話題になっている、先日サービスインしたGumroad、いろいろと物議を醸しているようですが、僕のように何かしら作ったものをパブリッシュしている人にとってはその機会のひとつとして捉えやすいように思います。例えば Movable Type プラグイン開発者であればプラグインそのものでもいいし、プラグインのサポートでもいいし、テーマでも、テンプレートでも、運用ノウハウでもいいかもしれません。

僕もひとつ、リンクを販売してみています。よろしければどうぞ

いい機会なので、Movable Type 管理画面から UI 操作だけで Gumroad にリンクを作って販売するためのプラグインを作ってみました(で、これも Gumroad で販売してみようと思います)。

ウェブサイト/ブログ、ブログ記事/ウェブページ、アイテム一覧画面から、プラグインアクションを選んでボタンを押すだけで Gumroad にリンクをポストします。

プラグインアクション

Gumroad URL

MT プラグイン「Gumroad」

インストール

Gumroad からダウンロードしたアーカイブを解凍してできる Gumroad フォルダをそのまま /path/to/mt/plugins ディレクトリにアップロードします。

正しく設置できていれば、システム・メニューのプラグイン設定画面に Gumroad プラグインの項目が表示されます。

動作環境

• Movable Type version 5.1 以上

使い方

まず、各ブログのプラグイン設定から Gumroad のアカウント情報と各オブジェクトの販売価格を設定します。現状では、それぞれのオブジェクト単位でのみ価格を設定できます(個別の記事やアイテム単位で価格が決められればいいなと思っていますが、それは売れたらやろうと思っています)。また、価格の単位は Gumroad API の仕様上、セントになるようです。

プラグイン設定画面

プラグイン設定が完了したら、各一覧画面に進み、プラグインアクションからリンクをポストして販売してみましょう。Gumroad へのポスト後は、一覧画面に Gumroad へのリンクが表示されます(表示されていない場合は「表示オプション」から「Gumroad リンク」をチェックしてください)。また、リンクを削除することもできます。

プラグインアクション

仕様

ウェブサイト/ブログの場合は「名前」を、ブログ記事/ウェブページの場合は「タイトル」を、アイテムの場合は「名前」を、リンクの名前として Gumroad にポストします。また、リンクの「説明」として、ウェブサイト/ブログの場合は「説明」を、ブログ記事/ウェブページの場合は「概要」を、アイテムの場合は「説明」を Gumroad にポストします。これらも個別に設定できればいいなと思っていますが、それは売れたらやろうと思っています

Ubuntu を適用した状態

やり方

以下のパスにあるファイルを、

/path/to/mt/tmpl/cms/include/header.tmpl

以下のパスにコピーします。

/path/to/mt/alt-tmpl/cms/include/header.tmpl

このファイルをエディタで開き、以下のように修正します。ここでは、Google Web Fonts の Ubuntu にしてみます。

<mt:setvarblock name="related_content"><$mt:var name="related_content" trim="1"$></mt:setvarblock>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="<$mt:var name="language_tag"$>" xmlns="http://www.w3.org/1999/xhtml" xmlns:mt="http://www.sixapart.com/ns/mt">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=<$mt:var name="language_encoding"$>" />
        <title><mt:if name="html_title"><$mt:var name="html_title"$><mt:else><$mt:var name="page_title"$></mt:if><mt:if name="blog_name"> - <$mt:var name="blog_name" escape="html"$></mt:if> | <$mt:var name="mt_product_name"$></title>

<mt:setvarblock name="html_head" prepend="1">

<mt:setvarblock name="related_content"><$mt:var name="related_content" trim="1"$></mt:setvarblock>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="<$mt:var name="language_tag"$>" xmlns="http://www.w3.org/1999/xhtml" xmlns:mt="http://www.sixapart.com/ns/mt">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=<$mt:var name="language_encoding"$>" />
        <title><mt:if name="html_title"><$mt:var name="html_title"$><mt:else><$mt:var name="page_title"$></mt:if><mt:if name="blog_name"> - <$mt:var name="blog_name" escape="html"$></mt:if> | <$mt:var name="mt_product_name"$></title>

<mt:ignore>追加ここから</mt:ignore>
<link href='http://fonts.googleapis.com/css?family=Ubuntu' rel='stylesheet' type='text/css'>
<style type="text/css">
* { font-family: 'Ubuntu', arial, serif; }
</style>
<mt:ignore>/追加ここまで</mt:ignore>

<mt:setvarblock name="html_head" prepend="1">

のように追記して保存するだけです。次にブラウザにアクセスしたとき、あなたの管理画面は Ubuntu になっています(感じ方には個人差があります)。

筆記体フォントとかにすると、一部何書いてあるかわかりにくくなったりします。このような場合はスタイルシートで使いどころを絞ってあげたほうがよさそうですね。

League Script を適用した状態

もちろんブラウザの設定を変えてインストールフォントに変えてもいいわけですが、その場合は恩恵に預かることができるのはそのブラウザを使っているあなただけです。みんなで共有しましょう。