新しいエディター Gutenberg 1.8 の新機能として Block templates という概念が紹介された。これにより、ある投稿タイプに対して特定のテンプレートを設定した状態でスタートすることができる。
添付した画像では、Bookというカスタム投稿タイプが以下のブロックをすでに持っている状態で始まっていることがわかる。
- タイトル
- 画像（おそらく、書影）
- 著者名
- 本についての説明
これはカスタムフィールド製造業界で想定される利用方法とかなり近い。少なくとも、新規プロジェクトにおいては、新しい編集体験をもたらし、プロジェクトを良い方向に導くだろう。
既存のプロジェクトは、俺たち／私たちのカスタムフィールドはどうなる？
じつはWP TAVERNの記事 “Gutenberg 1.8 Adds Greater Extensibility for Plugin Developers” ではすでにこの Block templates への反対意見（？）も出ている。
Judging by the book custom post type example, it seems that the author field is being stored inside the post content, instead of a separate meta field or taxonomy. In my opinion, this is a terrible decision, because one cannot, for example, query books by author this way.
これは要するに「ぱっと見はできているように見えるけど、投稿本文に保存してるから、メタクエリで著者名検索とかできないよ」ということなのだが、実のところ、考え方を変えれば済む話であり、カスタムフィールドやタクソノミーなどの投稿メタ情報（ex. 投稿ID9は著者タクソノミー10に紐づく）はいままで通りメタデータとして保存すればよく、投稿本文（post_content）はその出力結果と考えれば済む話ではある。実際、ブロックの情報源としてカスタムフィールドを使うAPIは実装済みである。
とはいえ、こうした反対意見に対して同情すべきなのは、投稿本文はその投稿オブジェクトのメタ情報などを含んだ情報すべての出力結果であるという概念が若干高度で分かりづらいという点だ。Advanced Custom Fieldsのようなプラグインはそうした「高度な概念」を直感的にわかりやすくしてくれた点に普及の秘訣があったので、今後こうした情報の強度をどれだけブレークダウンできるかが重要になってくるだろう。
また、現時点でACFを有効化するとGutenbergは壊れてしまうので、これはなんというか、プラグイン作者の頑張りに期待するしかない。
なにはともあれ、Gutenbergの開発進捗では、カスタムフィールド製造業界の住人にはまだまだ目が離せない展開が続きそうだ。引き続き注視していきたい。
コメントを残す