WordPressサイトを毎回作り直すのをやめよう

概要

多くのエージェンシーは、共通の基盤があればスケジュールを数週間短縮できる場合でも、すべてのWordPressサイトを空のテーマから構築しています。この記事では、theme.json、ブロックパターン、動的ブロックを使用することで、各クライアントの特徴的なデザインを維持しながら、構造層を標準化できると主張しています。また、チームが変更をためらう5つの反対意見に直接答えています。「クライアントはそれぞれ違う」「カスタムブロックは高価」「エディターはわかりにくい」「フックとフィルターを失う」「FSEは本番環境に使えない」。それぞれの反対意見に対して、実用的な反論と、段階的に採用できる具体的なパターンを紹介します。その見返りは、顧客固有の作業がふさわしい場所で尊重される、繰り返し可能な構築プロセスです。注意：ワンクリックでリセットするボタンは約束されていません。

あなたのクライアントサイトのうち、コードを1行でも共有しているものはいくつありますか？ 著作権表示ではなく、実際のコードです。答えが「ほぼない」なら、あなたはすでにその痛みを感じているはずです。同じヒーローセクションを9回作り直し、同じチームグリッドのマークアップをプロジェクトごとにコピーし、同じ前処理の調整を6つのテーマにまたがって相互参照する。また、「クライアントにはそれぞれ異なるニーズがある」という主張も聞いたことがあるでしょう。確かにその通りです。しかし、そこから誰もが導き出す結論、つまり「すべてのサイトには特注の基盤が必要だ」というのは誤りです。WordPressエコシステムは現在、デザインを標準化せずに構造部分を標準化する方法を提供しています。デザイントークンにはtheme.json、繰り返しのレイアウトにはブロックパターン、実際のサーバーサイドロジックが必要な少数の機能には動的ブロックです。この記事は、エージェンシーがその一歩を踏み出すのを妨げる反対意見と、それに反論したときに実際に機能する方法についてのものです。

「でもクライアントはそれぞれ違う」という反対意見

根本的な原則：表面ではなく基盤を標準化する。構造を共有ライブラリに保持する理由は、まさにビジュアル層を自由にしておくためです。theme.jsonファイルはデザインではなく、デザイントークンのセットです。色、スペーシング、タイポグラフィは値であり、マークアップではありません。これが重要な転換です。サイトごとのtheme.jsonによって異なるブランド向けにサイトを完全に変えながら、マークアップを共有できるのです。

2つのクライアントを例に挙げましょう。法律事務所とアウトドア小売店です。彼らのデザイン言語は大きく異なります。しかし、両方ともヒーローセクション、テストモニアルグリッド、コールトゥアクションバンドが必要です。それぞれのマークアップを再構築する代わりに、3つのブロックパターンを維持し、各クライアントのtheme.jsonで色、フォント、スペーシングを定義します。構造は同一のまま、デザイントークンがブランドを一方から他方へと変えます。小売店が来春カラーパレットを変更したら、6つのテンプレートのマークアップではなく、サイト上の1つのファイルを編集するだけです。

実際には、これはチームがパターンをコードとして作成し、共有プラグインに登録し、各クライアントサイトのtheme.jsonにペイントを任せることを意味します。パターンのクラス名がアーキテクチャになり、値が変数になります。さらに、theme.jsonを拡張して投稿タイプやプラグイン出力のカスタム設定を含めることもできますが、ある時点でサイトではなく設定インターフェースを構築していることになります。これについては、theme.jsonの拡張に関する記事で説明しています。共有レイヤーはスリムに保ちましょう。クライアント間で繰り返し発生するものだけを含めるべきです。「いつか誰かが欲しがるかもしれない」という設定を追加している自分に気づいたとき、あなたは節約する以上に維持費がかかる抽象化を作り出しています。

新しいクライアントのセットアップ時に、最初の30分は次のようにします。共有パターンプラグインをクローンし、クライアントのパレットとフォントスケールで新しいtheme.jsonを作成し、ロゴとフッターを登録します。これはカスタムビルドではなく、設定タスクです。残りのクライアント固有の作業は、コンテンツ、構造、そして真に特注の機能に充てられます。これは、すべての家をゼロから建てるのと、塗り替えや壁紙の張り替えができるプレハブの間取り図のセットを持つことの違いです。たとえ話は大まかですが、原則は有効です。theme.jsonの値に押し込めるほど、マークアップに触れる必要が少なくなります。

最も簡単な勝利の1つは、実際にブロックパターンの仕組みを見てみることです。パターンは、定義済みのコンテンツとスタイルを持つブロックの集まりにすぎません。任意のブロック構成をパターンとして保存でき、クライアントはそれがどのように構築されているかを知らなくても挿入できます。つまり、パターンは非技術ユーザーにとっての「エントリーポイント」になります。チームがコード内の基盤となるパターンを維持していれば、クライアントは1つのPHPタグに触れることなく一貫したライブラリを利用できます。

