フルサイト編集対応のブロックテーマを作成した感想
フルサイト編集対応のブロックテーマを作成した感想
信州 WordPress Meetup in 松本 Vol.25に登壇させていただきました。
その時に話した内容のリライト？です。
正直半分くらい愚痴になってるけど悪しからず。
培ってきた知識が転用しづらい
クラッシックテーマからブロックテーマへの変更は、基盤の部分になるテーマファイルの変更もあって既存の構築方法からそこそこ変える必要があった。
ご存じの通り PHP から HTML への変更が大分大きい。
PHPからダイレクトに出力することが難しい
今まで PHP そのものであったテーマファイルが HTML に変更され、殆どの場合 PHP で処理した内容を出力したい場合一度ブロックを経由する必要がある。
ダイナミックブロックであっても編集画面では js を通して画面を作る必要があるため、単純に一行程増えている。
クエリループを書いてコンテンツを出力していた既存の作り方から wp:query 他コアのブロックを使って出力するようになった。
分かればエディタから WP_Query の値を変更できて便利だが、テーマやブロック構築時には書き方を理解するまで時間がかかった。
index.html 等の一覧ページはテーマに直接書けるものの、 front-page.html に投稿のフィードを表示する等の場合はブロックを用意する必要があった。
デザイン次第の部分もあるが、ブロックエディタでのクエリループの作成になると作成したデータがコードに残らないことに不安を感じたため今回は InnerBlocks を使ってテンプレート化して実装することにした。
<div className={ styles.items }>
<InnerBlocks
allowedBlocks={[
"core/query",
]}
template={[
["core/query", {
queryId: 0,
query: {
perPage: 3,
pages: 0,
offset: 0,
postType: "post",
order: "desc",
orderBy: "date",
author: "",
search: "",
exclude: [],
sticky: "",
inherit: false,
"taxQuery":{"category":[5]}
},
}, [
["core/post-template", {
className: "news-items",
}, [
["core/group", {
style: {
spacing: {
blockGap: "var:preset|spacing|50",
},
},
type: "flex",
},
}, [
["core/post-date", {
isLink: true,
}],
["core/post-title", {
isLink: true,
}],
]],
]],
["core/group", {
type: "flex",
},
}, [
["core/button"]
]]
]],
]}
templateLock="all"
/>
</div>core/query の値は WP_Query と似ているためクラッシックテーマを書ける人ならそこまで違和感なく設定できそう。
core のブロックをそのまま使う場合、 HTML の出力の調整がしづらい。
["core/post-date", {
isLink: true,
}],
["core/post-title", {
isLink: true,
}]上記の記述では出力が以下のようになる。
<a href="{permalink}"><time>{YYYY.mm.dd}</time></a>
<a href="{permalink}"><h2>{title}</h2></a>機能的にもマークアップ的にも本来であれば以下のようにしたいが、core のみで作成する場合上手い方法を見つけることができなかった。
<a href="{permalink}">
<time>{YYYY.mm.dd}</time>
<h2>{title}</h2>
</a>core にないのであればカスタムブロックを作成するべきだが、今回は時間がなくて試せなかった。
HTMLの制約がより強くなった
ブロックエディタへの変更ですでに通っている道ではあるが、コンポーネント設計（指向）に寄せた構成の必然性が上がった。
デザインを分業している場合、デザイナーとコーダーの双方がコンポーネント設計への理解が必要になってきた。
特にフリーレイアウトと相性が悪いが、デザイン性を重視する場合の折り合いが見えなかった。
あまりいい手とは思えないが、一部を絶対に変更しないコンポーネントとして画像やレイアウトを丸ごとパッケージ化することで凌いだ。
この辺どうするのが正しいんだろう……。
CSS か themes.json かの選択が難しい
themes.json で定義すると CSS 変数として登録され、global で参照できるようになる。
また、管理画面内の色々な部分で参照されるため、テーマ作成者の CSS と投稿者が設定する値の共通化ができるのがめちゃくちゃ偉い。
ただし、レスポンシブは結局 CSS で定義するため結局なんかとっ散らかった感覚になる。
であれば管理画面では BlockVariation 等で class の付与に徹底し CSS のみで値を管理する方が収まりが良さそう。
構築後の変更に強い
構築時にはかなりの負担を感じたものの、運用フェーズになるとそれなりの恩恵を感じた。
コンテンツ外の修正であってもテキスト修正等の軽微な内容であれば管理画面で数秒で終わり、サーバに接続したファイル更新やテーマファイルエディタでの編集も必要ないため非エンジニアでも抵抗がなく修正ができるのは大きいと思う。
反省点
初めて作ったので割と手探りではあったのだが、それにしてもハンドブックを読み込めていなかった。
特に BlockVariation の使い方が上手くいっていなかったので、改善すれば工数を減らせたかもしれない。
また、別件でカスタムブロックを使った際に感じたが、やり方次第では core, InnerBlocks, BlockVariation だけでカスタムブロックの作成もそこそこカバーできる。
wordpress/data をはじめ優秀な API が用意されているが、そこそこ数が多いためそこが把握できれば効率化やできることの幅が増えそうな予感はしている。
その他
前述の内容と同様だが、ノウハウが蓄積すれば効率良くなりそう。
イベントで指摘された通り、ブロックの使い回しを意識すればより楽ができるのでその辺も改善した。
ただしクラッシックより早くなることはしばらくは難しそうだとは思う。
その場合、出来上がるサイトはクラッシックとブロックで同等なので増加した工数分を誰が負担するのかが難しい。
ブロックテーマのメリットや必然性をもってクライアントを納得させる必要があるのでその辺りの理解も大事だと思うが、ちょっとまだ掴めていない。
テーマ作成の上で React がほぼ必修になったと思う。すでにカスタムブロックで必修に近かった。
必要な知識が増えたため、「インスタントな CMS」というパブリックイメージは明確に否定されたように思う。
とはいえ元々カスタマイズ性が広く適当に扱うと煩雑になりやすくはあったので「インスタントな CMS」ではなかったのだが。
ブロックエディタの時点でそうではあったが、ブロックテーマも技術的にはかなり面白く React が必修になった反面 React さえできればかなり色々なことができる。
正直 WP の用意した API がなければブロックテーマ（エディタ）と同様の仕組みをつくるのはかなりしんどいと思う。
特にテーマ作成者は恩恵が大きそうで、販売テーマでよくある独自のテーマ設定で get_option なんかでフォローしていた部分をブロックで解決できる場面は多いと思う。
一方で保守に入る業者は何とも言えず、ブロックの追加や修正が必要なレベルの変更が入った場合は HTML と CSS を書いた方が早い場面は多い。
これは体感レベルだが、投稿しか触らないクライアントも多く、テーマが編集できる必要がない場面も多い。
正直自分の理解と技術が追いついていない場面が多く、ブロックテーマ自体の評価をするにはまだ全然早いと思うが、いくつかの課題が解決できればユーザの恩恵が大きく運用フェーズに入った後の保守の負担も減らせ双方にメリットがあるため、できれば今後もブロックテーマで作りたいと思った。
とはいえプロジェクト全体での技術要求が大きくなるため、ディレクタやデザイナ等のコーディングとは別行程との連携は殊更重要になった。
そこまでのイニシャルコストを払った上でその恩恵を望むユーザがどれだけいるのかという点でも難しいシステムになっていると思う。
マジで個人的な性根の問題でもあるが、 post_content に HTML を貼り付けただけの構築と同じ費用で作るの嫌だし……。