メニュー

ルーティング

ページ -> フォルダのセクション の最初の方で説明したとおり、 Grav の ルーティング は、主にサイトのコンテンツを作る際のフォルダ構造から決まります。

しかし、もう少し柔軟性が欲しいときもあります。
この点について、より便利になるように、 Grav には多様なツールと設定オプションが用意されています。

ここで、他の CMS から Grav へサイト移転する状況を思い浮かべてください。
新しいサイトを立ち上げるのに、いくつかの選択肢があります。

  1. フォルダ構造を一致させることで、古いサイトと同じ URL を複製する
  2. 新サイトは好きなように作成し、 web サーバーの「リライト」機能で、古い URL から新しい URL へリダイレクトする
  3. 新サイトは好きなように作成し、 Grav の設定で、古い URL から新しい URL へリダイレクトする

フォルダ構造とは違う URL に対応させたい状況は、ほかにもたくさんあるでしょう。
Grav では、その目的を達成するための以下のような機能があります。

ページレベルのルーティングとリダイレクト

ヘッダー -> Routesのセクション で概要を示したとおり、default ルーティング設定 や、ルーティングの aliases の配列により、 ルーティングのオプションを明示することができます。

routes:
  default: '/my/example/page'
  canonical: '/canonical/url/alias'
  aliases:
    - '/some/other/route'
    - '/can-be-any-valid-slug'

これらは、ページごとに処理され、キャッシュされます。
そしてこれらは、 素のルーティング と一緒に扱われます。
素のルーティングとは、 Grav がデフォルトで機能する、ページ階層をもとにした スラッグ を基礎とするルーティングのことです。
よって、カスタムのルーティングを提供したとしても、素のルーティング は、そのまま利用可能です。

ページレベルのルーティングと似ていますが、 Grav ではページのフロントマターに対象ページを指定することで、ページレベルのリダイレクトに対応しています。
より詳しくは、ヘッダー -> Redirect のセクション をご覧ください。

redirect: '/some/custom/route[303]'

サイトレベルのルーティングとリダイレクト

Grav には、強力な正規表現ベースの 別名ルーティング 機能と、あるページから別のページへの リダイレクト 機能が備わっています。
この機能は、 Grav へサイトを引っ越しするような場面で、古い URL を新サイトでも使わなくては行けない場合に、特に便利です。
これはしばしば、 web サーバの rewrite rules によって達成されることですが、ときには、 Grav の制御でやってしまったほうが、便利で柔軟であることがあります。

これらは、サイト設定 によって設定します。
Grav は、サンプル設定として system/config/site.yaml を提供しますが、user/config/site.yaml を編集することで、これらを上書きし、独自の設定を付け加えることができます。

[!Info]
(多言語サイトとする場合)すべてのリダイレクトするルールは、言語部分の後から始まるスラッグ部分に適用されます。

[!Warning]
特定の文字は、あらゆるルーティングにおいて、エスケープされなければいけません。このことは、サイトを引っ越すときに、古いサイトが伝統的なファイル拡張子を利用していた場合(たとえば .php )や、 URL パラメータを利用していた場合(たとえば ?foo=bar )に、とくに重要です。これらの例では、ピリオドやクエスチョンマークは、 /index\.php\?foo=bar: '/new/location' というように、エスケープしなければいけません

ルーティングのエイリアス(別名)

シンプルなエイリアス

最も基本的な別名の種類は、1対1になるように対応させるものです。
site.yaml ファイルの routes: セクションでは、別名と、実際に使われるルーティングを対応させたリストを作成できます。

[!Info]
これらの別名は、そのルーティングファイルが見つからなかったときのみ利用されることに注意してください。

routes:
  /something/else: '/blog/focus-and-blur'

もし、 http://mysite.com/something/else にリクエストが来て、そしてそれにデフォルトで対応するページが無い場合に、このルーティングは、 /blog/focus-and-blur にあるページに決定されます。
これは実質的には閲覧者をこのページへ リダイレクトした のではありません。
単に、別名のページを表示しただけです。

[!Info]
ここでのインデントは重要です。もし無ければ、ルーティングのリダイレクトは機能しません。

正規表現による別名

別名によるリダイレクトのより高度な種類では、別名の一部にシンプルな 正規表現 を使うことができます。たとえば:

routes:
   /another/(.*): '/blog/$1'

これは別名からワイルドカードでルーティングします。
よって、 http://mysite.com/another/focus-and-blur というリクエストのとき、実際は /blog/focus-and-blur にあるページが表示されます。
これはひとつの URL の集合を別のところへ組み合わせるのに、パワフルな方法です。
WordPress から Grav への移動にも、とても良いでしょう:)

すべての別名を集めて、特定のルーティングに対応させることもできます:

