2009年5月 Archive

microformatsのrel="tag"の記述について、nofollowも指定したいときの書き方とかのメモです。

先日、WolaWolaさまのページをブックマークしたときにつけたコメントの内容に関しまして（はてなブックマーク - Recent（最近の）言わんといて！ - WolaWola）、元記事に追記がありまして、コメントの内容について,自分で言っておきながらなんですが、妥当かどうか自信がないのでといいますか、突っ込みいれた責任上、メモとしてエントリしておきます。

指摘箇所ですが、タグのリンクについているrel属性のところでrel="nofollow,noindex,TAG"というのを、rel="nofollow tag"にせよ、とそういうことです。いいたかったことを二点にわけますと、一点目が「attributeの値に複数書くときの方法についてとmicrofomatsの件で」と、二点目が「noindexはどうなの？」となります。

rel属性の値に複数指定するとき

これは、以前調べた記憶があって、rel="nofollow"をrel="tag"につけたいときどうしたらいいのよ、ということで調べていたら海外のサイトだったかでスペース区切りにされていたようなので自分のところはそのように書いたと、そう記憶してます。

複数書く（＊Link types）場合の方法ですが、確か仕様書だったかにあるという発言をされていたかたをTwitterかWassr経由で知ったのですが、そのソースも忘れてしまったので、自分で検索してあたってみたのが以下のページになります。

• Links in HTML documents（Attribute definitions）

上記ページにThe value of this attribute is a space-separated list of link types.とありますので、Link Typeをスペースで区切ることになっているようです。

あと、microformatsのrel-tagについては以下を

• rel="tag" · Microformats Wiki

「TAG」という記述に関してですが、「microformatsに従うならば」、という文言をたぶんブックマークコメントにつけておけばよかったのかなと。この点は説明足らずで申し訳ないと思ってます。

Firefoxのアドオン、Operatorによりますれば、大文字でTAGと書いて仕舞うとタグ空間として抽出されないようです。自分のところで、Firebugを使ってtagとあるのをTAGに書き換えたところ、そのタグでは、Operatorで抽出できませんでした。ですが、Operatorはmicrofomatsの仕様ドラフトに忠実なために厳密な部分があります。そのため「microformatsに従う」という但し書がブクマコメントには必要であったということです。

noindexのことと、タグアーカイブページの検索エンジン対策について

nofollowは検索エンジン向けの記述でありますが（此の件はコチラが説明するよりは他のページの解説とかGoogleのウェブマスター向けのヘルプページとかをあたったほうが確実と思います。）、noindexはリンクを張っているページから記述されても（rel="noindex"）値を評価されないのでないかと思うのですがどうなのでしょう。

ページにリンクがあるとして、クローラーがそのリンクを辿る行動をするのがfollow。これをやらないで欲しいと伝えるのがnofollowですよね。これはメタ要素に書いていたことですけど、これを簡単に指示できるようにしましょう、としたのが（その経緯とかはここでは割愛）、rel="nofollow"。それで、noindexはインデックスされたくないページに書くと。そのあたりの件でブクマコメントには、noindexを記述しないでおいたのです。今思えば「自分ならばこのように書くかな」、程度なコメントなのかも。

タグアーカイブの検索エンジン対策

ここからは本題と逸れてしまいますが、タグアーカイブページをインデックスされないようにすることのお話です。

こちらで前から対策とかをやってはいるのですが、100パーセントは無理でないかなという感じがします。といいますのも、クローラーの中に行儀のよくないのがいるようなので......。

で、当方がおこなっているのは、robots.txtへの記述と、metaタグでのnoindexとかです。

Movable Type 4.2xのデフォルトのタグクラウドをみますと、javascript:void(0)でonclickイベントにてページ移動をさせています。こう書くことでrel=nofollowを書くまでも無く検索エンジンのクローラーはこのリンクが辿れないというわけです。

ただしこれだと先述のOperatorではInvalidです。rel-tagを採用していて、かつタグアーカイブページ（実態はタグ検索結果ページですが）microformatsに対応したURIにして使っていてこれでは本末転倒といったところ。

この辺の話になってくると、サイト運営者の方針でしょうから、外野があれこれいうこともないのですが、折角microformats取り入れているならば活用できる方法で記述されてはどうかなというのがワタくシの意見だと、つまるところはそういうことでした。

今月（2009年5月）、テンプレートなどをカスタマイズしたところをまとめておきます。

