feed
2013年11月21日, 編集履歴
ブログ記事にタグを設定し、タグ一覧ページ を作った(2013年12月8日追記:「Jekyll製ウェブサイトに簡易検索機能を実装する 」にて実装した検索機能に統合したためdeprecated)。
Front-matterでタグを付ける
Jekyllでブログ記事を書くときに、Front-matterにタグを埋め込むことができる。この記事の場合だと、Front-matterは以下のようになっている。
---
layout: post
title: Jekyllで簡易タグページを作る
tags: jekyll github
---
tags:
部分はスペース区切りかYAMLフォーマットのリスト形式で複数のタグを設定することができる。
タグ一覧ページを作る
タグを付けたら当然その一覧ページが欲しいが、Jekyllにはタグ一覧ページを出力する機能はついていない。プラグイン(Jekyllはプラグインで機能拡張ができる)でそういうのがあるのかもしれんけど、GitHub Pages 上でビルドする場合はプラグインは使えないので自分でなんとかするしかない。
あまり複雑なことをやろうとすると深みにはまるので、シンプルにいく。
まずはタグ一覧ページとして/blog/tags.html
ファイルを作成する。この中にブログ記事中で設定されているタグと、そのタグが付けられた記事を羅列する。今回は以下のような記述を/blog/tags.html
に追加した。
{% for tag in site.tags %}
<article>
<h1 id="tag_{{ tag[0] }}">{{ tag[0] }}</h1>
<ul>
{% for post in tag[1] %}
<li><a href="{{ post.url }}">{{ post.title }}</a></li>
{% endfor %}
</ul>
</article>
{% endfor %}
site.tags
には全タグの情報がハッシュとして入っている。キィはタグの文字列、値はそのタグが付けられた記事の配列になっている。
Jekyll(Liquid)でハッシュを{% for %}
文に掛けると、一時変数には各要素のキィ・値ペアが配列として渡される(インデックス0
にキィ、1
にその値)。上記の場合、{% for %}
文の一時変数tag
は配列になっており、tag[0]
がタグ文字列、tag[1]
がそのタグが付けられた記事情報の配列である。
ここではタグ毎に記事へのリンク付きでタイトルをリスト表示している。これにてタグ一覧ページは完成。
各記事にタグ一覧ページへのリンクを付ける
各ブログ記事にタグ一覧ページへのリンクを付ける。
設定したタグの一覧を出力させるために、ブログ記事のテンプレートとしている_layouts/post.html
に以下のような記述を追加した。
<nav id="tags">
<h2>tags:</h2>
<ul>
{% for tag in page.tags %}
<li><a href="/blog/tags.html#tag_{{ tag }}">{{ tag }}</a></li>
{% endfor %}
</ul>
</nav>
page.tags
にその記事で設定したタグ文字列が配列で入っているので、これを使って{% for %}
文を回す(注:site.tags
はハッシュ、page.tags
は文字列の配列である)。
問題点
今回のタグ一覧ページは簡易的なものである。ひとつのページに、すべてのタグとタグが付けられた記事を羅列しているだけで、「JekyllのPagination設定 」でやったようなページ分けもない。したがって、記事数が増えるごとにどんどん肥大化していくという問題がある。
それほど頻繁にブログを更新するわけでもなし、増えてきたら増えてきたでまたそのとき考えるということで、今回はこれまで。
2013年11月20日, 編集履歴
このウェブサイトは現在GitHub Pages でホストされている。
なにも設定していない場合、404ページ——すなわち存在しないURLをリクエストされたときに表示するページは、GitHub Pagesのディフォルト404ページになる。ディフォルト404ページは、このウェブサイト自体とは直接関連のない情報を表示するだけなので、そのままでは都合が悪い。最低限、このウェブサイトのトップページへ誘導するリンクくらいは置いておくべきだろう。
GitHub Pagesではもちろん、自分で404ページを用意することができる。参照情報はGitHub Pagesのヘルプ「Custom 404 Pages 」にある。
一言で言えば、ウェブサイトを管理するリポジトリィのルートに404.html
というファイルを配置すれば良い。そうすれば、存在しないURLへのリクエストが発生したときにそのファイルが表示されるようになる。
というわけで404.html
を配置した。
2013年11月18日, 編集履歴
Jekyllのsite
変数はposts
とrelated_posts
メンバを持つ。posts
は全ブログ記事が新しい順に入っており、related_posts
は処理中のブログ記事に関連している記事が最大10件分入っている。
<ul>
{% for post in site.posts limit:5 %}
<li><a href="{{ post.url }}">{{ post.title }}</a></li>
{% endfor %}
</ul>
のように書くと、最新のブログ記事へのリンクを5件、リストに出力する。ポイントはfor
文のlimit:5
。site.posts
には全記事分の情報が入っているので、limit:5
のようにすると5件に制限できる。
related_posts
も同じような使い方ができる。しかし、ディフォルトではrelated_posts
には単に最新記事が10件分入っているだけである。ビルド時に--lsi
オプションを付けると精度が上がるらしいが、どういうアルゴリズムになっているのかはよく解らない。さらにこのウェブサイトはGitHub Pages上でのビルドとホストしているが、その場合は--lsi
オプションは使えない(ローカルでビルドして、その生成物をアップロードする方法ならば可)。
ディフォルトでも、せめて同じカテゴリィや同じタグを付けた記事が入っていれば使いようがあるのだが……。
2013年11月17日, 編集履歴
JekyllのPagination とは、一ページ中にブログ記事がいくつか羅列してあり、一番下まで行くと「前の記事へ」「次の記事へ」などと前後の記事羅列ページへのリンクが貼ってあり、当該前後ページでまた記事が羅列されているという、よくあるアレである。
_config.yml
の設定
Paginationを設定するにはまず_config.yml
に、
paginate: 5
paginate_path: "blog/page:num"
のように記述する。上記の場合、一ページ中に羅列される記事数は5件。paginate_path: "blog/page:num"
で指定したblog
ディレクトリィの中にあるindex.html
ファイルが最初のページとなる。blog/index.html
内では変数paginator
を使い、記事羅列ページを作成する(したがって、blog/index.html
はJekyll(Liquid)の変換対象ファイルでなければならないので、YAML Front-matterが必要となる)。
以降のページは、そのblog/index.html
がテンプレート的な扱いとなり、blog/page2/index.html
、blog/page3/index.html
、…と作られる(page1
は作られないことに注意)。
記事の出力
paginator
はposts
変数を持っており、そのページ内で羅列される件数分(この場合は5件)の記事情報が保持されている。blog/index.html
内で以下のように記述すれば、5件分の記事が出力される。
{% for post in paginator.posts %}
<article>
<p class="date">{{ post.date | date: "%Y年%m月%d日" }}</p>
<h1><a href="{{ post.url }}">{{ post.title }}</a></h1>
{{ post.content }}
</article>
{% endfor %}
上記は各記事の全文を出力している。全文が必要ない場合はpost.content
の代わりにpost.excerpt
を使う。
blog/page2/index.html
以降ではblog/index.html
がテンプレート的に使われて同じ形態のファイルが出力される。paginator.posts
には、そのページが出力するべき記事情報が入っている。全記事数が12件でpaginate: 5
指定の場合、最初のページ(blog/index.html
)では最新5件分、2ページ目(blog/page2/index.html
)で次の5件分、3ページ目(blog/page3/index.html
)で最後の2件分がpaginator.posts
に入っている。paginator
が持つその他の変数も出力するページにあわせて変化する。
前後ページへのリンク出力
前後ページへのリンクにはpaginator.previous_page
、paginator.next_page
を使う。これらには前後のページ番号(なければnil
)が入っている。以下のようにblog/index.html
に書いた場合、前後ページへのリンクのリストが出力される。
<ul>
{% if paginator.previous_page %}<li><a href="/blog/{% if paginator.previous_page != 1 %}page{{ paginator.previous_page }}/{% endif %}">前の記事</a></li>{% endif %}
{% if paginator.next_page %}<li><a href="/blog/page{{ paginator.next_page }}/">次の記事</a></li>{% endif %}
</ul>
ひとつ注意が必要なのは、2ページ目以降のパスはblog/page2/index.html
、…であるが、最初のページのパスはblog/index.html
であって、blog/page1/index.html
ではないということである。したがって、paginator.previous_page
が1
のときとそれ以外で処理を分ける必要がある。
追記(2013年11月30日)
前節「前後ページへのリンク出力」について、previous_page
は日付上では新しい方向のページ番号を、next_page
は古い方向のページ番号を意味する。前節のように、変数名に合わせてそれぞれのリンク文字列を「前の〜」「次の〜」とすると、(考え方にもよるが、私は)気持ち悪い。
なので、リンク文字列をそれぞれ「新しい〜」「古い〜」と改めた。
<ul>
{% if paginator.previous_page %}<li><a href="/blog/{% if paginator.previous_page != 1 %}page{{ paginator.previous_page }}/{% endif %}">新しい記事</a></li>{% endif %}
{% if paginator.next_page %}<li><a href="/blog/page{{ paginator.next_page }}/">古い記事</a></li>{% endif %}
</ul>
2013年11月13日, 編集履歴
Jekyllを使ってウェブサイトとブログの再構築をした 。その際に用いたMarkdown用の設定メモ。
現時点での_config.yml
ファイルのMarkdown関係の設定は以下。
markdown: redcarpet
redcarpet:
extensions: ["autolink", "hard_wrap"]
生の設定ファイルはgenjiapp.github.io/_config.yml at master 。
Markdownレンダラの変更
JekyllのディフォルトのMarkdownレンダラはMaruku。これをRedcarpetに変更した。なぜ変更したか。きっかけは、MarukuではTwitterの埋め込みコード(以下のようなもの)
<blockquote class="twitter-tweet"><p>ヘウレーカ! JekyllでコンテンツをHTMLで書いて良いことと、レイアウト側だけではなくコンテンツ側でも include が使えることに気がついて、蒙が啓けた気がする</p>— Genji (@genji_tw) <a href="https://twitter.com/genji_tw/statuses/398471861828206592">November 7, 2013</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
がうまく変換できずエラーを吐くことに気がついたから。_config.yml
でmarkdown: redcarpet
と指定することで、MarkdownレンダラをMarukuからRedcarpetに変更できる。Redcarpetなら上記の埋め込みコードを正常に処理できる。
Redcarpetの拡張設定
指定した拡張はautolink
、hard_wrap
の2つ。
autolink
は http://genjiapp.com/ のような文字列を自動でリンクに変換してくれる。
次にhard_wrap
。Markdownは標準では空行を挿入しないと改段落にならない(ブラウザでの表示で行分けされない)。つまり、
とMarkdownを書くと、変換後のHTMLは
<p>あめんぼあかいなあいうえお</p>
<p>ほげほげ</p>
のようになる。Markdown上での単なる改行は改段落とはならずひとつの<p>
タグに纏められ(「あめんぼあかいなあいうえお」が一行で表示される)、空行を挟んで新しい<p>
タグが始まる。これは他の軽量マークアップ言語でもよくある仕様である。個人的な趣味でこの仕様があまり好きではない。
hard_wrap
を有効にすると上記のMarkdownは
<p>あめんぼあかいな<br/>あいうえお</p>
<p>ほげほげ</p>
のように変換される。Markdown上での改行が変換後に改段落されないのは同様であるが、改行部分に<br/>
タグが挿入されるようになる(ブラウザでの表示において行分けされる)。
HTMLの<p>
タグひとつが日本語の意味段落に相当し、形式段落を<br/>
で作るというイメージである。
追記(2013年11月18日)
当初、Redcarpetの拡張設定はもうひとつ、no_intra_emphasis
を指定していた。そして記事中では以下のようなことを書いた。
Markdownは標準では複数のアンダーバー_
間の文字列をHTML変換時に強調タグ<em>
でくくる。これの何が問題かというと、プログラムの変数名等でありがちなhoge_foo_bar
のような文字列が意図せず強調されてしまう。no_intra_emphasis
はその動作を抑制する。
Markdownの強調構文にはアンダーバーを使う方法ともうひとつ、アスタリスク*
を使う方法がある。ここで私が誤解していたのが、no_intra_emphasis
はアンダーバーを使う強調構文のみが対象であると思い込んでいたことである。しかしno_intra_emphasis
はアスタリスクを使う構文でも同様に作用する。
これの何が問題かというと、分かち書きをしない日本語文中では、余分な空白を入れないと強調構文が使えなくなるということである。つまり、
と書いても、
と出力される。強調構文にするには、余分な空白を挿入して
としなければならなくなる。そうすると出力にも当然余分な空白が入り込む。それはイヤなのでno_intra_emphasis
は外すことにした。
プログラムの変数名等でアンダーバーが意図しない強調になってしまうという問題は、インラインコード/コードブロック構文中なら関係ないと気づいた。コード片を書くときは元々インラインコード/コードブロック構文を使っていたので、そもそもno_intra_emphasis
は必要ないという結論に至った。