Gutenbergのcustom blockはthemeを替える前に内容と見た目が残るかを分けて確認する

Gutenbergで独自のblockを作れば、よく使う案内や見せ方を編集画面へ加えられる。だが、そのblockをthemeの中へ入れると、themeを替えたときに何が残るかが問題になる。本文、画像、link、問い合わせ先のような内容はsiteの資産であり、themeの見た目と一緒に失わないように分けて考える。

WordPress Themesの3月7日の議論では、Gutenbergのcustom blockをthemeへ含めることについて、theme変更後にcustom styleが失われることや、利用者がblockを使えなくなることへの懸念が示された。この時点ではGutenbergをcoreへ入れる正確な日も決まっていない。だから、特定のthemeでだけ意味が通るblockを、公開中の重要pageへすぐ広げない。

内容と見た目と機能を三つに分ける

themeを替えるときに残したいものを、まず三つに分ける。第一は内容である。見出し、本文、画像の説明、link先、価格、営業時間、問い合わせ先がここに入る。第二は見た目である。文字の大きさ、余白、背景色、枠、画像の切り方、二列の配置がここに入る。第三は機能である。予約の送信、一覧の絞り込み、地図の表示、会員だけへ見せる処理のように、画面の外で動くものがここに入る。

この三つを一つのcustom blockへまとめると、themeを替えたときに原因を分けられない。たとえば、サービス案内のblockに本文、背景画像、問い合わせbutton、送信先の設定まで入っているとする。新しいthemeで背景が消えたのか、buttonの色だけが変わったのか、link先まで失われたのかを、利用者は判断しにくい。内容まで消えれば、見た目の変更では済まない。

そこで、最初に内容を普通の段落、見出し、画像、linkとして読める形で残す。theme固有の装飾は、その内容へ後から加える。予約や問い合わせのように業務を動かす機能は、themeを替えても同じように管理できる場所へ置く。この順番なら、見た目が崩れても、読者に必要な説明と連絡先は残る。

theme固有のblockに判断材料を閉じ込めない

theme固有のblockが役立つ場面はある。季節の飾り、特定のheaderに合わせた案内、限られたpageで使う装飾は、そのthemeと一緒に入れ替わってもよい場合がある。しかし、事業の説明、商品条件、料金、申込みの入口までtheme固有の形へ閉じ込めると、themeを選び直す自由が小さくなる。

たとえば、背景画像と大きな文字でサービスを見せるblockを作る場合を考える。blockの中にある文章を新しいthemeでも段落として読めるなら、失われるのは主に見た目である。これなら、theme変更後に余白や文字色を直す作業を見積もれる。一方で、独自のblockが読み込まれなければ本文も表示されず、問い合わせbuttonのURLも出ないなら、siteの内容をthemeが抱え込んでいる。

判断材料を残すために、pageの本文だけで条件が読めるようにする。buttonは目立つ入口として置いてよいが、buttonだけに重要な説明を入れない。画像内の文字だけで料金や受付時間を伝えない。theme固有のblockが使えない画面でも、読者が何を頼めるか、どこへ連絡するかを分かるようにする。

この考え方は、themeをすぐ替える予定がないsiteにも必要である。制作した人がいなくなったり、themeの更新で表示が変わったりすると、後から初めて依存関係に気付く。作るときに内容を分けておけば、themeを所有しているのか、siteの内容を所有しているのかを混同しない。

変更前に複製したpageで試す

custom blockを試すときは、公開中のpageをそのまま使わない。検証用のsiteか、公開しない複製pageを用意する。そこへ、実際に使う見出し、長めの本文、画像、link、buttonを入れる。短い仮文だけでは、文章が増えたときの崩れや、編集する人が迷う場所を確かめられない。

まず、現在のthemeでpageを開き、本文と操作が意図どおり見えるかを見る。次に、別のthemeへ替えた状態で、同じpageを開く。見出し、段落、画像、caption、link、buttonの行き先、問い合わせ先を順に確認する。見た目が変わっても内容が残るのか、blockを編集できるのか、古いblockのまま残っているのかを記録する。

ここで、themeを削除して試す必要はない。公開siteのthemeを外すことも避ける。目的はthemeを消すことではなく、themeに依存している内容を見つけることだからである。問題が出た場合は、blockを増やして取り繕う前に、内容、style、機能のどれをthemeから外すべきかを決める。

たとえば、styleだけが失われたなら、新しいthemeで読みやすい標準の見た目を決める。link先が失われたなら、linkをblockの設定だけに持たせず、本文のlinkとして残す。独自の予約機能が動かないなら、themeの変更とは別に、その機能の所有者、更新方法、移行の手順を確認する。原因を一つずつ分ければ、theme変更の作業がサイト改修全体へ広がりにくい。

引き継ぐのはfileだけではない

制作会社や担当者からthemeを受け取るとき、zip fileだけを保管しても十分ではない。どのblockがtheme固有なのか、どのpageで使っているのか、themeを替えた場合に何を確認するかを残す。これがなければ、更新する人は怖くてthemeを替えられず、古いまま使い続けることになる。

引継ぎ用の記録には、少なくとも三つを書く。第一に、theme固有のblockの名前と用途。第二に、使っているpageのURL。第三に、theme変更後に確認する内容である。写真の見え方、本文、link、form、管理画面での編集を分けて書く。専門用語を増やすより、誰が見ても何を確認するか分かる表現にする。

themeを替える自由は、見た目の好みだけの問題ではない。保守、速度、更新の都合で変更が必要になることもある。内容と業務の入口をthemeから分けておけば、その判断を先送りせずに済む。Gutenbergのblockを使うときは、編集が便利になることと、siteの所有が保たれることを、同じ条件として確認する。