クライアントに安全なサイトエディター：theme.jsonプレイブック

まとめ

クライアントが初めてWordPressサイトエディターを開くと、すべてのブロック、色、レイアウトを編集できる機能は、彼らにとっては便利なものに感じられますが、あなたにとっては脅威に感じられます。この記事では、コンテンツ編集とデザイン管理の間に明確な線を引くためにtheme.jsonを利用する方法を説明します。サイトエディターと戦うのではなく、技術に詳しくないクライアントでも自分のサイトを安全に更新できるように、プリセット、デフォルト、境界を設定します。何をロックし、何をオープンにすべきか、そして過剰にロックすることが実際のリスクである理由について説明します。このアプローチはデザイントークンとテンプレートレベルの制約に基づいているため、あなたが管理するすべてのクライアントサイトで一貫して機能します。最後には、デザインシステムの鍵を渡さずにサイトエディターを引き渡すための再現可能なワークフローを身につけることができます。

クライアントから「見出しを更新しようとしただけなのに」というメールが届き、サイト全体の余白が崩れてしまったとき、あなたはまず何をしますか？

複数のWordPressサイトを管理しているなら、何らかの形でそんなメッセージを受け取ったことがあるでしょう。サイトエディターは、クライアントに5速シフトでブレーキのない車の鍵を渡すようなものです。彼らは単純なテキスト変更だと思っているのに、突然グローバルなタイポグラフィが崩れ、ホームページのヒーローがあなたが選んでいないネオンカラーになり、2つのブロックが横並びではなく縦に積み重なってしまいます。

その間、あなたはサポートしている他の6つのクライアントサイトのことを考えており、「親切心からの」クライアント編集のたびにバックアップからの復元が必要になるようなメンテナンスの罠は避けたいものです。

答えはサイトエディターを取り上げることではありません。theme.jsonを使ってその中に境界を設定することです。WordPress Developer Resourcesによると、theme.jsonはブロックエディターの設定とスタイルの中心的な情報源であり、クライアントに表示されるカラーパレット、タイポグラフィ、レイアウトオプションを定義します。つまり、デザインを制御する同じファイルが、クライアントが編集できるものとできないものも制御できるのです。

ほとんどのチュートリアルは開発者向けにtheme.jsonの機能に焦点を当てているため、この考え方について説明します。代理店にとっての疑問は異なります。クライアントが窮屈に感じることなく安全に使えるようにするにはどうすればよいか、ということです。

サイトエディターはなぜ危険に感じられるのか？

クライアントはサイトを壊そうとしているわけではありません。彼らは古いエディターで何年も訓練されてきたこと、つまり見出しの変更、画像の差し替え、段落の追加などをしようとしているだけです。危険なのは彼らの意図ではなく、サイトエディターがグローバルなコントロールとコンテンツのコントロールを同じ場所に表示することです。

よくあるシナリオを紹介します。クライアントがサイトエディターでテンプレートを開き、見出しブロックを目にします。新しいブランドのスウォッチに合わせて色を変更します。しかし、その見出しがテンプレート内にあるため、そのテンプレートが使われているすべての場所に変更が適用されます。クライアントには1つの編集に見えましたが、サイトにとってはグローバルな変更でした。

一般的な原則として、ページビルダーを誰かに渡すと、彼らはやがて「ガードレール付き設定」を見つけて無効にしてしまうものです。しかし、theme.jsonを使えば、ガードレール自体を隠すことができます。クライアントに「グローバルスタイルに触らないで」と言う代わりに、悪い結果を生む可能性のあるカラーパレットをそもそも表示しないのです。承認された色のパレット、フォントサイズのスケール、スペーシングのプリセットを定義し、クライアントはCSSの全範囲ではなく、それらの中から選択します。

これが最初の転換です。ルールについて考えるのをやめ、工場について考え始めましょう。theme.jsonはあなたの生産ラインです。クライアントが目にするオプションを設定し、制約はハンドオーバー文書の一連の指示ではなく、インターフェース自体によって強制されます。

実際に何をロックすべきか？

すべてではありません。コンテンツ領域を厳しくロックしすぎると、クライアントは段落を追加するたびにあなたに電話するか、あるいはあなたを迂回する方法を見つけるでしょう。多くの場合、一時的なプラグインを追加したり、古いサイトからHTMLをコピーしたりします。

何をロックし、何を残し、その理由をまとめた実用的な表は次のとおりです。

編集面	ロックする？	理由
テンプレート構造とブロックレイアウト	ロック	コアなレイアウトブロックの誤削除や並べ替えを防ぎます
グローバルスタイル（色、フォント、スペーシングプリセット）	プリセットでロック	クライアントは任意の値ではなく、承認されたセットから選択します
コンテンツのテキストと画像	オープン	これは彼らの仕事です。許可なく実行させます
ブロック間のスペーシング	部分的にロック	スペーシングプリセットを提供し、整列を崩さずにリズムを調整できるようにします
厳選されたブロックパターン	精査済みならオープン	クライアントがゼロから構築せずに新しいセクションを追加する安全な方法

重要なニュアンスは、「ロックアウト」ではなく「プリセットでのロック」です。グローバルスタイルでは、設定パネルを隠すのではなく、選択肢を厳選されたセットに減らします。テンプレート構造では、特定のブロックを削除できないようにロックしつつ、クライアントが内部のテキストを編集できるようにできます。

