Grav 1.7の安定版が2021/1/19にリリースされるようだ。Grav 2.0に向けて大幅な更新が行われているようで、この中には後方互換性を損なうものも含まれている。20ものRelease Candidateを経た大規模更新によって何が変わったのかをレビューしていく。
手元のデバッグ用の環境でuser/config/system.yamlのgpm releaseをstableからtestingに変更することによってGrav 1.7を試すことが出来る。そうしなくてもじきにこの1.7rc20はstableとしてリリースされる。adminパネルからのアップデートはキャッシュとかの関係で極めて不安定なのでCLI/gpmからアップデートするのが良いだろう。
このようにして作ったGrav 1.7の環境を実際に動かしてみて、追加された機能をレビューしていこうと思う。まだ試していないものもあるが、それについては適当な所感を示そう。
webpとlazyloadingのサポート
これは大きい。webp形式での画像配信はPagespeed insightsやweb.devの診断で必ず指摘される項目だ。以前のバージョンのGravでもメディアタイプにwebpを追加しておけばwebp形式での画像配信は可能だったが、改めてサポートされるのは喜ぶべきことだ。
lazyloadingについても同じく、Pagespped insightsなどでFCPの改善のためによく用いられる方法であり、これが正式にサポートされるのは嬉しい。以前でもプラグインからlazysizesを使って画像の遅延読み込みを行うことはできたが、どうしても使い勝手が微妙だった（残念ながら何が微妙だったかは今現在すぐに思い出せないが、何かしらが微妙だったためカスタムテーマからjsを忍ばせてmarkdownに画像タグ直接書きでlazysizesの遅延読み込みを利用している経緯がある）。
まだ実際にどのようにサポートされたのかは確認していないが、前向きな変化だといえるだろう。
もっと望ましいのはimgタグに適切なwidthとheightを指定してくれる機能だ。Cumulative layout shiftというキーワードを調べるとすぐにわかるように、近年ではimgタグにこれらの属性を指定してプレイスホルダーの役割を果たさせることがスタンダードとなっている。ユーザしてんでも遅延読み込みされた画像でテキストが押しのけられてどこを読んでいたのかわからなくなる現象は煩わしいだろうから、このスタンダードには強く同意できる。altだけ重要と言われていたのはもう古い。今後の更新に期待したい。
twigで{% cache %}が使える
https://twig.symfony.com/doc/3.x/tags/cache.html
このページにあるとおり、Twigの3.2で新しく追加されたタグだ。これによって以前はtwigcacheというプラグインが果たしていた役割をTwigの機能で直接的に行うことができて、結果としてキャッシュまわりのパフォーマンスが向上するようだ。パフォーマンスが向上するといわれれば使いたくなるものだが、そもそもtwig事体キャッシュをある程度前提としている形式なのでテンプレートの指示によるキャッシュがどの程度有効なのかはわからない。
極端な話リクエスト名によってベーステンプレートをまるまる囲ってしまったらtwigのみで静的キャッシュが実現するのかと考えてしまうが、まるまる囲って効果のあるキャッシュならこんなタグとか導入するまえに勝手に実装されるだろう。
よって今のところの使いどころは得に思い当たらない。Grav 1.7にともなってデフォルトのテーマのテンプレートなどがアップデートされてくればこのタグの使い方もある程度分かるようになるだろうから、それを待って自分のカスタムテーマに反映することにしようと思う。
svg画像のサポート
svg_image()というTwig関数が導入されたようだ。svg画像はベクタ形式の画像配信形式としてよく使う。このサイトのロゴもsvgだ。しかしTwig関数でincludeを代替するという導入の仕方はよくわからない。sanitizeとあるからweb的にいらない部分はそぎ落としてくれそうな雰囲気がするのはありがたい。
markdownからインラインにsvg画像を展開してくれる機能があればよかったのだが、これはmarkdownのフロントマターでprocess/twig/trueにしておいて{{ svg_image('page://hoge.svg') }}を使えということなのだろうか。マークダウンで画像を読み込みときの?以降にinline指定で同じことができると良かったのだがそうではないようなのが残念だ。今後に期待したい。
page collectionの挙動
細かい話だが、ページコレクションの挙動が少し変わっている。具体的にはlimitで対象ページ未満の数を指定してpagenationをfalseにしたときに全てのページが表示されるようになっている。
以前の挙動ではcollections|slice(0, limit)が返されていたがスライスが適用されない状態になっている。limitというパラメータがpagenation: trueありきになってしまい、そうでないときlimitというパラメータは死んでしまっている。これは複数のコレクションを持つページにとっては都合が非常にわるい。単なるバグなのか、しかしあえて挙動が変わったということはこれが仕様なのか。
別にテーマ側で対応できるので問題は無いが、面食らってしまった。Archiveプラグインの最新版がなぜか動かないバグといいそのへんは対応してもらいたいところ。
デリケートなdebug情報の秘匿
これは明らかな改善だ。やむを得ず本番環境（=インターネットに晒されている）でデバッグ機能を使いたい場合にデリケートな情報を秘匿化することができる。本番環境でデバッグなどオンにすることはそもそも無いと思われるが、かならず設定しておくべき項目といえるだろう。
Flex Objectsとやら
よくわかっていないが、現在使っていないModularと同じくやや迷走気味の機能であるように思う。カスタムテーマを書いている人からするとまず想定される使い方よくわかってないんだろうと思う。DrupalのViewsがわけわかんなかったのと同じで、使いこなすと便利なのだろうが使わなくてもやりたいことが出来ていると何であるのか、なんでそんなにFlexと言われているのかわからない。
よって当面は無視でよいだろう。うまくつかっているテーマが現れてきたら真似してみることにしよう。
GRAV Premiumとやら
有料のテーマとかが使えるというものがGrav 1.7のリリースのあたりの時期にいわれるようになってきた。おそらく使わないだろう。カスタムテーマをごりごり書いているものからすると使う意味を感じないのは当然のことだ。ウィシウィグエディタもそもそも使用していないため、いくら機能強化されても使うことなないだろうと思う。
元来Gravは生成するHTMLの一字一句まで自分でコントロールできる、限りなく静的ファイルサイトに近くてかつCMSなのでテンプレート的な部分を一貫して取り扱いえるところに魅力がある（と思っている）。別で述べたところかもしれないが、最適化をしていない素のGravサイトはPagespeed insightsなどの計測サイトでテストしてもWordpressサイトと比べてそんなに速い数値は出ない。少なくとも自分の知る使い方の範囲ではそうだ。原因はサイトスピードの観点で足をひっぱるプラグインやテーマが多く出回っているからで、それらを使っている限りいくらAdminパネルからキャッシュの設定などいじっていてもできることには限界があるのだ。
そういう問題のあるプラグインやテーマには公式マーク付きのものも多分に含まれている。それらを放置しておきながらいきなりプレミアムだとかSEOマジックだとか言われても「いや自分でやるわ」となるのである。
だからtwigやphpを自分で編集することは必須であり醍醐味だ。Gravはそういうユーザを想定して作られていて、APIのリファレンスなどはやや不親切なものの必要なものはそろっている。まあそれでいて欲しい機能がないといったことはよくあるのだがそれも込でまあ今後に期待したい。特にサーバサイドでいろいろやって静的に配信といったことが概ねできない。ただしそこも載せているサーバの制約であってそれがなければ十分に可能なものばかりだ。それくらい柔軟性がある。
まとめ
Grav 1.7から話がそれたが以上。phpstan関連がブラッシュアップされただけでもスピード狂としてはアップデートする価値はあると思った。何か追加で思うことがあれば加筆したい。