MovableType Archive

今さらなのですが、個別記事のところのサイドバー等に最新記事リストを表示させることについて自分なりの考えとかまとめてみます

以前、INSTINCのおもちゃ箱のmonbikkeさんの「INSTINCのおもちゃ箱 - 「最近の記事」リストはいるか？」というエントリにてコメントさせていただいたかと思ったんですが、名無しさんになっているので、自分のコメントかどうか確認できないけど、monbikkeさんがレスしているところをみるとコメントしていた模様。

今頃になってなんですが、この件について少し考えなどをこの記事にて述べてみたいと思います。

最近書いたことを辿るような重要な事を書いていない

これは訪問者の立場でみていくと、記事の重要度はひとによって違うようなきがするんですね。自分の書く記事すべてが重要でもないと思っていても、もしかしたら、ほかのひとには何か役に立つとか心にとまるところがあるとかはあるのでないかなー、と考えてます（＃とかいって自分のとこは棚にあげておくとします）。記事内容を重視するのならば、特定カテゴリに絞った新着記事を表示みたいにするのがいいのかも。

カテゴリーを多く設けたので万が一何か探す時もこれでよかろうかと

カテゴリ分けはどのブログでもおこなわれていることですし、新着一覧よりはカテゴリ一覧のほうが利用価値はありそう。探すことに関していうと、一応、動作が遅いとかいわれていたりしますがMovable Typeの検索を利用するという手もあります。タグを設けて絞り込むということも出来ますね。コメントに書いたかどうか忘れたのですが、記事の関連記事を設けていると当該記事以外のページにも興味のある方は読んでいただけるのでないかと思います。＃このあたり運営方針と絡んでくる箇所ですけど。

あとmonbikkeさんの挙げた新着記事を表示させていない理由のほかに、リビルドに関しての問題もあるのでないかと思います。

ダイナミックパブリッシングは別として、新着記事リストをモジュールとして取り込んだ場合、過去記事にはその時点での新着記事になるので、過去記事において常に最新記事を表示させるためには、「サーバサイドインクルード」による表示をおこなう必要がでてくるわけです。このあたりについては以下のエントリなどが参考になります。

• MT4.1以下で実現するサーバー・サイド・インクルード[to-R]
• http://bizcaz.com/archives/2008/08/03-000022.php Movable Type 備忘録 - Movable Type 4.2 のキャッシュとサーバサイドインクルードについ
• 複雑なキャッシュとその効果 - The blog of H.Fujimoto

記事ページで新着記事表示している理由

理由の前に、いるか・いらないか、の2択でしたら、まず「いらない」と答えておきます。それでも表示しているその主たる理由は以下のようになります。

• このブログがアクティブなブログかどうかを判断する材料のひとつとするため

訪問者が見たブログをアクティブかどうか気にするものなのかもわからないんですけど（links for~ とか~(BlogPet)みたいな自動投稿の記事が新着記事リストに並んでるのを見たら、アクティブなブログってあまり感じないのではないかと）。あまり無いとは思いますが、アクティブなブログということで継続して購読されるかたがもしかしたらいらっしゃるのではないかと。これはどうでも必要という積極的な理由ではないんですけどね。

検索エンジンがMTの検索結果ページで出力される、検索結果フィードをクロールしていたようです。その際にMTのシステムログに記録されてしまうのでちょっと対策してみました

Movable Typeのシステムログをみたところ、検索のところにいくつか同一IPのものが並んでいました。そこまでは、よくあることなんですが。

拡大・ダウンロード

上のキャプチャ画像のアクセスはIPを調べた結果（というよりは、サーバの生ログからたどったのが実際なんですけど）、Yahoo!の検索ロボットであるということがわかりました。

MTのシステムログでは、「検索」という文字があるだけで実際のページのURIが示されていないものですから、実際の検索結果のページがタグ検索なのか、キーワード検索かといった区別が見た感じではわかりにくいです。そこで、サーバのログを使いまして同じIPのアクセスを調べたわけです

結果として、Yahoo!によるもので、URIは例えばpluginというタグをつけたページの検索結果ページで出力されているような場合、

/mt/mt-search.cgi?tag=plugin&Template=feed&IncludeBlogs=1

