文章の幅を変える。640pxから800pxまで広げました。800pxだと横幅が広すぎて読みにくいかなと思ってましたがやってみるとそうでもないかもしれない。もしくは、自分の感覚が昔と変わっただけかもしれない。

これにより、横幅800pxの大きな画像も貼れるようになった。いくつかの過去記事にて差し替えてみたけど、どかっと大きな画像がでるのは気持ちが良い。フォト蔵に画像を置いている関係で、フォト蔵の仕様に縛られる必要があり、今までは横幅450pxの画像を基本的に使ってきた。

↑ 横幅800pxの大きな画像

ちなみに、サイト全体の幅を文章の幅と同じ800pxにした。今までは文章の幅は640pxでも左右に余白を作り、サイト全体の幅は750pxとしてきた。この変更により、CSSもシンプルになるし、見た目もシンプルになって調子がいい。

あとはヘッダー周りも少しシンプルにしてみた。縦方向に関して少しスリム化。結局はシンプルな方向に向かっていくみたい。

entry スタンザは、つぶやきを表します。 (中略) title と content の内容が同じであることに注目してください。つぶやきにはタイトルがありません。そのため、タイトルが実際のつぶやきそのものになるのは当然のことです。

Atom は記事のような文書を対象に設計されていることを思い出してください。記事では通常、見出しがあり、その後に本文が続きますが、つぶやきはその限りでないため、この 2 つの要素には同じ内容が含まれます。

これによると、Twitter Search API によって出力された検索結果(Atomフォーマット)で、entry内のtitleとcontentが同じであるとのことである。

しかし、僕が実際に試したところ、この二つは全く同一のものが入っているわけではなく、titleにはTweetの内容が素のままで入っていて、contentにはTweet内のURLなどにあらかじめアンカーをつけてリンク形式になったものが入っていた。(最初、あまりドキュメントを読まずに試してみたときは、適宜使い分けろという意図なのだと思った。)

で、僕はリンク付きならcontentを使ったらいいんだな、という理解で使おうとしたんだけど、これがまた調子が悪い。

画像にで、上がTweet部分にcontentの内容を利用したもので、下がtitleを利用したものである。日本語だけの問題なのかもしれないが、contentを利用したものは、どこまでがURLなのかをうまく判断できておらず、リンクがおかしくなってしまう場合がある。この不具合により、contentの利用は諦めた。

だからといって、titleに入っている内容はリンクも何もされていない状態なので、これはこれで使えない。そこで、正規表現を使ってURLを自動的にリンクとして表示するようにした。そのための正規表現は以下のようになる。

$text = ereg_replace("(https?|ftp)(://[[:alnum:]\+\$\;\?\.%,!#~*/:@&=_-]+)", "\\1\\2" , $text); 

正直、何をしてるのかよくわからんのですが、正規表現って便利なんだなというのを実感しました。適当にぐぐればすぐ出てくるのですが、参考にしたサイトは、URLの自動リンクをする正規表現(PHP) – こまちドーナツおよび[PHP-users 20308]自動リンクです。

まとめ

• 海外のサービスは日本語関連処理が苦手
• 正規表現はなにかと使える

Twitterのapiを使用して簡単なサイトを作ってみた。概要は、YouTubeやらニコニコ動画やらにのリンクを含んでそうなTweetをまとめて表示します、というもの。詳細の説明が必要ないほどに簡単なサイト。

仕組みも単純で、ただ単に検索ワードとしてyoutubeとかnicovideoとかを設定しておいて、検索結果を表示するだけ。

参考サイト

ロゴ作成にはこちらのサービスを利用させて頂きました。便利。

• Generate Your Own Twitter Logo | Twitlogo

主な参考サイト(Twitter Search API系)

• Twitter Search API の使い方
• プログラミング研究室: [PHP]Twitter APIを使って日本語検索

その他、参考サイト(Twitter API 総合)