Movable Typeをアップグレードさせたこともあって、あれこれ弄ってた気がするのですが主な変更箇所等は以下のとおりです。

1. 「タグアーカイブページ」で関連タグがでるようにした
2. 4.25にアップグレードとコメント認証のサービスを追加
3. ダッシュボードのウィジェットを作成してみた
4. 検索をmt-search.cgiからAjax＋JSONによる全文検索に変更した。
5. スタイルシートのファイル構成の変更
6. フッター（#footer）の背景色・リンクカラーを変更

TagSupplementals PluginおよびMT-XSearchによるタグアーカイブですが、MTRelatedTagsを利用した、関連タグをサイドカラムに表示するようにしました。

関連

• タグ検索結果ページで関連タグがでるように

以下のページ等で確認できます。

• tag: template

Movable Typeのヴァージョンを4.25にしました。これまで、コミュニティ機能なしのMovable Type Commercial を利用していましたが、今回よりmotion等コミュニティ機能つきのProとしました(今のところコミュニティ機能の使い道が無いんですけど)。

アップグレードについては、いつものように圧縮ファイルアップロード、SSH接続でunzipと、pluginsフォルダ、/mt-static/plugins/ 内のフォルダ等のコピー、configファイルのコピー、cgiファイルのパーミッション設定といった手順です。

アップグレードにともない、認証サーヴィスの追加をおこないました。確認できているものでgoogle、yahoo、livedoor、はてな等が利用可能です。

ダッシュボードウィジェットは、プラグインという形で現在、最近の記事で使われている、「カスタムフィールドの内容」を出力するウィジェットを作成して使っています。（後日紹介のつもり）

Movable Typeの全文検索ですが、以下のページを参照しました。

参考ページ

• 今日のMovable Type：Ajaxを利用したMT用超高速検索システムはスゴすぎる！: 世界中の１％の人々へ
• 暴想: ココログプロとかTypepadとかMTとかブログ人とかその他のブログサービスとかでもAjaxでバックナンバーを検索するJavaScript
• MT 向け Ajax サイト内検索 | WWW WATCH

導入方法についても解説されているままです。あと、記事ページに１カラムレイアウトを採用している関係で、検索結果をページ内に流し込む方法だと検索窓をページ上部にもってこないと不都合だったりするので専用ページを設けることにしました。これについては、WolaWola（author:oscarさん）さまのテンプレートを参考につくりました。

検索ページを見た限りですと、ページ遷移すると検索が始まるようでしたので、たぶんパラメタの値でもってごにょごにょやってるのだろうと思い、自分なりの解釈で作ってみました。

スタイルシートの構成については先日書きました。

• スタイルシートの構成を変更してみました

フッターの背景を黒系にしてヘッダーとあわせるとしました。ソースは以下のとおり。

div#footer {
   color: <em>#CCCCCC</em>;
   background-image: none;
   background-color: #000000;
   padding: 1px 0;
}

div#footer ul.support {
    color: #CCCCCC; /* + maRk */
    margin: 0em 10px;
    text-align: right;
}

/* + maRk */
div#footer ul.support li a:link {
    color: #0198CA; }

div#footer ul.support li a:hover,
div#footer ul.support li a:active {
    color: #00B8FD; }
/* + maRk */

Movable Type 4.25では、これまでの認証ユーザのサービスにいくつかのサービスが加えられています。今回は「はてな」のOpenIDによる認証を試してみます。

認証ユーザの件については、MovableType.JPの以下のドキュメントを参照します。＊モーション用のドキュメントですが、通常のブログであっても認証については同様です（のはず）。

• OpenID などを使用した認証ユーザーのサインイン（www.movaletype.jp）

コメントのサインインのリンクをクリックします。

サインイン画面に遷移します。自分のはてなIDを入力して、サインインのボタンをクリックします。

はてなのサインイン画面に遷移します。SSLでログインする場合は、セキュア(SSL)のリンクをクリックします。なお、すでにはてなにサインインしている場合は、ログイン認証画面は出ずに次のステップとなります。

OpenIDでのログイン確認画面に移動します。認証するサイトのURIが表示されて、認証をおこなう場合は、「今回のみ許可」か「常に許可」を選ぶことができます。この辺の説明は、はてなの説明ページを参照します。

• はてなでOpenID - はてな

認証に成功すると、元記事のページに戻りコメント欄のところで、ワタくシの場合だと「maRkとしてサインインしています。」という文言が表示されます。