さて、私が繰り返し言う注意点：過度に集中化しないこと。考え得るあらゆるニュアンスの設定を持つtheme.jsonは、メンテナンスの沼です。共有パターンは、独断的であれ、全能であってはなりません。クライアントが根本的に異なるレイアウト（たとえば、大きな特集グリッドを持つ雑誌のホームページ）を必要とする場合、標準パターンライブラリに合わないかもしれません。それでいいのです。標準化とは、類似したプロジェクトの80%で勝つことであって、すべてのサイトを同じ型に押し込むことではありません。

「カスタムブロックは予算を圧迫する」という反対意見

ここに、退屈に聞こえるがお金を節約する反対原則があります。カスタムブロックが必要だと思っているもののほとんどは、必要ありません。コアブロックとパターンで、圧倒的多数のレイアウトをカバーできます。カスタムブロックは最後の手段であり、最初の意図ではありません。

典型的な例はチームグリッドです。一度きりなら、コアの「カラム」と「グループ」ブロックを使用し、クライアントにアバターを手動でドロップしてもらいます。3人のクライアントが「名前の下にソーシャルリンク」という同じ構造の同じグリッドを求めたら、それはブロックパターンの候補になります。そのパターンに新しいオプション（ホバー効果、並べ替え、評価スター）が追加され始めると、パターンは管理不能な寄せ集めになり、その時点でカスタムブロックを書く時です。予算を痛める間違いは、最初のリクエストでいきなりカスタムブロックに飛びつくことです。

より陰湿なシナリオ：クライアントが「ケーススタディカルーセル」を要求します。最初の直感は「カルーセルブロックが必要だ」と考えることです。しかし、彼らは本当にカルーセルが必要でしょうか？ おそらく、横にスクロールできる投稿のグループで十分で、コアブロックの「グループ」ブロックとCSSで処理できます。あるいは、最近のケーススタディの動的リストが必要で、それはCPTをクエリする動的ブロックです。問題は「クライアントはどの機能を求めているか」ではなく、「それはどのデータに依存するか」です。データが静的でクライアントが編集できるなら、パターンで十分です。データがデータベースクエリからのものなら、動的ブロックが正当化されます。データがAPIからリアルタイムに更新される必要があるなら、REST API統合を検討していることになります。これは別種の構築に属します。

ブロックを実際に構築するとき、block.jsonは頼りになります。これは属性、スクリプト、スタイルの単一の真実の源であり、ブロックをプロジェクト間で移植可能にします。また、依存関係と翻訳をきれいに宣言できるため、多くのクライアントサイトにライブラリを配布する際に不可欠です。ライブデータに依存するコンテンツの場合、動的ブロックはサーバー側でレンダリングされるため、ページビューごとにJavaScriptバンドルを配信する必要はありません。そして、ブロックが進化する場合、既存のコンテンツを壊さないように非推奨を優雅に処理できます。正確なパターンは、ブロック非推奨ガイドで説明しています。

何かを構築する前に、このグリッドで判断を実行してください：

アプローチ	最適な用途	避けるべき場合
コアブロック	一度きりのコンテンツ、シンプルなページ	レイアウトが多くのクライアントで繰り返され、豊富なオプションが必要な場合
ブロックパターン	ロジックなしの繰り返しレイアウト	レイアウトに条件、動的データ、複雑なインタラクションが必要な場合
カスタムブロック	繰り返し、データ駆動、または非常に特殊な動作	唯一の理由がクラスで処理できる一度きりのセクションである場合

また、初日からブロックの命名について考える必要があります。ブロック名は本質的にコンテンツとの契約です。wagent/team-gridと呼び、後でwagent/team-carouselに名前を変更すると、非推奨パスを提供しない限り既存のコンテンツが壊れます。ブロックが進化しても虚偽の表示にならない、汎用的で目的ベースの名前を選びましょう。これはプラグインのプレフィックスから学んだ命名規律の一種であり、ブロック名にも同様に当てはまります。

ここで言える最も有益な逆説的な見解は、クライアントが「1つだけ」と頼んだからといって作るカスタムブロックは、ほとんど常に間違いだということです。丁寧に断り、クラス付きのコアブロックを出荷し、時間を節約しましょう。クライアントからの信頼が高まり、メンテナンス予算の項目も減ります。

「クライアントがエディターを壊す」という反対意見

この反対意見は半分正しい。ブロックエディター自体が問題なのではなく、問題はクライアントにあまりにも多くの自由を与えることです。theme.jsonは編集可能な範囲を制限できます。テンプレートエディターを無効にし、許可するブロックを制限し、デフォルトスタイルを設定して、列の配置ミスによる被害を減らすことができます。それでもクライアントが何かを壊すことはありますが、保存済みのパターンにページをワンクリックで戻すことができます。これはクラシックエディターにはできなかったことです。

