Nextora サイト構成
Nextora をソースとするブロックテーマの構成レイヤーを担当します:templates/、parts/、patterns/、およびそれらを記述する theme.json の宣言。ブロック内部については ../nextora-gutenberg-blocks/SKILL.md、外観とプリセットデータについては ../nextora-design-system/SKILL.md、子テーマのブートストラップとアセットについては ../nextora-child-themes/SKILL.md を参照してください。
読み込むべき参照
references/templates-and-patterns.md— 実際のファイル名によるテンプレート階層、パーツの所有権とオーバーライドルール、パターンヘッダーとカテゴリの規則、隠しパターンとシンテンプレートのレシピ、クエリ構成とサニタイズヘルパー、ファイルシステム vs データベースのカスタマイズ、観察された欠陥、および下流の WordPress 受け入れレシピ。ステップ 3 の前にロードしてください。source-map.md— そこに記載されているすべてのアンカーの出典。quality-gates.md— 構成が完了したかどうかを判断するゲート。
ローカルファイルは、これらの参照に引用されているすべての値を上書きします。
順序付けられたワークフロー
1. テーマルートを解決し、ローカルサーフェスを読み取る
親はテンプレートディレクトリ、アクティブテーマはスタイルシートディレクトリです:
get_template_directory(); // 親ルート
get_stylesheet_directory(); // アクティブテーマルート(子テーマが有効な場合は子)
この順序で読み取ります:theme.json(customTemplates、templateParts)、templates/、parts/、patterns/、対象の blocks/*/block.json 名、およびクエリまたはテンプレートヘルパーのための inc/。子テーマのテンプレートまたはパーツのコピーは、同じ名前の親のファイルを上書きするため、既に存在するものが答えの大部分を決定します。
2. 何かを構成する前に、既に存在するものを見つける
再利用は発明に優先します。この順序で:
- すでにそのセクションである既存のパターン。
- すでにそのセクションをレンダリングする既存のブロック(親の
nextora/*または子自身のブロック)。 - 既存のブロックから構成された新しい子パターン。
- それらのパターンを組み立てるシンテンプレート。
- 子パーツのオーバーライド — 子が実際に所有するサーフェスのみ。
- 新しいブロック — 要求された動作または編集構造が既存のブロックで表現できない場合のみ。
モックの投稿を本番コンテンツとして出荷しないでください。また、親のコンタクトフォームバックエンドをクローンしないでください:親は既に nextora/contact-form ブロックを出荷しており、サンプルのコンタクトページはそれを子ラッパーグループ内で構成しています。
3. 構成を適切なテンプレートに配置する
references/templates-and-patterns.md の階層を適用します:
front-page.htmlは存在する場合フロントページを管理します。home.htmlは投稿インデックスであり、フロントページの同義語ではありません。index.htmlはフォールバックです。- アーカイブ、単一、検索、およびページ固有のテンプレートは、インデックスフォールバックよりも優先されます。
theme.jsonのcustomTemplatesで宣言された名前には、それを宣言するテーマ内に一致するtemplates/<name>.htmlが存在する必要があります。
ファイル名を推測するのではなく、テーマ自身の templates/ リストを読み取ってください:親は front-page、home、index、archive、single、search、page、page-full-width、about-us、contact-us、frequently-asked-questions、theme-terms-conditions、theme-privacy-policy、404 を出荷しています。サンプルの子テーマは、独自の、異なる名前のセットを出荷しています。
4. パーツの所有権を決定し、パーツを参照する
wp:template-part 参照は、最初にスタイルシートディレクトリに対して解決されるため、子テーマの parts/header.html は、それが使用されているすべての場所で親のヘッダーを置き換えます。
- 子テーマがヘッダー/フッターを所有する理由がない場合は、親のヘッダー/フッターを維持します:コピーしたパーツを追加しないでください。
- 子テーマがパーツを所有する場合、子が所有するボディを与え、そのことを参照で明示します。親のコピーを固定する
theme属性を残さないでください。 - サンプルの子テーマの
parts/header.htmlとparts/footer.htmlは、それぞれ 1 つのブロック参照(nextsaas/site-header、nextsaas/site-footer)です。親のヘッダーパーツはnextora/scrolling-promotionとnextora/headerを構成します。 - ソース内の参照構文は、子テーマでは
{"slug":"header","tagName":"div"}、親では{"slug":"header","tagName":"header","area":"header"}です。対象の独自の規約に合わせてください。ファイルシステムパスをハードコードしないでください。
5. パターンを実際のヘッダーを持つ PHP ファイルとして作成する
パターンは patterns/*.php にあります。登録は register_block_pattern() 呼び出しではなく、ファイルヘッダーから行われます。どちらのソーステーマもそれを呼び出しておらず、PHP でカテゴリのみを登録しています。必須のヘッダーフィールドとスラッグルールは references/templates-and-patterns.md にあります:
Title、Slug: <child-slug>/<pattern-slug>(一意)、Categories、およびいつ使用するかを示すDescription。- パターンボディは、エディターが挿入するシリアル化されたブロックマークアップであり、ヘッダーコメントの閉じ
*/の後に始まります。 - パース可能で、登録されたブロックのみを使用し、挿入後も編集可能である必要があります。
6. フルページ構成には正確に 1 つの権限を与える
新しいフルページ構成の場合、セクションリストを隠しファイルシステムパターン(ヘッダーに Inserter: no)に配置し、シンテンプレートからそれを参照します:
<!-- wp:template-part {"slug":"header","tagName":"div"} /-->
<!-- wp:pattern {"slug":"nextfolio/page-landing"} /-->
<!-- wp:template-part {"slug":"footer","tagName":"div"} /-->
セクションリストをテンプレートにも繰り返さないでください。サンプルは現在、同じリストを 2 回保持しています(patterns/page-home.php と templates/front-page.html)。また、親のテンプレートは metadata.patternName を持つパターンマークアップをインライン化しています。この重複は、このルールが新しい作業のために置き換えるものです。既存のブロックを編集するだけの場合は、既存の重複を維持してください — セクションコンテンツが実際に変更された場合にのみ、他のコピーを更新します。
7. コアブロックと明示的なコンテキストでクエリを構成する
- アーカイブ、投稿インデックス、検索、および投稿詳細は、
"inherit":trueを持つwp:queryに委譲するため、メインクエリがコンテキストを提供します。サンプルのindex.html、home.html、archive.html、search.htmlはすべてこれを実行しています。 - ループを
core/post-templateとcore/post-*ブロックから構築し、wp:query-paginationを追加し、常にwp:query-no-resultsを提供します。 - 単一投稿サーフェスには、従来のループではなく、
wp:query-title、core/post-title、core/post-content、core/comments+core/comment-template+wp:comments-pagination+wp:post-comments-formを使用します。 - 独自のループを開始するブロックは、サニタイズされた属性を渡します:子テーマの
inc/blocks/query.phpヘルパーが存在する場合はそれを再利用し、そうでない場合はページサイズをクランプし、投稿タイプ、タクソノミー、およびタームを許可された値に対して検証します。準備された SQL はその検証の代わりにはなりません。
8. theme.json の宣言を正確に保つ
テーマが所有するサーフェスについてのみ、かつコアテンプレートではない名前についてのみ、customTemplates と templateParts エントリを宣言します。サンプルで観察された再宣言と新しい作業のルールについては、references/templates-and-patterns.md を参照してください。
9. サイトエディターを考慮する
ファイルシステムのテンプレートとパーツは、サイトエディターで保存されたデータベースのカスタマイズによってマスクされる可能性があります。ファイルの編集がフロントエンドを変更しない場合は、ファイルに触れる前に保存されたテンプレートまたはスタイルを探してください。実際のサイトのカスタマイズを黙って上書きしないでください。使い捨て環境でのみ検査またはリセットしてください。
10. 実行中のサイトに対して検証する
各テンプレートとパーツをフロントエンドで解決し、パターンが挿入後に編集可能であることを確認し、要求された WordPress 最小バージョンと現在サポートされているリリースを確認し、references/templates-and-patterns.md のブラウザレシピを実行します。実行しなかったものは未検証としてマークします。
完了チェック
- 使用されているすべてのテンプレートとパーツが意図されたテーマに解決される。子テンプレートから親パーツを固定する
theme属性が残っていない。 - 不必要な新しいブロック、従来の PHP ページテンプレート、モックの本番コンテンツがない。
- 新しいフルページ構成:隠しパターン内の 1 つの権限、シンテンプレートから参照される。重複したセクションリストがない。
- パターンがパースされ、登録されたブロックを使用し、一意のスラッグを保持し、そのカテゴリがテーマが PHP で登録するものである。
- クエリループが明示的なコンテキスト、サニタイズされた属性、および結果なし状態を使用する。
theme.jsonは所有するコア以外のテンプレート名のみを宣言する。quality-gates.mdが適用され、その構成受入セクションを含む。
境界
マークダウン指示のみ:ランタイムスクリプト、ジェネレーター、コピーされたテーマツリー、インストーラーはありません。また、親テーマやサンプルの子テーマへの編集もありません。親のパターンライブラリとサンプルの構成は、フォークするためのファイルではなく、読み取るための証拠です。