こういう細かい話とかが意外と共有されて無さそうなので気をつけてることを思いつく限りつらつらと。
テンプレートのトップレベルには、グループブロックを配置しその中に要素を設置する。
Twitter でも書きましたが、トップレベルにはグループブロックが必要です。基本的にはグループブロックがサイトの横幅を制御しています。CSS とかで横幅の制御を自前でやっても管理画面では崩れたり、幅広や全幅が正しく動作しなかったりします。
Twenty Twenty-Five だとこんな感じです。main タグがそれに当たります。
<!-- wp:template-part {"slug":"header"} /-->
<!-- wp:group {"tagName":"main","style":{"spacing":{"margin":{"top":"var:preset|spacing|60"}}},"layout":{"type":"constrained"}} -->
<main class="wp-block-group" style="margin-top:var(--wp--preset--spacing--60)">
<!-- wp:query-title {"type":"archive"} /-->
<!-- wp:term-description /-->
<!-- wp:pattern {"slug":"twentytwentyfive/template-query-loop"} /-->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer"} /-->テンプレートや、テンプレートパーツの要素は基本的に「コンテント幅を使用するインナーブロック」が有効になっている （"layout":{"type":"constrained"}が設定されている）グループブロックの子要素になるものと考えればよいと思います。
CSS の記述は極力避けて、ブロックの設定でスタイリングを行う。
エディター側でスタイルを変更する機能が結構沢山あるんですが、「エディタで変更したのにスタイルが当たらない」とかの問題を引き起こしがち。また、最近は少なくなった気がしますが、WordPress のアップデートで CSS のセレクタの優先度やセレクタそのものが変更されることもあったりするので、その際にアップデートを困難にする一つの要因になります。
それでも CSS を記述する場合も当然存在します。その際は「WordPress が提供してるスタイルを上書きして塗り替える」的なアプローチより、「WordPress に足りないスタイルをちょい足しする」みたいなスタンスで付き合うのが良いのかなと。
また、html 要素に対して、font-size: 62.25% とかを設定するのも避けたいです。最近だとエディタが iframe になったのでデメリットが減りましたが、管理画面でのルート要素とフロントエンド側側でのルート要素に当たるスタイルが一致しないとかで不具合を引き起こしたりします。
body_class, post_class や、親 class 等に依存しない。どこに置いても同じような見た目になるようにする。
ブロックエディタになって、コンテンツのレイアウト編集等も容易になりました。ブラウザで複数のタブを開いてブロックをコピー & ペーストしたり、ブロックパターンを用いたりなどで、一度作ったブロックの設定やその組み合わせを使い回したりも容易になりました。
その際に、同じブロックが「投稿」と「ページ」はもちろん、ヘッダー、やフッターでも同じスタイルが適用されるのが良いです。自動的にいい感じにしてくれるってのは一見便利そうですが、大抵運用時などに、「〇〇の時は~」等の条件等を理解する必要が出てきたり、その条件なども忘れ去られがちです。開発時にはいちいち設定する必要がなくて便利なのかもしれませんが、エディタってある意味では「いちいち設定」をするための機能なので、この辺は長期的に見てあんまり上手くいってるケース少ないなと思ってます。
The Zen of Python で語られる「暗黙より明示のほうが良い ( Explicit is better than implicit. )」という考え方がありますが、これはテーマ開発や CSS とかの開発でも広く適用出来る話なのかなと。
妥協しても 最低 95% くらいは、エディタでの見た目と実際の表示を一致させる
「ブロックエディタで編集しやすくなった」といっても、小まめにプレビューを確認するのであれば意味無いですし、結局ただ設定項目がいっぱいある複雑なエディタ、みたいなことになります。WYSIWYG は「What You See Is What You Get」のアクロニムで「見たままが得られる」ということです。Word とか PowerPoint とか Pages とか Keynote とかその辺も、WYSIWYG です。「結局保存してプレビューやら PDF にしてみないとわからないよね」となってしまうとそれらって使いものにならないですよね。
別に全部が WYSIWYG である必要は無いし、Markdown から生成したりするものもいっぱいあるご時世、中途半端な WYSIWYG って実装コストと実際に提供している価値のバランスが見合ってないと感じます。WYSIWYG にちゃんとこだわるのが使いやすい WordPress サイトの価値に繋がるのかなと。
ナビゲーションブロックの使い所
「ナビゲーションブロックをどこで使うのか」は色々難しいところですが、今のところ、ヘッダー等のグローバルナビゲーション等に使うだけで良いのかなと。ナビゲーションブロック固有の機能を使わない箇所に使うのはちょっとオーバースペックかなと。
例えば、フッターなどにある、サイトのコンテンツへのリンク等が付くことはよくありますがこの辺は、単純にリストや段落ブロックで記述してリンクを設定し。テンプレートパーツやパターンで管理するので十分かなと。
ブロックテーマの場合、「テーマ編集権限 = ナビゲーション編集権限」と考えて差し支えないです。( https://wordpress.org/documentation/article/roles-and-capabilities/#side-editor-capabilities ) なのでその前提のもと、フッターなどを編集してもらったりするのがわかりやすいのではないかなと。
またエクスポートなどで複数のナビゲーションが存在すると面倒だったりするので、「テーマ側ではナビゲーションは基本的には１つだけ」と思って使うのが面倒が少ないと思います。
おわりに
この辺のノウハウとかって調べづらいなぁと改めて感じた次第です。ちょくちょく棚卸ししないとなと思いました。
この辺を押さえるのは既存のブロックテーマを触ってるだけだとなかなか気付きづらい部分が多いので、Twenty Twenty-Five や WordPress 7.2 でリリース予定の Ipsum なんかを眺めながら、自前でシンプルなテーマを作るのが一番勉強になるな改めてと感じました。その際は公式のTheme Test Data を使ってそれらがいい感じに動くようにするのが学習としてはよいかなと思います。