シナリオを描いてみましょう。クライアントから電話があり、「セクションを移動したら、ページ全体がおかしくなった」と言われます。クラシックテーマなら、ログインしてCSSを調べ、おそらく1時間かけてレイアウトを修正するでしょう。ブロック設定なら、ページを開いてコンテンツエリアを選択し、保存済みのパターンにリセットできます。パターンがベースラインであり、クライアントの変更はオーバーレイです。オーバーレイがおかしくなったら、それを削除するだけです。これはより優れたワークフローであるだけでなく、根本的により寛容なエディターです。

ここでニュアンス：ほとんどのクライアントはほとんど編集したがりません。テキストを変更し、写真を交換し、セクションを並べ替える程度です。ブロックパターンは、サイト構造全体をさらすことなく、まさにそれを実現します。この意味で、エディターはおもちゃではなく、ビューファインダーです。あなたの仕事は、クライアントが見えるものを調整することです。つまり、「テンプレート」設定を無効にし、ブロックインサーターを厳選されたリストに制限し、空のパターンにプレースホルダーを事前に入力することもできます。エディターはウェブデザインのキャンバスではなく、コンテンツ入力フォームになります。

アクセシビリティの面では、ブロックエディターのフォーカス管理とキーボードサポートは、クラシックエディターのテンプレートフィールドよりも概して優れています。しかし、パターンに適切な見出し階層とアクセシブルな名前があることを確認する必要があります。パターンはクライアント間で共有されるため、これらの問題は一度だけ修正すればよく、これは標準化のもう1つの隠れた利点です。

本当に難しい部分は内部にあります。チームにとって、ブロックでプロトタイプを作成することを学ぶには、「PHPでやる」習慣を捨てる必要があります。これは実際のコストですが、1人あたり1回限りのコストです。アプローチを避ける理由ではなく、どこにでも展開する前に、1つのパターンライブラリと1人の寛容なクライアントから始める理由です。「私のクライアントはブロックを扱えない」という言葉で、クライアントに歩み寄るブロック設定をまだ構成していない事実を隠してはいけません。

「フックとフィルターはもうある」という反対意見

ここでの原則は、フックを捨てるのではなく、その上にレイヤーを追加するということです。ブロックはプレゼンテーションの境界であり、フックは依然としてロジックを注入する方法です。動的ブロックのレンダーコールバックはPHPで実行されるため、すでに信頼している同じ関数を呼び出し、同じフィルターを適用できます。

フィルターを使用して任意の投稿に「注目の製品」フィールドを追加できるプラグインを想像してください。動的ブロックを使用すると、そのフィルターを実行し、出力をブロックのラッパー内に出力するサーバーレンダリングブロックを含めることができます。クライアントはブロックを挿入し、既存のPHPロジックが重い処理を行います。何も捨てられません。さらに具体的な例として、最近のプロジェクト投稿を一覧表示するカスタムブロックを考えてみましょう。そのレンダーコールバックでは、get_posts()を呼び出し、ループしてthe_title()とthe_permalink()を適用します。これは何年も使ってきたテンプレートタグと同じです。

また、翻訳できないものについて正直になる場所でもあります。巧妙な古いテーマの中には、ページコンテキストに基づいて引数を取る複雑な条件文を持つtemplate-partsを使用するものがあります。それをブロックとして再現するのは厄介かもしれません。しかし、一度にすべてを再現する必要はありません。段階的な道は、PHPロジックを維持し、それを動的ブロックでラップし、マークアップをブロックテンプレートに移動することです。既存のフィルターパターンが新しい出力を処理できることに気づくことがよくあります。そして、ロジックがテンプレート階層に密接に結びついている場合（例：「検索結果ではこれを別の方法で表示する」）、通常のページにはブロックを使用しながら、特定のビューにはクラシックテンプレートを引き続き使用できます。

REST APIはまた別の扉を開きます。他のWordPressサイトやサードパーティサービスからデータを取得するブロックを構築できます。動的ブロックはwp_remote_get()を呼び出してJSONを取得し、フロントエンドでレンダリングできます。これは、クライアントが別の統合を管理せずにソーシャルフィード、製品リスト、内部データを表示したいエージェンシービルドにとって強力なパターンです。トレードオフはキャッシュとエラーハンドリングです。リモートAPIが遅いと、ページも遅くなります。APIベースのブロックを重要なファーストビューのコンテンツから遠ざけるか、適切なローディング状態を持つクライアントサイドレンダリングを使用してください。

アクションとフィルターは依然として保存とレンダリングの周りで実行されます。フックアーキテクチャはブロックを採用しても消えず、新しいコンテキストに移動するだけです。アクションとフィルターがこの新しいブロックの世界とどこで交わるかについての理解を新たにする必要があるなら、フックの詳細ガイドが役立ちます。