といったページをクロールしていたもようです。どのようなページかというと、タグ検索の結果をフィードで出力するページです。タグ検索結果のページで、link要素に記述されているURIです。

さて、検索ロボットのアクセスが毎回システムログにあがるのは、ちょっとうっとうしい感じ。なのでこの際、MTの検索結果ページそのものが検索エンジンに登録されないように調整してみることにしました。

robots.txtに以下のような記述でちょっと様子見ということにしています。

User-agent: Slurp
Disallow: /*mt-search.cgi

[追記 2008/07/30] msnbot-mediaも巡回するっぽいです。

[28/Jul/2008:00:13:50 +0900] "GET /mt/mt-search.cgi?tag=driver&Template=feed&
IncludeBlogs=1 HTTP/1.0" 200 1958 "-" "msnbot-media/1.0 (+http://search.msn.com
/msnbot.htm)"

ブログなどでよくある、続きを読ませるためのリンク。たまに煩わしさを感じるのですが、閲覧する側からみるとどうなのかと考えてみました

続きを読むリンクは必要？

人力検索はてなのアンケートに以下のようなものがありました。

再アンケートです。
ブログでよくある「続きを読む」のリンク。
トップページをすっきりさせるという意味ではいいと思いますが、クリックが増えるので煩わしく感じることもあります。
ただ、「続きが読む」がない場合はスクロールし続ければ全部読めますが縦に長くなってしまいます。

「続きを読むためのリンクがあったほうがよい」という考えのかたは少なめのよようで、「記事が長い場合にあったほうがよい」という考えの方が多いという結果のようです。

はてなユーザの層とかあるのでこれだけで判断できるものでもないですけどね。

個人的には、ページが縦長になることへはそれほど煩わしさを感じませんから、極力続きを読ませるためのリンクは使わないほうがいい、という考えを持っています。

縦に長くなっても構わないよ、というのはキー操作の部分でカバーできることによります。例えば、PageUP/PageDownキーとかスペースバーによるページスクロール、マウスでもページスクロールをボタンに適用できる機能を備えたものもあります。

記事ページが長い場合にあったほうがいい、という意見には、それは仕方ないかなと思うけれども、それならば記事を分割させてもいいのではと思います。ただIT関連のニュースサイト系に多い、無駄にページ分割が多いというのもちょっと困りますが。

続きのためのエントリ？

話は変わりますが、ワタくシがBloglinesに登録してるフィードのなかで、このようなものがあります。

タイトルとリンクのみが配信されていて、リンクをクリックすると、情報のサマリー。全文を読むには、全文を読むためのリンクをクリックしないといけない（しかも内容はどこぞのサイトの転載記事だったり）。

この場合に、中間にある、記事のサマリーが掲載されているページが閲覧者にとっての余分なページのように思います。せっかくのフィードですのでせめてサマリーくらいは配信してもいいのではないか、と思うのあります。

ところで、Movable Typeでは、記事本文を表示させるためのテンプレートタグと追記部分を表示させるためのテンプレートタグがそれぞれ用意されています。

<MTEntryBody>タグと<MTEntryMore>タグなどがそうです。

MTEntryMoreは追記のために使われているかと思うと、ひとによっては、本文のところがサマリー、内容全体が追記（EntryMore）のような使われかたをされているケースは結構あります。

これは、アーカイブページや、メインインデックスページなどのエントリが羅列されるページにおいて、ページの量を抑えると意味で、記事のサマリーを表示させているのではないかなと思います。

アーカイブページで全文が載ってしまうと縦長になるという問題は、アーカイブページのページ分割をおこなうとか、サマリーを載せるのにMTEntryExcerptを使うというやりかたで解決できそうではあります。

あと、個別記事ページにおいて、追記部分を折りたたむ形にするというカスタマイズが紹介されていたりするんですが、何故にこのようなものが需要があるのか不思議に思っています。例えばです。追記部分に重要な内容がある場合だとします。このようなとき、はじめから隠された状態よりも寧ろページが表示されたときにわかりやすい箇所に明示されているほうが親切なのではないでしょうか。

で、結局どうするか

MT4になってから、本文と追記はタブ切り替え式で縦方向のサイズは可変となってます。前は本文のテキストエリアが狭く、追記のほうが広くとられていたので、追記のほうがメインで書くべきなのかなとは思っていました。

ということで記事内容によっては追記エントリもありとするのですが、ひとつの記事は1ページ完結になるようにMTEntryBodyでおさめられたらいいのでないかなと。その前になるべく簡潔に記事を書く能力を養わないとですが＞＜

【追記：2008/09/21】 Open MagicVox.netさまが、関連エントリをアップしてくださいました。

• 続きを読むリンクについて考える - Open MagicVox.net

ActionStreamの登録するサービスのうち、Flickrがあるんですけど、アカウントの表示名で登録して、Flickr側でURLを設定してないと、プロフィールページが見つからなくなるようです

いつの間にか影をひそめた感のある、「ActionStreamsプラグイン」なのですけど、今日たまたまきづたので修正をおこないました。

ActionStreamsを使っていないかたはわかりにくいかとおもうんですが、ActionStreamsプラグインには、「Find Me Elsewhere」といって、登録しているサービス群をリストアップするwidgetsがあります。

この出力で、Flickrに登録する際、FlickrのIDを表示名（screen name）に（自分のでいうとmaRkdesuですが）してしまいますと、

• http://flickr.com/photos/＜表示名（screen name）＞/

のようになってしまいます。Flickr側のYour account（http://flickr.com/account/）で、Your Flickr web addresses の設定をせずに＠つきのままつかっていますと、リンク先（＝profileおよびphotostream）がPage Not foundになってしまいます。

ワタくシは、一旦登録済みのFlickrをMTのプロフィール設定の「Other Profiles」のところより削除して、あらたに、＠つきのアカウントにて登録しなおしをしました。

Flickr側にてURLを設定された場合にどういった挙動になるのか、試してませんのでわかりません。ちなみに、表示名にて登録していても、ちゃんとFlickrの投稿は拾ってくれておりました。

＃でもよくみたら、Flickrを登録する時点で説明に、「For example: 36381329@N00」と書いてありました。調子に乗って登録しまくったので見落としてしまったかも。

MT4.1のカスタムフィールドで生成されるタグを記述しないとカスタムフィールドの内容は表示されません。このことから、カスタムフィールド内にフィード配信しないコンテンツを含めて利用しよう、という使い方です。

W3CのFeed Validation Service を利用して、フィードチェックをすると、フィードの要素内に、scriptタグが含まれてると、以下のような警告が出ます。

この警告についての説明ページをみますと、

http://validator.w3.org/feed/docs/warning/SecurityRisk.html より引用

Some feed elements are allowed to contain HTML.However, some HTML tags, like script, are potentially dangerous and could cause unwanted side effects in browser-based news aggregators.For this reason, these potentially dangerous tags are often stripped out on the client side.

JavaScriptのように危険なコードが含まれる可能性のあるタグは、クライアント側で除去されることがありますよ。といったところでしょうか。

例えば、ブログパーツを記事で紹介するようなとき記事内に公開されているソースコードを埋めたいようなことがあります。

ところが、記事本文内にscriptタグで埋め込みますと、Feed Validation Serviceで上記の警告がでてしまいます。

これを回避するのに、feedのテンプレートで、MTEntryExcerptは配信しないようにして、追記部分にソースコードを埋め込む、というのを以前やっていたことがありました。

そのほかには、フィードを概要配信に変えてしまうという手もあります。

この辺のお話は、WingMemoさまの記事、「RSSを配信するということ(2)」が参考になると思います。

ただこれらの方法ですと、全文配信派（この場合、読み手の立場からになるのか？）なひとからすると、一寸不満な部分はあると思います。

そのような場面で、カスタムフィールドを使うというのを考えました。

カスタムフィールドの説明などは、www.movabletype.jpのドキュメントにあるとおりなので、細かな説明は省略します。

• カスタムフィールドを使用する

冒頭に書いたとおりですが、カスタムフィールドを作成して生成されたタグをページに埋め込まないことには、カスタムフィールドの内容は表示されません。

記事ページ用のカスタムフィールドとして登録しておき、フィードのテンプレートはそのまま何も手を加えなければ、フィードでJavaScriptコードは出力されなくなるというわけです。

以上はカスタムフィールドを利用したほんの一例でしかありません。サイトの運営方針などもありますし。JavaScriptの動作確認をするのなら、テストページを作成して記事内でリンクの形のほうがいいのかも知れません。

おまけですが、例えば、なぞかけエントリなどで、「そのこころは」の部分をカスタムフィールドでといった使い方も考えられるでしょうね（これだけのために使うというのもアレなのでようせんけど）。

RSSフィードの配信で、改行されていると確かに読み手にとって読みやすいです。ですが、改行せずに配信しても問題ないのではないかと思いました。

ほとんどネタっぽいのですが、その理由としてはこうです。

1. 体裁がよくないために、購読者をサイトに誘導することができる（かも）から
2. Movable TypeのRSS（2.0）で、記事部分（CDATAセクション）はdescription要素なので（あくまでも？）

MT4では、ウェブページを管理することができるようになりましたが、作成したウェブページを特定のフォルダで管理する場合に、そのフォルダのトップページとして、フォルダ一覧のページがあればいいかなと思い作成してみることにしました

追記：　このページでは、Movable Type バージョン 4.x においてのフォルダ管理に関してを記しているものです。

MT4で、ウェブページは、特にアーカイブマッピングで指定しない場合、ブログトップページのディレクトリ配下にウェブページが出来ます。

MT4では、フォルダ管理機能があります。フォルダを作成してウェブページを整理していくことも可能なわけです。

このように、フォルダごとでウェブページを管理していく場合に、作成したフォルダのトップページ（例えばindex.html）があって、フォルダ内の一覧を出力してあるようなものがあったらいいかと考えました。

おおまかな手順メモとして示します

フォルダを管理してみる

メニューの　[一覧]　＞　[フォルダ]　で、フォルダ管理画面になります

例えば、「web」という名前のフォルダを作成したいとき、「トップレベルフォルダを作成」をクリックします。 表示する名前にwebと入力して、「新規作成」をクリックで、<$MTBlogURL$>配下にwebディレクトリが作成されます。

フォルダの編集については以下のドキュメントを参照します。

Movable Type 4 ドキュメント　フォルダの編集

＊フォルダ名は「英語で表記することをお奨めします」とのことなので、この点に注意する必要があります

実際にウェブページでフォルダを指定して使うには、ブログ公開の[フォルダの変更]（MT4.1で右ペインにあります）をクリックして表示されている任意のフォルダ名のラジオボタンをチェックします

フォルダトップページをインデックステンプレートで作る

ここでは、webという名のフォルダを作ってあるという例で/web/index.htmlというインデックステンプレートを作成することを説明していきます

インデックステンプレートを新規作成します。設定等はこのような感じです

テンプレート名

webのインデックス*1

テンプレートの種類

カスタムインデックステンプレート

再構築オプション

任意で設定*2

*1 何でもいいです。　*2 ワタくシはウェブページを作成後に手動でこのテンプレートを再構築するようにするので、インデックステンプレート再構築と同時に再構築しないようにしています。この辺はサイトの運営方法など絡んでくるかと思います

テンプレートの中身をつくる

基本的に、ウェブページアーカイブのテンプレートを丸ごとコピーして貼り付けです。

部分的な修正箇所は、ページタイトルなど、SetVarにタイトル名など指定してあるものを適切な値が得られるように変更します。

ページのコンテンツには、webフォルダ内のウェブページ一覧を示すための記述をいれておきます。例として、以下のようなものです

<MTPages folder="web" lastn="99">
<h2><a href="<$MTPagePermalink$>"><$MTPageTitle$></a></h2>
</MTPages>

folderモディファイアで任意のフォルダを指定します(ここではweb)。 lastn="n" は少なくとも、現在作成してあるウェブページの総ページ数以上は指定することになります。

<MTPages folder="web" lastn="99">
<MTPagesHeader><ul></MTPagesHeader>
<li><a href="<$MTPagePermalink$>"><$MTPageTitle$></a></li>

<MTPagesFooter></ul></MTPagesFooter>
</MTPages>

MTPagesHeader、MTPagesFooterが最初と最後に実行させるためのテンプレートタグです。

作成できたら、リビルドして作業完了です。

作成したページの例

• http://www.mardiary.com/blog/web/

[ 追記：2008年9月15日 ] The blog of H.Fujimotoさまにて、WriteToFileプラグインを利用したフォルダアーカイブページの作成方法が紹介されています。興味のある方は参考にされるとよいでしょう。

• WriteToFileプラグインを使ったフォルダアーカイブの作成 - The blog of H.Fujimoto

今回利用したテンプレートタグ

• MTPages
• MTPageTitle
• MTPagePermalink
• MTPagesHeader
• MTPagesFooter

Movable Typeでは、run-periodic-tasksスクリプトを実行することで、スケジュール処理が可能なのですが、MTのログフィードを取得することで、同様の処理がなされるそうです

密かに（？）Action Streamプラグインを仕込んでおりました。設定そのものはできていましたが、登録したものが更新されてなくて、やっぱりcronの設定しないとだめなのか、と思っていたんです（利用しているサーバでcronは許可されています。負荷等を考慮して使わないようにしていただけですが）。なんとcronの設定しなくても、タスク処理ができるのだそうです。

MovableType.jpブログの「ログフィードの取得によるスケジュール処理の実行」より引用

Action Streams を常に最新の状態に保つには、Movable Type のアプリケーションディレクトリ (通常 mt.cgi のあるディレクトリ) にある tool ディレクトリに格納された run-periodic-task スクリプトを cron などを使用して定期的に実行する他、Movable Type のログフィードをフィードリーダなどで Subscribe (購読) しておき、そのフィードの取得時にスケジュール処理を実行するなどの方法があります。

システムメニュー　＞　ログ　＞ログフィードのリンクを購読　ということです。これで、フィードが読まれたとき、Action Streamsが最新の情報となるんだそうです。

ログフィードをブラウザで読み込んでから、上の、「こんにちはxxxxxさん」のリンクから、プロフィール管理のページでAction Streamsをみましたところ、最新の状態となっているのを確認できました。

こんな方法があるとは、さすがにわからなかったです。これならば、cronが使えないサーバでも使えますね。とてもナイスな情報でした。

4.2のかたは。。ログフィード取得のみではテンプレートの再構築ができませんので、以下のドキュメンテーションを参考にCronの設定等をする必要があります。

• ブログの公開プロファイル

MT4のリッチテキストフォーマットで、箇条書きボタンをつかったときの動作およびマークアップについて確かめてみました

MT4にリスト要素のための入力補助ボタンがあります。いまひとつ使い方とか動作がよくわからなかったため、いろいろといじってみることにしました。

リッチテキストフォーマットでの操作について

リッチテキストフォーマットには、HTMLをがディスプレイで見た状態に表示する、WYSIWYGモードと、HTMLタグつきで表示されるHTMLモードとあります。

WYSIWYGモードのとき、箇条書きリストボタンを押下し、リストの内容を入力していき、改行により、リストマークで区切られるようになります。

リストを入れ子にしてみる

さて、リストを入れ子で使うときもあります。この場合、WYSIWYGモードですと、Tabキーをおすとインデントになるようでした。

ところがです、この状態から、HTMLモードにしてソースを眺めると少し気になることがありました。以下のようなソースでした。

<ul><li>りんご</li><li>みかん</li><ul><li>バナナ<br /></li></ul></ul>

このリスト要素の構造、本来ならば、期待されるソースは以下のようものではないかと思います。ブラウザでは、上記のマークアップでも、入れ子の表示になってはくれますが。

<ul><li>りんご</li><li>みかん<ul><li>バナナ</li></ul></li></ul>

フォーマットなしの場合でやってみる

さて、フォーマットなしの場合（または、リッチテキストでHTMLモード）ですが、箇条書きボタンを押すのは、先にリストを書き上げて、それに対して選択してから、箇条書きリストボタンを押すことで、リスト表示のマークアップになるようです。

因みに何も入力せずに箇条書きボタンを押すと、ul,li要素の組がそのまま入力されます。li要素のインデントには、タブ文字が使われているようです。

で、先に示したような、入れ子にするときですが、例のように、「みかん」の子要素にバナナを入れる場合、「みかん」の後ろにカーソルをもっていき、バナナと打って選択状態にしてから、箇条書きボタンを押すと以下のような状態になります。ちょっと、見た目が変な整形ですが、一応入れ子の形は出来ているかと思います。