kwLogをMT5ではなくWordPressに移行した理由

正直言うと先日までMT5の検証をしてたし、バグの報告とかもしてた。
つまりMT5に移行する気はあった。でも挫折した。もう無理だ。スマン。

まずkwLogはカスタマイズできるブログを書くのが目的でありMovable Typeを使うのは手段でしかなかった。なので移行した理由は目的の達成に適さないと判断したに過ぎない。

もう少し細かく書こう。

Movable Type 5は完全にCMSを実現するツールになってしまった。でもそれを否定する気はまったくない。個人でもそういうことをやりたい人はいるだろうし、そういう人にとってはWordPressを使うよりMovable Typeを使う方が適していると思う。むしろ、そういった(WordPressとは異なる)方向性をはっきり示すことについては好感さえ持っていた。だからこそMT5に移行する気があった。

でも・・・時間が足りない。

一つだけよくわからないのが、「何でもできるから誰でもできるへ」みたいなキャッチコピー。実際MT5を使ってみたけど、サイトとかブログとかスタイルとか言われても何だかよくわからない。サイトマップをちゃんと描けないと使いこなせない気がするし、自分のようなただブログが書きたい人にとってはいきなりサイトとかブログとか言われても?だと思う。

管理ページはだいぶ改善されてるけど、理解しないといけない概念が増えているからそれをUIで解決するのにも限界がある。ドキュメントはかなり整備されてるから学習すればいけると思うんだけど、それを言ったら今までだって学習すればたいがいの人はできるわけなのでやはり腑に落ちない。「何でもできるからさらに何でもできるへ」か「何でもできるから誰でもできるへ(ただしブロガーは除く)」にしか思えない・・・

MT5 RCのリリースの度にサイトとブログのパスが毎回変更されていた気がするんだけど、RC3ぐらいのときかな?既存のデータベースからMT5にあげたときに自動に作成される「新しいサイト」と「kwLog」の出力パスが同じになってページ開くと新しいサイト。とか表示されて、

あぁ・・もう俺・・無理ぽ。

もちろんパス変えたりしたら普通にMT5でもブログだけ書くことは全然できるんだけど、時間が足りないというところにぶち当たるんだよね。何で設定を変えたり学習コストを要してまで使わなきゃいかんのかと。

CMSサイトを作るのもMTを使うのも目的ではない以上、ここで手を引くのが賢明だと判断した。

なんというか残念というか難しいところである。WordPressと内部構造を比較した場合、設計面ではMovable Typeのが洗練されている。WordPressなんかは割とポピュラーなプラグインが普通にSQL使ってたりする(しかもすげーひどいSQLが普通に使われてたりする)けどMovable Typeはオブジェクティブでありこの辺はカプセル化されている。MTタグがあるあたりも素晴らしい。

しかしWordPressの方は痒いところに手が届くというかphpの緩い感じをうまく取り入れている気がする。データベースのテーブルの数もWordPressが10個くらいに対してMovable Typeは40個くらいであり、データ構造を見てもWordPressの方がシンプルなことがわかる。だからこそプラグインが直接SQL書いたりできる。そのためなのかMovable Typeの方がプラグインを書く敷居が高いように感じる。

まぁ、要求されている機能が違い過ぎるので一概に比較するのはフェアではない気もするな。CMSもできるツールがブログだけできるツールと比べて冗長なのは仕方ないか。

MTOSがあるからそこからMT5とは別にブログに特化したMTをつくるのもありだとは思う。でもやっぱり繰り返しになるけど、そんな時間はないし、ツールを作るのは目的ではないのだ。

というわけなのでいったん、Movable Typeとはさよならする。Hackthonにまで参加していくつかプラグイン書いてたけど自分が使わないものは作らない主義なので基本的にメンテナンスもしない。githubにあげる予定なので好きにforkしてください、というスタンスになるつもり。

Movable Typeで簡単に写真付きブログを書くには?

Movable Typeで写真付きブログを書くのはかなり面倒くさい。まず画像のアップロードが面倒くさい。