はてなのOpenIDの確認画面で「常に許可」を選んだ場合ですが、次回からはそのサイトではOpenIDを許可するかの確認画面が表示されなくなります。

「常に許可」のサイトを解除するには、http://www.hatena.ne.jp/ユーザID/config/authのページに移動して、許可済みサービス一覧のなかから削除したいサイトのところの「削除」ボタンを押下します。

あとがき

検証日時は、2009年5月21日です。その後の仕様変更などで挙動が変わることがあるかもしれません。

はてな認証は、4.25からのもので、プラグインのものとは別です。4.24以前からプラグインで導入されているかたは、無効にするかプラグインを外されるとよろしいかと。自分の場合ですが4.25にアップする際、以前のバージョンのプラグインディレクトリからコピーせずにアップグレードをおこないました。「はてな」のほか、4.25ではWordPress（のアカウント）も同様にはじめから認証サービスとして入っています。

エムロジック放課後プロジェクト提供のRenameLabel Pluginは、Movable Typeの編集画面のフィールド名を任意の名称に変更するためのプラグインです。ためしにこれを使って漢字のラベルにしてみました。

プラグインを入手する

プラグインは、エムロジック放課後プロジェクト（エムロジック株式会社）さまの以下のページからダウンロードできます。

説明のHTMLファイル等も同梱されていましたので、導入方法などはそちらを参考にします。

• MovableType用RenameLabel Plugin　Ver.1.12

ラベル表記を変更する

プラグインが導入できますと、ブログのプラグイン設定の画面にRenameLabel Pluginが表示されているはずですので、そこから「設定のタブ」を表示させると、設定画面が表示されます。

利用の状況に応じて適切なラベル名を付ける、というのがこのプラグインの本来の目的なのですが、今回は昨今の漢字ブームにあやかって（？）ラベルを漢字にしてみました。漢字訳ですが、かなりテキトーです。漢字訳については、いちおう以下のサイト等を利用しています。＃ネタですいません（汗;

• Wikipedia(ja)
• エキサイト翻訳

スクリーンショットを示します。

管理画面は以下のようになりました。ちょっとやばいカンジです。

Click to Enlarge

今回ためした件のラベルとその値の対応は以下のファイルとなってます。訳はコチラのイメージとかによるので、妥当ではないとおもいます。「トラックバック／言及通知」とか。

Download

• rename_label.zip

mt.VicunaテンプレートのスキンのStylesheetと、カスタマイズしたスタイルとの構成を見直して変えてみることにしました。

既にmt.Vicunaでは新しいスキンが提供されているわけですが（MTテンプレート vicuna - スキン）、ここのブログで切り替えしようかどうか迷ったんですけれども、結局、使い慣れているということから今までのスキン（style-ninja）を使うことにしました。

これまでこちらが追加したスタイルは、<$MTBlogURL$>style.css内に、以下のように書いていました。

@import url(<$MTStaticWebPath$>themes/style-ninja/import.css);
/* add styles */
<MTInclude file="foo.css" />

上記のように追加するスタイルシートは別にカスタムインデックステンプレートで作成して、MTIncludeで取り込んで追加分ファイル側から設定を変更したりなどしていました。

これをこの度、上記のような方法をやめにして、追加スタイルシートを別途作成したうえでlink要素から追加するという書き方に変えました。

追加スタイルのほうですが、index系のテンプレート、アーカイブリスト、記事ページ毎に追加スタイルをそれぞれ設けることとしました。具体的には以下のような形でそれぞれのテンプレートのhead要素内に追記しています。

変更のときはFTPクライアント経由ということでおこなうとします。（カスタムインデックステンプレートを作成してもいいのだけど、今の状況からテンプレートを増やしたくないというか）

インデックステンプレート

• <link rel="stylesheet" href="<$MTBlogURL$>custom-style_indexes.css" type="text/css" />

アーカイブリストテンプレート

• <link rel="stylesheet" href="<$MTBlogURL$>custom-style_archivelist.css" type="text/css" />

記事ページテンプレート

• <link rel="stylesheet" href="<$MTBlogURL$>custom-style_entry.css" type="text/css" />

それと、import.cssですが（旧スキンでは0-import.css）、インポートするスタイルをlayoutとsubSkinの2つのスタイルだけにして、他のファイルはimport.cssに統合させる、としました。5-module.cssについても、利用しているのは今のところグローバルナビゲーションのスタイルのみですので、そのスタイルも統合しました。以上です。