• Twitter API 仕様書 日本語訳: tsupo (http://watcher.moe-nifty.com/)
• Twitter API – TwitterまとめWiki

現在、うちのサイトでは画像は全部フォト蔵に置いてるんですね。ファイル容量を食う画像を外部においておけば、今後サーバーの容量が足りなくなるなんてことはありえないという理由から。

いつか足りなくなるんじゃないかという遠い未来のことを考えながらアップロードをセーブしたりするのはできないと思ったので、月単位の容量制限がよかったのでフォト蔵を選んでみたのだけど、フォト蔵はサイズが微妙なんだ。

フォト蔵は、極小(120x)、小(240x)、中(450x)、大(800x)、特大(1024x)、元画像、という個人的にはなんとも使いにくいサイズ。小とか極小とか小さいサイズはいろいろあるくせに、(個人的に)一番欲しい中と大の中間ぐらい(希望としては640pxぐらい)のサイズがなかった。

それで、ちょうどいいサイズでアップロードできるところはないかなと思ったんだけど、だいたい500pxぐらいが標準みたいだった。まぁ、世の中のブログとかって本文の幅それぐらいにしてるところが多いからなぁ。しかし、うちのサイトは1カラムでやってるのでもうちょっとだけ欲しい。で、はてなフォトライフをちょっと見てみたらアップロードできるサイズが自分で決められると。

はてなフォトライフだといろんなサイズを勝手に保存してくれるというわけではなく、自分で長辺のサイズをピクセル単位で指定、必要であれば元ファイルも保存という形式らしい。

アップロードサイズであるが、フォト蔵の場合は月あたり1Gで最大容量無制限という実質アップロードし放題という状況に対して、はてなフォトライフは無料の場合、月あたり30Mと少なめ。よって、フォト蔵のように元ファイルをがんがんあげるようなことはできない。ただし、逆に言えば、無茶な使い方をしなければ十分間に合うとも言える。

実際に試してみたら、640×480pxと元ファイルとして1024×768pxの画像を画質100%で上げてみたら750KBぐらいで、jpgなので誤差はあるだろうけど、400枚ぐらいは月にアップロード出来る計算になる。1日10枚以上あげられるよ。

さらに、画像にペイントする機能とかあって便利そうだった。ちょっとしか触ってないけど、レイヤーとかあってすごい使いやすそうだった。

ブログへ貼るときの体裁だけど、フォト蔵のデフォルトのように変にごてごてしたのがついてないから良い。ただ、これ元ファイルがあるときは元ファイルに直接飛んでくれないかなーと思ってしまう。フォト蔵の時は自分でわざわざツール作ったりして解決したけど、それよりはちょっと使い勝手は落ちる気がする。

でも、総合的にみたらはてなフォトライフはかなり優秀だと思ったわけで、今後は大きめの画像を貼りたいときはそっちを使っていこうかなと考えている所存であります。フォト蔵も使うけどね。

まず、Wordpressの仕様の話から。WPではコメントとトラックバック、ピンバックがすべて同列のように扱われる。それがいやだなって人はごにょごにょにしてコメントとトラックバックを分けて表示するようにしなくてはいけない。

WP2.7以前はプラグインとかで対処しないといけなかったっぽいんだけど、今となってはテンプレートタグだけで対処できるようになった。

wp_list_comment について

そのテンプレートタグ (wp_list_comment)については、結構前にうちのサイトでも触れていたりするんだけど、もう少し詳しく書いてみる。というか補足。(WordPress2.7 テンプレートタグ wp_list_comments() | ROKU STUDIO)

実は日本語版のCodexだとまだ訳し切れてなくて、しかも一番重要だと思われるところが訳されてない。

この「type」の説明が欲しかったのに、日本語版には載ってない。(2009.09.30現在)

type
(string) The type of comment(s) to display. Can be ‘all’, ‘comment’, ‘trackback’, ‘pingback’, or ‘pings’. ‘pings’ is ‘trackback’ and ‘pingback’ together. Default is ‘all’.

Template Tags/wp list comments ? WordPress Codex

つまりはこういうことだ。↓

< ?php wp_list_comments('type=comment'); //コメントのみのリスト ?>
< ?php wp_list_comments('type=trackback'); //トラックバックのみのリスト ?>
< ?php wp_list_comments('type=pingback'); //ピンバックのみのリスト ?>
< ?php wp_list_comments('type=pings'); //トラックバックとピンバックのリスト ?>

それで、方針としては comment.php の中身をこのテンプレートタグを使ってちょっと書き換えるわけだ。

と、その前に

comment.php 以外に書き換える必要がある大切な部分があって、それは single.php などの comment.php を読み込む部分。

デフォルトでは次のようになっているかと思う。

<?php comments_template(); ?>

次のように変更する。

<?php comments_template('', true); ?>

どういうことなのかちょっと正確な情報が見つからないんだけど、これをやらないとうまくいかない部分が現れるので、忘れないでやっておく。

準備完了。comment.php を書き換える。

comment.php は具体的には次のように変える。以下はコメントの表示部分のみを載せます。

<h3>この記事へのコメント</h3>

<?php if ( ! empty($comments_by_type['comment']) ) : //コメントがある場合 ?>

  <ol class="commentlist">
  <?php wp_list_comments('type=comment'); //コメントのみのリスト ?>
  </ol>

<?php else : // コメントがない場合 ?>

  <?php if ('open' == $post->comment_status) : //コメントがオープンの場合 ?>
    <p class="nocomments">現在、この記事へのコメントはありません。</p>

  <?php else : // コメントがクローズの場合 ?>
    <p class="nocomments">現在、この記事へのコメントは受け付けていません。</p>

  <?php endif; ?>

<?php endif; ?>

single.phpを書き換えておかないと、ここらへんがうまくいかない。

<?php if ( ! empty($comments_by_type['comment']) ) : //コメントがある場合 ?>

こんな感じで、コメント部分、トラックバック・ピンバック部分を作る。(トラックバックとピンバックを分けたければそうする)

実際にうちで使ってるcomment.phpの全文は次のファイルです。
ダウンロード：commentphp.zip

参考

• WordPress 2.7 でコメントとトラックバックを分離 – p15.jp
• Template Tags/wp list comments ? WordPress Codex
• WordPress2.7 テンプレートタグ wp_list_comments() | ROKU STUDIO

画面の解像度に合わせて横幅が変化するので、いろんな環境に対応できるというのがリキッドデザインのメリットの一つらしい。

しかし、解像度の大きなディスプレイを使ってたりして、しかもブラウザを最大化しているような人にとって、横に広がりすぎるのは見にくい。(と思うんだけどなぁ…)

見やすい解像度ってどれくらいなのか

そもそも見やすい解像度ってどれぐらいなのか。固定幅のサイトだとだいたい650から1000pxぐらいが主流だと思う。

すると、ブラウザの、サイトが表示される部分の幅は最低でも1000pxぐらいは確保できるなら当然確保したい。

また、固定幅で1000pxぐらいのサイトは、サイドバーが広かったり、2列あったりとかしてるのが多いので、メインのコンテンツの幅はそんなに広いわけでもない。

個人的にだけど、メインのコンテンツの幅は広めにとっていても600pxとかそれくらいが見やすいような気がしてる。文字の大きさとかにもよるけれど。

しかし。リキッドデザインで1カラムのデザインとかだと1000pxに文章がいっぱいに広がることになる。見にくい。(いっぱいに広がっても不思議と見やすいサイトがたまにある。)

ウインドウ幅を調整するという面倒な行為

ここで、「見にくいなら、ウインドウの幅を調整するべき。」という主張がある。それがリキッドデザインのメリットらしいのだけど、訪れるサイトにあわせてウインドウサイズをいちいち調整しないといけないとかありえねぇ、と思う。基本的に大は小を兼ねるべき。

最大幅を設定したリキッドデザイン

そこで、最大幅を設定したリキッドデザインがあるけど、これはまぁ良い案だと思う。(IE6だと対応してないとかいろいろあるけど。)

その場合、基本的に最大幅で表示されることを想定してデザインするべきかと思う。「最大幅は1000pxだけど一番見やすいのは800pxぐらい」とかは避けるべきかと。(もちろん個人の感じ方はいろいろあるのだろうけど、作る側が想定するものとしての話です。)

横幅1000pxぐらいで見てほしいけど、800pxでもちゃんと見れるよ、それ以下でもなんとか見れるよ、みたいなのが最大幅を設定する場合のスタンスとしては良いのかなぁと思う。

つまりは、せっかく大きいディスプレイ使ってるのに、それ故に見にくくなったりするのはなんだか損した気分になるから避けたいということなのだけど。

最終的にはユーザースタイルシートとか作って好きにしたらいいのかもしれないけど、それはまた別の話。

いや、今まで作ったツールってフォト蔵のAPI使ったやつがあるだけでまとめるようなものでもないんだけど。

ただ、サブドメインでページを作ってみたかっただけ。

こういう単体ページはスタイルシート書くのが楽でいい。

古いURL(roku.xxv.jp)からは新しい方(roku000.com)にリダイレクトするように設定。

万が一古いほうのURLをブックマークしてたりRSSリーダーに登録してたりする方がいたら、新しい方のURLに変更しておくようにお願いします。古い方はいつか消えてなくなると思うので。

WordPressには、オートセーブやリビジョンの機能があり、これは便利な機能だとは思うのだけど、普通に個人で使う分には割とうざい。

記事IDがどんどん増える

たとえば、うちのサイトなんかだと、パーマリンク設定を「http://roku.xxv.jp/post_id/」という限りなくシンプルな形にしてます。これだと、まずシンプルだし、記事が増えていく感じをなんとなーく実感できるという利点があって個人的にはこのスタイルがとても良い。ところが、リビジョンとかってひとつ保存するのにひとつのIDを使っていくらしく、IDの数字がどんどん増えていく。実際にに1400越えてたりする。そんなに記事の数はないのに(200もない位)。これはちょっと気になる。

データベースもどんどん増える

あと、リビジョンやオートセーブによってデータベースへ保存する内容もそれだけ増えます。容量自体は対して気にならないような気もするけど、懸念されるのは「重くなるかも」ってこと。実際体感したわけでもなんでもないんだけど、まぁないほうが良さそう。

リビジョンとオートセーブを無効にするプラグイン

リビジョンやオートセーブなんていらん、と思った時にその機能を切れるプラグインがこれ。

Exper Chaotic Flow ? Blog Archive ? Disable Revisions and Autosave plugins

オートセーブのみ無効、リビジョンのみ無効、両方とも無効、の3種類が用意されている。3つ目しか使ってないのでわかんないけど、1つ目と2つ目を両方つかったら3つ目と同じになるということだよね？

あと、すでに保存されたリビジョンなどを削除するぷらぐいんとしては、

WordPress ? Delete-Revision ? WordPress Plugins

これを使えば消せるはず。

ちなみにオートセーブを切っちゃうともしもの時にガーンってなるので、僕はエディタで編集⇒コピペ後に微調整という感じに落ち着いてます。

Google Reader で改行が反映されないfeedのサイトがある

Google Reader で改行が反映されないfeedのサイトがあります。

うちのサイト(WP2.7)の場合で検証したところ、feedの種類によって何がどう違うのかはさっぱりしらないけど、RSS 0.92 のfeedでのみ改行が反映されない。他(rdf,rss2.0,atom)などについては改行されている。(あと、画像も表示されない)

例えば、RSSを購読する手段として、Firefoxだったらロケーションバーの右側にFeedのアイコンがあってそこをクリックして、自分が使ってるRSSリーダーに登録して、とかって手順だと思います。

ここで、ブラウザが取得しているFeedのURLは、WordPressが出力しているFeedのURLとは異なります。(WPが出力したのを自動的にブラウザが認識してくれるとかではない) ブラウザに認識してもらうためには、ソースのheadタグにFeedのURLはこれですっていう記述を書かないといけない。

<link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="RSS 2.0のURL" />

のような感じで。これを複数、たとえばRSS2.0とAtomを書いたら、RSS2.0を購読するか、Atomを購読するかという選択肢が現れる。

すると、Google Reader で改行が反映されないサイトも、headに記述されているfeedのURLがRSS 0.92 であっただけで、自分でRSS 2.0 ないしAtomのURLを叩いてやれば、しっかりと改行が反映された状態で見れるような気がして、いくつかのサイトで試して見た。だけど反映されない場合もあった。というか大抵のサイトはRSS2.0かAtomで配信している。

ちなみにWPでは複数の種類のFeedを吐き出していて、bloginfoというテンプレートタグを使って簡単に確認することができます。(Feed自体は何もしなくても勝手に出力されている。)テンプレートタグ/bloginfo – WordPress Codex 日本語版によると、RDF/RSS 1.0 形式(/feed/rdf)、RSS 0.92 形式(/feed/rss)、RSS 2.0 形式(/feed/)、Atom形式(/feed/atom)がある。

Feedにどんな種類があるかというと、次のようなサイトが参考になる。
HepCat Dev and Test: Feedフォーマットの歴史、バージョン、起源とか

ここまでのまとめ

一旦、ここまでの内容をまとめてみます。

1. Google Reader で改行が反映されないfeedのサイトがある。
2. うちのサイトではRSS 0.92のみ反映されない。
3. 別のWPで作られたサイトでは、RSS 2.0やAtomでも反映されないサイトがある。

2つ目に関連してると考えられるものについて、WordPress フォーラム ≫ RSSに投稿画像を含ませ、改行など有りで配信する方法を見る。解答されてる方の、RSS 1.0 系統と RSS 2.0 系統というのが何の事を言ってるのかちょっとひっかかりますが、RSS 2.0 ないし ATOM フィードを使うようにすると改行や画像は反映されるよという内容。RSS 1.0 系統をRSS 0.92 のことだと考えるとうちのサイトの状況と合う。

3つ目について、若干古い情報かもしれないけど、[WP] RSS Feedを全文配信にするカスタマイズ WP 2.2対応版 – Odysseygate.com によると、WPのコアファイル「feed-rss2.php」内の

<content :encoded>< ![CDATA[<?php the_content() ?>]]></content>

<content :encoded>< ![CDATA[<?php the_content('', 0, '', 0, 3) ?>]]></content>

ちなみに、自分のサイトのものを見てみたけど、デフォルトの記述のままでした。しかし、Google Reader で見る限りはちゃんと改行されている。だから、別にわざわざWPのコアファイルを修正しなくてもデフォルトで改行なんかは反映されるはずだと思うのだけど、上記のような変更をしないとちゃんと反映されないサイトがあるのも事実らしい。

the_content ってそもそもどんなテンプレートタグなのか

ここで、 the_content ってそもそもどんなテンプレートタグなのってことで調べる。

• テンプレートタグ/the content rss – WordPress Codex 日本語版
• Function Reference/the content rss ≪ WordPress Codex

書式： < ?php the_content_rss('more_link_text', strip_teaser, 'more_file', cut, encode_html); ?>

気になったのが最後の encode_html という引数なのだけど、Codexによると

encode_html （0/1/2）- フィルタするHTMLタグを指定。
0（デフォルト。リンクは「URL脚注」として番号を振って出力）
1（PHPのhtmlspecialchars()関数を使ってフィルタ。「cut」の値を0に設定するので、同時に指定しないこと）
2（HTMLタグを取り除き、必要ならば記号などを文字実態参照に変換する。「cut」を指定した場合は、これがデフォルトとなる
）

とのこと。3なんて書いてないんだけど…。ちなみに、strip_teaser と cut のデフォルトは0らしいのでわざわざ書く必要もないと思う。

考えられるのは、1．新たに3というパラメータが追加された、２．今でも3というパラメーターは存在しない、の二つかなぁ。あるいは昔は3もあったとか。

どれなのかはわからないけど、2であるとする(無理やり！)。パラメーターに定義されていない数字を入れた時にどんな挙動をするのかはわからないけど、予想としてはデフォルトの動作をするんじゃないかと。すると、さっきのコアファイルの変更は何か変更しているようで実際にはなにも変更していないのと同じことになりそうなもんなんですがどうなんでしょうか。

最終的なまとめ

まとめると、WordPressが吐き出すfeed(全文出力)で、RSS 2.0 やAtom のfeedならば改行や画像が反映されるはずだけど、反映されない場合がなぜかある。そのような場合、コアファイルを修正すると、その原理は不明だが反映されるようになるらしい、ということになりました。なんとも煮え切らない結果で残念。