注意点が1つあります。テンプレート内のブロックをロックすることは、特定のページでロックすることとは異なります。テンプレートのロックは、そのテンプレートを使用するすべてのコンテンツに影響します。ページごとに異なるロックレベルが必要な場合は、エディター内でブロックレベルで操作する必要があり、それより脆弱です。代理店業務を繰り返し行うには、ロックされた領域が一貫するようにテンプレートを設計してください。

エディターを罠のように感じさせずに境界を設定するには？

その手法は、theme.jsonでデザイントークンを定義し、CSSで他に何もしないようにすることです。

たとえば、クライアントがボタンに任意の色を設定できるようにする代わりに、theme.jsonでパレットの特定の色を使用するボタンスタイルを定義します。クライアントはボタンを選択してテキストを変更できますが、カラーピッカーには承認済みのスウォッチだけが表示されます。フォントサイズ、行の高さ、スペーシングも同様です。

同じ原則がテンプレートにも適用されます。テンプレート内の特定のブロックで「ロック」機能を使用できます。たとえば、証言ブロックの列構造をロックして、クライアントが引用テキストを変更できても、3列を2列に変更できないようにするなどです。ブロックロックをまだ使用したことがない場合は、エディターツールバーで利用できます。ブロックをロックするときは、クライアントがコンテンツを編集できるか、移動できるか、その両方を許可するかを選択できます。これはtheme.jsonでブロックレベルのデフォルトに適用することもできます。

目指すのは、クライアントがデザインを壊すようなコントロールを一切見かけないエディターです。それは何も間違ったことをできないという意味ではありません。最悪の間違いは、サイト全体の外観ではなく、見出しの文言を変更することだけであるという意味です。

カスタム投稿タイプを使用している場合は、同じ原則がデフォルトのテンプレート以外にも適用されます。詳細については、theme.jsonをカスタム投稿タイプとプラグイン出力に拡張するガイドを参照してください。

ロックしすぎるとどうなるか？

逆説的な点を挙げます。過剰なロックは、ロック不足と同様に有害です。見出しのサイズを変更したり、セクション間に隙間を追加したりできないクライアントは、やがて「見た目を整えてほしい」と依頼するでしょう。そしてあなたは無償で小さな編集をすることに戻ります。さらに悪いことに、サイトエディターは役に立たないと判断し、再び過剰なコントロールを提供するサードパーティのページビルダーに戻るかもしれません。

このトレードオフは現実的です。厳しくロックされたエディターは緊急の連絡を減らしますが、「このボタンを5ピクセル上に移動してもらえますか」という依頼が増えます。逆に、ロックが緩いエディターはその逆です。あなたの仕事は、すべてのクライアントに同じ設定を適用するのではなく、各クライアントに適したバランス点を見つけることです。

良い出発点となるヒューリスティックは次のとおりです。何かのすべてのインスタンスに影響するもの（グローバルスタイル、テンプレート構造）はすべてロックし、1つのインスタンスのみに影響するもの（単一ページのテキストと画像）はオープンのままにします。クライアントが単一ページを壊した場合は5分で修正できます。グローバルスタイルを壊した場合は20分の修正とセキュリティ上の懸念が生じます。

これをクライアント間で再現可能にするには？

ここで代理店のワークフローが重要になります。デザイントークン（カラーパレット、タイポグラフィスケール、スペーシングプリセット）を定義するベースのtheme.jsonを持ち、その後、特定の値を拡張または変更するクライアントごとのオーバーライドファイルを用意します。

まず「スターター」ブロックテーマを作成します。theme.jsonを使ったカスタムブロックテーマの構築方法を参照してください。開発して文書化したら、新しいクライアントにコピーするのは、ブランドカラーとフォントを入れ替えるだけです。車輪の再発明ではなく、トークンを交換するだけです。これはまさにすべてのWordPressサイトを再構築するのをやめる考え方であり、バックエンドではなくエディターに適用されます。

theme.jsonは単一のファイルなので、バージョン管理と複数の環境へのデプロイも簡単です。変更を確認し、クライアントがグローバルスタイルで何を変更したかを確認し、その変更をベースファイルと比較できます。これにより、サポートリクエストのための強力な監査証跡が得られます。

複数のサイトを管理していて、まだベーステーマを設定していないなら、これがその機会です。これは、クライアントがエディターを開くたびに費用対効果が得られる、カスタムWordPress作業の1つです。

「もう1色追加して」と要求し続けるクライアントには？

パレットは約束です。5つのブランドカラーを定義し、クライアントが6つ目を要求した場合、答えは「ノー」ではなく、「はい、ただしパレットへの意図的な追加として、見出しの一回限りのhexコードとしてではなく、追加されます」です。theme.jsonに色を追加すると、サイト全体で一貫して利用できるようになります。それがそういったリクエストに対処する正しい方法です。

また、ここでクライアントとコミュニケーションを取る必要があります。サイトエディターにはブランド基準に合った色とフォントだけが表示されることを説明してください。基準を拡張したい場合は、デザインシステムで対応し、その後はすべての新しい色がどこでも利用できるようになります。まだ構築していない将来のページも含めてです。これは「それはできません」よりもはるかに良い回答です。

同時に、40色ものパレットを蓄積しないでください。四半期ごとに見直し、一度きりの事故だったものを削除します。目標は、少なくて意図的なオプションのセットです。

レイアウトをロックしてコンテンツをオープンにし、パレットをクライアント関係の生きた一部にすれば、サイトエディターは脅威ではなくなります。あなたが保護するために報酬を受けているデザイン基準を犠牲にすることなく、クライアントに真の自律性を渡す方法になります。