今までも画像をブログで表示してたけどほとんどMTの機能を使っていない。最近はFTPで画像をアップして素のhtmlを書いていた。

でも別に写真のアップロードを楽にしたいわけじゃない。携帯から投稿するような軽い記事の場合、タイトルの写真と数行のテキストでいい。TIFF情報から日付も判定してくれたりするともっといいんだけど、本当に入力はそれだけでいい。で、これは携帯じゃなくてもこれくらい軽い情報で書きたい。twitterの文字数制限はSMSベースだけどPCで投稿する人はたくさんいる。

先日Flickrアカウントが復活できたので昔やっていたFlickrで画像をあげてBLOG THISも復活してみる。xmlrpcを使ったツールを作ればFlickrじゃなくてもできるけどつくるのも面倒。もうとにかくいろいろ面倒。

先日読んだヒューメイン・インタフェースを思い出すといろいろ問題点が見えてくる。例えばうちのMTは複数ブログつくったりしたせいかMTログイン後にシステムメニューが表示される。なのでいつもブログを選択してから記事を投稿しないといけない。面倒だ。熟練者に優しくない。そして問題なのはこれを直したいのだがどうすればいいかわからない。つまりこの設定が可視化されていない。(ちなみにヒューメイン・インタフェースではドキュメントに載っているというのは非可視とされている)
おそらくトリガーは複数ブログを作ったことだと思うので、さらに言うと複数ブログがある状態がモード化されているということ。モードレスを唱えるヒューメイン・インタフェースからするとこれも優しくない。

でブログを見ていて誤字・脱字に気がついた場合にその記事の編集画面に行くのが遠い。ベースが静的ページで、管理者のセッションがわからないわけだから難しいと思うんだけどJavascriptでなんとかプラグインでをつくれないものか。

MT5でもこのあたりが改善されたとは思えない。ブログを書く・修正するという基本的機能の改善こそ使いやすさにつながると思うのだけど・・・どうもCMS的な強化やWordPressっぽくなっただけで個人ブロガーにとってはMT5の恩恵はあまり受けられない気がする。

さていろいろ文句を言ってしまったけど、別にMTだけが特別劣っているという意味ではないし、sixapartやMT5を責める気は全くない。企業なんだから金にならない個人ブロガーよりも企業向けにCMSを強化するのは全然理解できる。

まーMovable Type Open Sourceがあるのだからガタガタ言ってないで自分でつくりゃいい話ってことだ。Ubiquityあたりで簡単にできるといいんだけど。

Movable Typeでテンプレートキャッシュしたらjavascriptが動かなくなった

早くなるかなと思ってサイドバーをテンプレートキャッシュしたらjavascriptで動かしてたtwitterとあわせてよみたいが動いていなかった。

サイドバーでSetVarしたのをフッターでチェックして動かしていたからサイドバーがキャッシュされてトリガーが消えてしまったっぽい。

あわせてよみたいがだいぶ初期化されている。

MT5 beta3でダイナミックパブリッシングが動かない

MT5 beta 3が出たので入れてみたんだけど、phpダイナミックパブリッシングが動かない。beta 2までは動いていたのに。

バージョンアップのときに、ウェブサイトを自動的に作成する。

ブログの公開パス(サイトURL、サイトパス)設定と、サブドメインの指定に関連する管理画面の内容を変更する。

ブログのサイトパスに、/(またはC:¥など)から始まるパスを書けばそれを絶対パスとして認識するようにした。

これがあやしい。

まだMT5のサイトの概念を理解していないんだけど、ようするに既存のブログを管理している状態でMT5を入れると勝手にサイトを作られ、既存のブログがその階層下に配置されるっぽい。

で、このブログのサイトパスが、親のサイトのパス + ブログのパスのように相対パスにするっぽい。でもブログのパスが絶対パスなら、相対パスにしないように動かしたいって感じ。

サイト (path=/home/makoto_kw/public_html)
– ブログ (path=blog)

これだとブログのパスは ‘/home/makoto_kw/public_html’ + ‘/’ + ‘blog’ になると。