routes:
  /one-ring/(.*): '/blog/sunshine-in-the-hills'

上記の別名ルーティングでは、 /one-ring/to-rule-them-all/one-ring/is-mine.html のようなワイルドカードにマッチするすべての URL について、 /blog/sunshine-in-the-hills のルーティングのページからコンテンツが表示されます。

よりクリエイティブに、複数対応させたり、任意の正規表現の構文を使うこともできます。

routes:
  /complex/(category|section)/(.*): /blog/$1/folder/$2

これは、次のように書き換えられます:

/complex/category/article-1      -> /blog/category/folder/article-1
/complex/section/article-2.html  -> /blog/section/folder/article-2.html

このルーティングは、 complex/categorycomplex/section で始まっていないものには適合しません。より詳しい情報は、 Regexr.com で、正規表現を学び、テストする素晴らしい方法を提供しています。

リダイレクト

別名によるルーティング とは別系統の選択肢としては、リダイレクト による方法があります。
これらは似ていますが、 URL がそのままでコンテンツのみ別名のページから持ってくるのではなく、ブラウザを対応したページへリダイレクトさせる点で違います。

リダイレクトするため、システムレベルでは3つの設定オプションがあります:

pages:
  redirect_default_route: false
  redirect_default_code: 302
  redirect_trailing_slash: true
  • redirect_default_route Grav が自動的にページのデフォルトのルーティングへリダイレクトできるようにします。
  • redirect_default_code デフォルトのHTTPリダイレクトコードを指定できます:
    • 301: 恒久的なリダイレクトです。このリソースに対してそれ以降リクエストを行うクライアントは、新しい URI を使うべきです。 POST/PUT/DELETE リクエストに対しては、自動リダイレクトを行うべきではありません。
    • 302: 未定義の理由によるリダイレクトです。このリソースに対してそれ以降リクエストを行うクライアントは、新しい URL を使うべきではありません。 POST/PUT/DELETE リクエストに対しては、自動リダイレクトを行うべきではありません。
    • 303: 未定義の理由によるリダイレクトです。通常、 ‘処理は完了したので、他の場所へ続けてください’ という状況です。このリソースに対してそれ以降リクエストを行うクライアントは、新しい URL を使うべきではありません。クライアントは、 POST/PUT/DELETE リクエストのリダイレクトに従うべきです。
    • 307: 一時的なリダイレクトです。リソースは、あとでこの場所に戻ってくるかもしれません。その後にこのリソースにリクエストを行うクライアントは、古い URL を使うべきです。 POST/PUT/DELETE リクエストに対しては、自動リダイレクトを行うべきではありません。
  • redirect_trailing_slash 現在の URL から末尾スラッシュ無しの URL へリダイレクトするオプションです。

たとえば:

redirects:
    /jungle: '/blog/the-urban-jungle'

URL部分に各カッコ[] で囲むことで、リダイレクトコードを指定することもできます:

redirects:
    /jungle: '/blog/the-urban-jungle[303]'

もし、 http://mysite.com/jungle をブラウザで表示するとき、リダイレクトされ、次のページに行き着きます: http://mysite.com/blog/the-urban-jungle

ルーティングエイリアスにあったものと同じ正規表現機能が、リダイレクトにもあります。たとえば:

redirects:
    /redirect-test/(.*): /$1
    /complex/(category|section)/(.*): /blog/$1/folder/$2

これらは、ルーティングエイリアスとほとんど同じようですが、透過的に新しいページを表示するのではなく、 Grav は実際にブラウザをリダイレクトし、ページを新しく読み込みます。

ホームへのルーティングを隠す

system.yaml ファイルに、サイトのホームとしたいページをセットできます:

home:
  alias: '/home'

/ へのルーティングを、このページの別名として設定しています。
つまり、/ へのリクエストがあったとき、 Grav はそのページを表示します。

しかしながら、 Grav は、このホームページ以下のページについては、何もしません。
このため、ブログ投稿の一覧を表示するページとして、/blog というページがあり、このページをホームページに設定したとき、これは期待通り動きます。
しかし、ブログ投稿のリンクをクリックすると、URLは /blog/my-blog-post になります。
これは期待される通りの動作ですが、あなたが意図するところとは違うかもしれません。
system.yaml によって、この URL から、トップレベルの/blog を隠す選択ができます。

このような動作は、次のように変更できます:

home:
  hide_in_urls: true

[!訳注]
ここで言われているのは、 home.alias: '/blog' かつ home.hide_in_urls: true にしたとき、 Grav が自動生成し、 twig 上に出力されるリンク URL が /my-blog-post になるということです。 /blog/my-blog-post 自体が非表示になったり無くなったりするのではなく、直接ブラウザ表示すれば、ページは表示されます。