ブラウザで、ページ上部に戻るためのボタンが実装されていたらいいな、という話の件につきまして

で、元記事は以下と。テキストが短いので引用すると全文転載みたいになるのでリンクのみで。

• 「ページの上に戻る」ボタンはブラウザに実装されるべき 云々（うんぬん）unnun.com

多分その動作は、スクロールバーの上向き矢印マークの下付近にカーソル移動させてShift＋マウスクリックかと思いますが（Windowsの場合）。

でもそもそも戻りたい箇所が必ずしもページ先頭とは限らないのでは、と思うわけです。例は出さないけども、ページのはじめのところに戻って読み返したいという場所がヒトによって違うのでないかということです。

まー、自分の閲覧方法に基づいたらこういうのがあったらいいな的な機能でないでしょうか。デフォルトで実装というよりは拡張機能であればよしというか。「Greasemonkey」でいう意見があるのでそうなのでないのかなーと。

Twitterの背景画像をメイン領域で透かして見えるようにするためのユーザースタイルの例です。

自分はクライアントやモバイル版経由の投稿が主なのユーザースタイルとか適用してもあまり恩恵は得られないわけですが。。ま、なんというか自己満の世界とでもいいましょうか。

コードは以下です。透過は「-moz-opacity」(*１)で。リンクカラーとかを指定してある場合を考慮してないので透過の割合はヒトによって違ってくるかも。マウスオーバー時の背景色は継承させないやりかたがよくわからなくて、濃い目の色に上書きさせることで対処してます。

例によってFirefoxアドオン、Stylish向けのスタイルシートです。（確認環境は、Stylish1.0.1・Mozilla Firefox 3.0.10です）