「FSEは本番環境に対応していない」という反対意見

もっともですが、「リスクがある」とは実際には何を意味するのか問いかけてください。フルサイト編集はいくつかのリリースを経て、theme.jsonは安定したスキーマに落ち着いています。リスクはエディターが「突然壊れる」ことではなく、チームのカスタムコードがブロックテンプレートとぎこちなく共存する旧式のPHPテンプレートに依存している可能性があることです。また、一部のサードパーティ製プラグインは依然としてクラシックエディターやカスタマイザーを前提としています。これは互換性の判断であり、モデル全体を捨てる理由にはなりません。

これについて考える有用な方法：ブロックで記述されたコンテンツを持つシンプルで反復可能なサイトは、最もリスクが低いです。リスクの高いクライアントは、独自のフロントエンドをレンダリングする深くカスタマイズされたクラシックテーマやプロプライエタリなプラグインを持つ人々です。それは、その小さなニッチにクラシックテーマを使い続ける正当な理由です。誤りは、「本番対応」がオンかオフかの単一のスイッチであるかのように装うことです。

クライアントにブロックテーマを提案する前に、簡単なチェックリストを確認してください：

• クライアントに移行が必要なほど高度にカスタマイズされたテーマがありますか？
• 必須プラグインはサイトエディターとREST APIをサポートしていますか？
• ホスティング環境はブロックテーマが期待するファイルアクセスを許可していますか？
• ブロック登録だけでなく、パターンデザインの時間を確保しましたか？
• クライアントのチームはエディターの変更を受け入れますか、それともロックされたテンプレートが必要ですか？

いずれかの答えが「いいえ」の場合、範囲を調整するか、ハイブリッドアプローチを使用します。これは妥協ではなく、エンジニアリング判断です。ハイブリッドを構築する場合は、上記のフックとフィルターの話を思い出してください。theme.jsonがグローバルな外観を処理しながら、古いロジックを動的ブロックにラップできます。

theme.jsonのバージョニングは理論上の懸念だけではありません。クライアントがWordPressを更新し、ブロックのstyleファイルがwp_register_style()で変更されたハンドルの下に登録されたとき、エージェンシーのカスタムブロックライブラリが壊れるのを見たことがあります。修正は簡単でしたが、パニックは本物でした。サイトのステージングコピーで更新を実行し、主要ページをクリックしてからリリースするという簡単なテストプロセスが、これらの驚きのほとんどを解決します。

あなたが自分自身にまだしていない反対意見

エージェンシーが標準化を妨げるメタ反対意見はこれです。「大きな変更であり、クライアントワークの最中に行う時間はない」。それは事実です。だからクライアントワークの最中に行ってはいけません。内部プロジェクトか小さなクライアントを選び、1つのパターンライブラリを構築してください。theme.jsonをデザイントークンシステムとして使用します。正当化される場合にのみカスタムブロックを追加します。役立つ場所では古いフックをラップします。反復します。

大まかな最初の30日は次のとおりです：

1. 過去5つのクライアントビルドを監査し、最も繰り返される10のレイアウト部分をリストアップします。
2. その10の部分を、少数のCSSクラスを持つブロックパターンに変換します。
3. それらのパターンを登録する共有プラグイン（またはmu-plugin）を構築します。プラグイン構成について考えたことがない場合は、まず堅牢なプラグイン構築ガイドに目を通してください。
4. ベースラインデザインに一致する1つのtheme.jsonを作成します。プロジェクトを立ち上げる際にクライアント固有の値を追加します。
5. 小さな内部プロジェクトか友好的なクライアントを1つ選び、そのスタックに移行します。
6. クライアントが電話をかけずにホームページを編集したというヒーローストーリーを1つ記録します。

その実験の終わりには、壁に掛ける「ブロックファースト」のバッジはありません。しかし、共有ベースラインから新しいクライアントサイトを立ち上げることができ、スケジュールについて謝罪する必要のないチームができるでしょう。また、クライアントの42番目のカスタムブロックのリクエストを断る立場にもなります。コアブロックが何ができるかを正確に知っているから、あるいは動的ブロックが本当に高速である理由を示せるからです。

それでも特注サイトを構築しますか？ はい。一部のクライアントは常にカスタムテンプレート、特注ページ、または共有モデルに無理に組み込む価値がないプロプライエタリな統合を必要とします。目標は特注作業をなくすことではなく、特注をデフォルトではなく例外にすることです。

再現性は退屈な部分から生まれます。堅実なtheme.jsonスキーマ、明確なパターンライブラリ、そして共有レイヤーをスリムに保つ規律。これはウェビナーで聞くような派手なバージョンではありません。月曜の朝の空のテーマの憂鬱に打ち勝つものです。