で、まず実際に動かしてみるとサイトの状態はこんな感じになった。

サイト (path=/home/makoto_kw/public_html)
– ブログ (path=/home/makoto_kw/public_html)

勝手につくられたサイトのパスはブログのパスがそのまま入った。で、これは絶対パスなのでそのまま扱ってもらいたい。

でも、ページを出力してダイナミックパブリッシングで動的に表示しようとすると/home/makoto_kw/public_html/home/makoto_kw/public_htmlにファイルをつくろうとしやがる。絶対パス判定ができていない。

apache様に/home/makoto_kw/public_html/home/makoto_kw/public_htmlを作成する権限がないので動かない。

なおしました。/php/lib/class.mt_blog.phpの65,66行目がfunction site_path()がおかしいです。

if ( $this->is_site_path_absolute )
  return $site;

は以下にすべきです。

if ( $this->is_site_path_absolute() )
  return $this->blog_site_path;

ちゃんとダイナミックパブリッシングもテストしてほしい。。。

MTプラグインのMovable Type 5.0対応とか

粛々と対応していたMovable Typeプラグインの5.0対応したのを更新してみた。

Movable Type 5.0は現時点ではBetaリリースなんですが、開発者向けの資料がみつからず内部的に何がかわったかよくわからず試してみてダメだったところを直すという感じで対応。

結論から言うと対応を要した5.0での変更点は

  • (perl)のデフォルト文字コードがutf-8になった(らしい)
  • MT.phpのメンバがpublicからprotectedに変更された

というところ、

前者の場合、utf8な外部からデータを取ってきて出力するようなプラグインはそのまま出力できるようになった。でも過去互換もとらないといけないのでとりあえず、

use utf8;
...
sub fn() {
...
utf8::encode($contents) if MT->version_number < 5;
$contents
}
1;

な感じで、プラグイン内ではutf8で処理して(use utf8;)、出力する際にMT5未満ならフラグを落として返してあげる、5以上ならそのまま出力。本当はMTのバージョンではなくそのPerlの内部コードやらで判定してやりたかったのだけどPerlの文字コード周りがよくわからないので妥協。

後者の場合、phpダイナミックパブリッシングを処理するプラグインにおいて、dbをみる場合に

$config = $ctx->mt->db->fetch_plugin_config('SyntaxHighlighter', "blog:$blog_id");

などをしていたらMT5ではMT.phpのメンバ変数が全部protectedに変わっているのでアクセスできなくなった。$dbに関してはdb()というpublicなgetterが用意されているのでこれを使うようにした。

$config = $ctx->mt->db()->fetch_plugin_config('SyntaxHighlighter', "blog:$blog_id");

それ以外の変数を使ってないので大丈夫かよくわからない。

設計面でみるとMovable Typeはかなりobjectiveにつくられておりこのあたりのアクセス件は厳密にするのが設計ポリシーなのだろうと予測。WordPressなんかは逆にphpの何でもできるところをそのまま継承して多くの機能がglobalにアクセスできる用にしている気がする。

どちらが良いというわけじゃなくいろんな文化があることが良いと思う。

ただ、いい加減Movable TypeのダイナミックパブリッシングはPerlにして欲しい。ポリシー以前に言語を二つ使うのはプラグイン開発者としてはしんどい。

Dashboard Hatena Trends 0.1.1 (for Movable Type)

怒濤のMT5対応プラグインリリース第二弾。

Movable TypeのDashboardにはてな注目キーワードを表示するプラグインをMovable Type 5.0(utf-8)に対応させました。

あと、Date/Simpleモジュールが入っていないと動かないことに気がついたのでプラグイン内に同梱しました。

Dashboard Hatena Trends

SyntaxHighlighter for Movable Type 0.1.1をリリースしました

SyntaxHighlighter for Movable Typeを更新しました。

  • SyntaxHighlighter 2.0.320に更新しました、ブラシにActionScript3, PowerShellが追加されました
  • onloadで余計なことをしていた処理を修正しました
  • Movable Type 5.0 (beta)に対応しました