twitter背景透過

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("twitter.com") {
#content{ -moz-opacity: .8; }
ol.statuses li:hover,
ol.statuses li.hover{
            background:#E3E3E3 none!important; }
}

Movable Typeのダッシュボードにプラグインとして、ウィジェットを追加することができるとのことで、あれこれ試して「ブログパーツ」を表示するというのができました。

最近ブログパーツとか使わないというか、それほどかまったりすることがないのですが、ほんの練習がてら作ってみたものです。ウィジェット作成の方法ですが、The blog of H.Fujimotoさまの以下の記事から始まる続き物記事にて詳しい解説があり、参考にさせていただきました。

• 簡単なダッシュボードウィジェットを作る（その1）

以下に作成した手順を記しておきます。これはネタ的なものでして、実用性とか全く考えてませんのであしからず。例としてBlogPet（ブログペット）を表示させるというのを示します。まずはキャプチャから。

手順は以下のような感じです。

手順１：ブログペットを表示させるHTMLファイルを作る

テンプレート側で、インラインフレームにて呼び出す、という形にしています。因みに自分のVoxブログにて表示させていますが、あれもインラインフレームが使われています。

テンプレート自体はブログペットを表示させるだけの簡単なものでいいかと思います。blogparts.htmlとか適当なファイル名で保存して、サーバにアップしておき表示されることを確認しておきます。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" lang="ja">
<head>
<title>blogpet</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta name="robots" content="noindex,nofollow" />
<style type="text/css">
object,embed{ border: 0px none; }
</style>
</head>
<body>
＜－－ここにブログペットを表示させるコード　－－＞
</body>
</html>

手順２：config.yamlとテンプレートを作成

config.yamlのコード

ここではidをWidgetBlogparts、テンプレートファイルは、blogparts_widget.mtmlとし、ファイル名config.yamlで保存します。

name: Widget Blogparts
id: WidgetBlogparts
description: ブログパーツを表示
version: 1.0
widgets:
  blogparts_widget:
    label: ブログパーツ
    plugin: $WidgetBlogparts
    template: blogparts_widget.mtml
    singular: true
    set: sidebar

テンプレート（blogparts_widget.mtml）のコード

ファイル名をblogparts_widget.mtmlとして、tmplという名前のフォルダを作成してその中に保存します。以下は上記のブログペットを表示するページをウィジェットに取り込むためのテンプレートの例です。

<mt:setvar name="blogpetID" value="ブログペットのID（貼り付け用コード内にある32文字くらいの英数）" />
<mt:setvar name="src" value="http://example.com/blogparts.html" />

<mt:setvartemplate name="showBlogparts">
<iframe frameborder="0" marginwidth="2"
marginheight="2" longdesc="http://www.blogpet.net/profile/view/<$mt:getvar name="blogpetID"$>" src="<$mt:getvar name="src"$>" width="134" height="324" scrolling="no"></iframe>
</mt:setvartemplate>

<mtapp:widget id="WidgetBlogparts" class="widget" label="ブログパーツ" can_close="1">
    <mt:getvar name="showBlogparts">
</mtapp:widget>

手順３：ファイルをまとめてプラグインディレクトリに入れる

ファイルの準備が整ったらフォルダにまとめていつものようにMTシステムのpluginsディレクトリに収めます。

フォルダの構成とかはこのような感じです

• blogpartsWidget
  • tmpl
    • blogparts_widget.mtml
  • config.yaml

最後に

マルチブログ機能とかで、複数ユーザのパーツの対応とか考えたけど、ややこしくなってきそうなのでこの辺でやめておきます。この理屈でいうと、いくつでもパーツをつけれそうなのですが、ま・あまりつけ過ぎるとダッシュボードがカオス状態に！くれぐれもご注意を。次回はもう少しマトモなのをやってみたいと思います。以上です。

MT-XSearch対応のタグ検索ページで関連タグが表示されるように修正をおこないました。

自分メモ的なことので、背景だとか経緯とかは端折ってしまいます。以下のページにてその辺の内容を書いています。

• mt.Vicuna：MT-Xsearch用のテンプレートモジュールを試作。

ということで、TagSupplementals（0.22）とおよびMT-XSearchという環境が大前提にあります。

サイドバーのタグのウィジェット部分を以下のコードに替えました。実際に使っているテンプレートでは、タグのウィジェットをインクルードせずにコードをテンプレートに直に書いています。

<dl class="others">
   ・・   略   ・・
<dt>Related Tags</dt>
<MTXSearchTags><dd>
<ul>
<MTRelatedTags>
<li><a href="<$MTBlogURL$>tags/<$MTTagName encode_url="1"$>" rel="nofollow"><$MTTagName$></a></li>
</MTRelatedTags>
</ul>
</dd></MTXSearchTags>
   ・・   略   ・・
</dl>

MTRelatedTagsについては、以下を参照します。

• ogawa/mt-plugin-TagSupplementals · GitHub

記事に設定したカスタムフィールドもあわせてフィードに配信する方法を考えてみました

自分のところに検索された語から何かを読み取って勝手に回答してしまうエントリです。ということで今回はMovable Typeのカスタムフィールドネタをします。

ここで以前、カスタムフィールドに書いたものはフィード配信にならないという内容の記事を書きました。

• フィード配信しない内容をカスタムフィールドにて

今回はその逆ですね。フィードのテンプレートを少しカスタマイズすると恐らくいけるのかとおもいます。

フィードにカスタムフィールドの内容を反映させる（案）

まずカスタムフィールドを作成します。ありきたりですが、ここでは「関連記事」というカスタムフィールドを作り、複数行テキストにて、関連記事へのリンクを示すというものを作ったと仮定して説明してみます。

例として以下のようなカスタムフィールドを出力するコードをフィードのテンプレートに埋めてみます。

このフィールドはcf_relatedentryというテンプレートタグ名とし、出力させるコードは以下のようなものとします。

<mt:If tag="cf_relatedentry">
        <div id="related" class="relatedEntry">
          <dl>
          <dt><b>関連記事</b>:</dt>
               <dd><mt:cf_relatedentry></dd>
          </dl>
        </div>
</mt:If>

テンプレート編集で「最新記事のフィード」（Atomフィード）を編集します。

content要素の内容で、mt:EntryMoreタグの下に追加します。

カスタムフィールドの内容をCDATAセクションにします。

ただ、この方法ですと、mt:EntryBodyタグにある、encode_xmlオプションのために、CDATA区間が2箇所できることになります（＊環境変数でNoCDATAを使用してない場合です）。このことが原因で正しく表示できないフィードリーダーがもしかしたらあるかもしれないです。

これがキモいというときは、encode_xmlを使わずに直接CDATA区間を指定する方法を使ってみます。

なお、確認は簡単なテスト記事にてIE7のフィードプレビューでしか（Firefoxだと、summary要素の内容がでてしまうので）おこなっていません。実際の運用のところまでは一寸自信がありませんのでその点はご承知おきいただけたらと思います。