今週末 Movable Typeプラグインとかリリースしる

いくつかプラグインがMT5用に変更する必要があるので週末あたりに軒並み更新します。普通に不具合修正とかもぽつぽつしていたのも一気にあげます。

同時にPukiWiki for Movable Typeとか最近つくったやつのリリースページもちゃんとつくります。

さらに、kwWiki抹殺します。必要そうなページはこのブログのウェブページに移行します。(もともとその目的でPukiWiki for Movable Typeをつくっていた)
週末そんな時間がつくれるかわからないけど、自分を追い込むためにあえて宣言してみるの巻き。

Movable TypeとWordPressにPukiWikiフォーマットを導入

kwWikiをMovable TypeやWordPressのウェブページに移行する計画のためにPukiWikiをプラグインにして導入しました。せっかくなのでPukiWiki形式でこのエントリ書いてみるMarkdownに書き直し。(ブログのエントリで下書きするのはなんか間違ってる気がするが・・・)
人様につかってもらえるほどのテストもしていないし、ドキュメント(使い方の説明)もまだ乏しいのでプレビュー版だと思っていただきたく。

とりあえず箇条書き

あとでドキュメント化しよう

  • もともとの動機は主にMovable Type/WordPressのウェブページをPukiWiki形式で書きたいところからきている
    • Movable Type版ではテキストフィルタを作成したのでブログエントリでも使えるが、WordPress版ではまだそれと同等なものは用意していない
    • WordPressのほうでは自作テーマをつかっているのでPukiWiki変換をするテンプレートページをつくってそれをウェブページの画面で選択している(個人的要求はこれで満たせている)
    • ちなみに自作テンプレート内で直接こんなことしてます
<?php echo wp_pukiwiki(get_the_content()); ?>
<span class="powered_by_pukiwiki">Powered by <a href="http://pukiwiki.sourceforge.jp/">PukiWiki</a></span>
  • Movable Typeではグローバルフィルタも作成、テンプレートでpukiwiki_convert_html=”1″を使うとPukiWikiで変換される
<mt:SetVarBlock name="pukiwiki_src">
*h1
**h2
***h3
-aaa
--bbb
---cccc
preprepre
</mt:SetVarBlock>
<div class="pukiwiki_content">
<mt:GetVar name="pukiwiki_src" pukiwiki_convert_html="1"/>
</div>
  • cssとして下記を追加する必要がある
    • Movable Type: /mt/mt-static/plugins/PukiWiki/pukiwiki.css
    • Word Press: /wp-content/plugins/pukiwiki-for-wordpress/pukiwiki.css
    • またdiv.pukiwiki_contentで括る必要がある

仕組み

  • プラグインの階層化にPukiWiki 1.4.7(utf8)そのものを同梱
  • プラグインから自分の階層にあるPukiWikiに対してHTTPをPOSTして変換したhtmlを受け取り出力する
    • Perl(Movable Type)から使いたいこと、phpからもグローバル変数・関数のバッティングなどを考慮してHTTPでアクセスすることにした(SOA的な)
  • 内部にあるPukiWikiのアクセス制限のため、別途リクエスト受け取り用のスクリプト(Adapter)を作成
    • このスクリプトは変換機能だけをもつ(書き込みはしない)
    • プラグインから以外のアクセスはエラー
    • interwikinameはOFF
  • 変換処理について
    • contentとfooter_noteを出力する
    • 実ページがあるわけではないので添付ファイルは使えない
    • PukiWiki内部リンクはすべて除去する

その他補足

  • PukiWikiはiniの設定を少し変えただけでデフォルトの状態、iniの設定やフォルダのパーミッションを設定すれば普通にPukiWikiとして使える
    • 危険なのでPKWK_READONLY=1にしてある
    • http://blog.makotokw.com/mt/plugins/PukiWiki/svc/pukiwiki/
  • このエントリでcodeprettifyが効いてるのは別途PukiWikiのプラグインを追加しているため
  • エントリの下にあるPowered by PukiWikiは、ブログのテンプレートに直接書いているものでプラグインが出力するものではない