miketropi/nextora-site-composition

Nextora Site-Komposition

Besitzt die Kompositionsschicht eines Nextora-basierten Block-Themes: templates/, parts/, patterns/ und die theme.json-Deklarationen, die sie beschreiben. Block- Interna befinden sich in ../nextora-gutenberg-blocks/SKILL.md; Aussehen und Vorgabedaten befinden sich in ../nextora-design-system/SKILL.md; Child-Bootstrap und Assets befinden sich in ../nextora-child-themes/SKILL.md.

Zu ladende Referenzen

• references/templates-and-patterns.md — die Vorlagenhierarchie mit den tatsächlichen Dateinamen, Teilbesitz und Überschreibungsregeln, die Pattern-Header- und Kategorie-Konventionen, das Rezept für versteckte Patterns plus dünne Vorlagen, Query-Komposition und die Bereinigungshilfen, Dateisystem- versus Datenbank-Anpassung, die beobachteten Fehler und das nachgelagerte WordPress-Akzeptanzrezept. Lade es vor Schritt 3.
• source-map.md — Herkunft für jeden dort genannten Anker.
• quality-gates.md — die Tore, die entscheiden, ob die Komposition abgeschlossen ist.

Lokale Dateien haben Vorrang vor jedem in diesen Referenzen angegebenen Wert.

Geordneter Arbeitsablauf

1. Auflösung der Theme-Wurzeln und Einlesen der lokalen Oberflächen

Das Eltern-Theme ist das Vorlagen-Verzeichnis, das aktive Theme ist das Stylesheet-Verzeichnis:

get_template_directory();      // Eltern-Wurzel
get_stylesheet_directory();    // Aktive Theme-Wurzel (Child, wenn eines aktiv ist)

Lies in dieser Reihenfolge: theme.json (customTemplates, templateParts), templates/, parts/, patterns/, die blocks/*/block.json-Namen des Ziels und inc/ für Query- oder Vorlagenhelfer. Eine Kopie einer Vorlage oder eines Teils im Child überschreibt die Datei des Eltern-Themes mit demselben Namen, daher bestimmt das, was bereits existiert, den Großteil der Antwort.

2. Finden, was bereits existiert, bevor etwas komponiert wird

Wiederverwendung schlägt Erfindung, in dieser Reihenfolge:

1. Ein bestehendes Pattern, das bereits den Abschnitt darstellt.
2. Ein bestehender Block (Eltern nextora/* oder das eigene des Childs), der bereits den Abschnitt rendert.
3. Ein neues Child-Pattern, das aus bestehenden Blöcken zusammengesetzt ist.
4. Eine dünne Vorlage, die diese Patterns zusammenstellt.
5. Eine Child-Teil-Überschreibung – nur für eine Oberfläche, die das Child tatsächlich besitzt.
6. Ein neuer Block – nur wenn das angeforderte Verhalten oder die Bearbeitungsstruktur mit keinem bestehenden Block ausgedrückt werden kann.

Versende niemals Platzhalter-Beiträge als Produktionsinhalt und klone niemals das Kontaktformular-Backend des Eltern-Themes: Das Eltern-Theme liefert bereits den nextora/contact-form-Block, und die Kontaktseite des Beispiels komponiert ihn innerhalb einer Child-Wrapper-Gruppe.

3. Platzierung der Komposition in der richtigen Vorlage

Wende die Hierarchie aus references/templates-and-patterns.md an:

• front-page.html regiert die Startseite wenn vorhanden; home.html ist der Beitragsindex, kein Synonym für die Startseite; index.html ist der Fallback.
• Archiv-, Einzel-, Such- und seitenbezogene Vorlagen gehen dem Index-Fallback voraus.
• Ein in theme.json customTemplates deklarierter Name muss eine passende templates/<name>.html im Theme haben, das ihn deklariert.

Lies die eigene templates/-Auflistung des Themes, anstatt Dateinamen zu raten: Das Eltern-Theme liefert 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; das Beispiel-Child liefert seinen eigenen, anders benannten Satz.

4. Entscheidung über den Teilbesitz, dann Referenzierung des Teils

Eine wp:template-part-Referenz wird zuerst gegen das Stylesheet-Verzeichnis aufgelöst, daher ersetzt ein parts/header.html des Childs den Header des Eltern-Themes überall dort, wo er verwendet wird.

• Behalte den Eltern-Header/-Footer bei, wenn das Child keinen Grund hat, sie zu besitzen: füge keinen kopierten Teil hinzu.
• Wenn das Child einen Teil besitzt, gib ihm einen child-eigenen Körper und erwähne dies in der Referenz; hinterlasse kein theme-Attribut, das die Kopie des Eltern-Themes festhält.
• Die parts/header.html und parts/footer.html des Beispiel-Childs sind jeweils eine Blockreferenz (nextsaas/site-header, nextsaas/site-footer); der Header-Teil des Eltern-Themes komponiert nextora/scrolling-promotion und nextora/header.
• Die Referenzsyntax in den Quellen ist {"slug":"header","tagName":"div"} im Child und {"slug":"header","tagName":"header","area":"header"} im Eltern-Theme. Passe dich der eigenen Konvention des Ziels an; kodiere niemals einen Dateisystempfad fest.

5. Erstellung von Patterns als PHP-Dateien mit einem echten Header

Patterns leben in patterns/*.php. Ihre Registrierung erfolgt über den Datei-Header, nicht über einen register_block_pattern()-Aufruf – keines der Quell-Themes ruft ihn auf; beide registrieren in PHP nur Kategorien. Erforderliche Header-Felder und Slug-Regeln finden sich in references/templates-and-patterns.md:

• Title, Slug: <child-slug>/<pattern-slug> (eindeutig), Categories und eine Description, die angibt, wann es zu verwenden ist.
• Der Pattern-Body ist das serialisierte Block-Markup, das der Editor einfügt, beginnend nach dem schließenden */ des Header-Kommentars.
• Er muss parsen, nur registrierte Blöcke verwenden und nach dem Einfügen bearbeitbar bleiben.

6. Vergabe genau einer Autorität für eine vollständige Seitenkomposition

Für eine neue vollständige Seitenkomposition platziere die Abschnittsliste in einem versteckten Dateisystem-Pattern – Inserter: no im Header – und referenziere es aus einer dünnen Vorlage:

<!-- wp:template-part {"slug":"header","tagName":"div"} /-->

<!-- wp:pattern {"slug":"nextfolio/page-landing"} /-->

<!-- wp:template-part {"slug":"footer","tagName":"div"} /-->

Wiederhole die Abschnittsliste nicht auch in der Vorlage. Das Beispiel enthält derzeit dieselbe Liste zweimal (patterns/page-home.php und templates/front-page.html), und die Vorlagen des Eltern-Themes inlineieren Pattern-Markup mit metadata.patternName; diese Duplizierung ersetzt diese Regel für neue Arbeiten. Wenn du lediglich einen bestehenden Block bearbeitest, behalte die bestehende Duplizierung – aktualisiere die anderen Kopien nur, wenn sich der Abschnittsinhalt tatsächlich geändert hat.

7. Komposition von Queries mit Core-Blöcken und explizitem Kontext

• Archive, der Beitragsindex, Suche und Beitragsdetails delegieren an wp:query mit "inherit":true, sodass die Hauptabfrage den Kontext liefert; die index.html, home.html, archive.html und search.html des Beispiels tun dies alle.
• Baue die Schleife aus core/post-template plus core/post-*-Blöcken, füge wp:query-pagination hinzu und stelle immer wp:query-no-results bereit.
• Verwende wp:query-title, core/post-title, core/post-content, core/comments + core/comment-template + wp:comments-pagination + wp:post-comments-form für die Einzelbeitragsoberfläche anstelle einer klassischen Schleife.
• Ein Block, der seine eigene Schleife startet, übergibt bereinigte Attribute: verwende die Helfer des Childs in inc/blocks/query.php wieder, wo sie existieren, andernfalls begrenze Seitengrößen und validiere Beitragstypen, Taxonomien und Begriffe gegen erlaubte Werte. Vorbereitetes SQL ist kein Ersatz für diese Validierung.

8. Halte theme.json-Deklarationen korrekt

Deklariere customTemplates- und templateParts-Einträge nur für Oberflächen, die das Theme besitzt, und nur für Namen, die keine Kernvorlagen sind. Siehe references/templates-and-patterns.md für die beobachtete Neudeklaration im Beispiel und die Regel für neue Arbeiten.

9. Berücksichtigung des Site-Editors

Vorlagen und Teile des Dateisystems können durch Datenbank-Anpassungen maskiert werden, die im Site-Editor gespeichert wurden. Wenn eine Dateiänderung das Frontend nicht verändert, suche vor der Bearbeitung der Datei nach einer gespeicherten Vorlage oder einem Stil. Überschreibe niemals stillschweigend die Anpassungen einer echten Website; überprüfe oder setze nur eine Wegwerf-Umgebung zurück.

10. Überprüfung gegen die laufende Website

Löse jede verwendete Vorlage und jeden Teil im Frontend auf, bestätige, dass Patterns eingefügt werden und bearbeitbar bleiben, bestätige das angeforderte WordPress-Minimum und die aktuell unterstützte Version und führe das Browser-Rezept in references/templates-and-patterns.md aus. Markiere alles, was du nicht getestet hast, als unverifiziert.

Abschlussprüfungen

• Jede verwendete Vorlage und jeder Teil wird im beabsichtigten Theme aufgelöst; kein irreführendes theme-Attribut fixiert einen Eltern-Teil in einer Child-Vorlage.
• Kein unnötiger neuer Block, keine klassische PHP-Seitenvorlage, kein Platzhalter- Produktionsinhalt.
• Neue vollständige Seitenkomposition: eine Autorität in einem versteckten Pattern, referenziert aus einer dünnen Vorlage; keine duplizierte Abschnittsliste.
• Patterns parsen, verwenden registrierte Blöcke, behalten eindeutige Slugs, und ihre Kategorien sind diejenigen, die das Theme in PHP registriert.
• Query-Schleifen verwenden expliziten Kontext, bereinigte Attribute und einen Keine-Ergebnisse-Zustand.
• theme.json deklariert nur besessene, nicht zur Kernvorlage gehörende Vorlagennamen.
• quality-gates.md angewendet, einschließlich seines Kompositions-Akzeptanzabschnitts.

Grenzen

Nur Markdown-Anweisung: keine Laufzeitskripte, Generatoren, kopierten Theme-Bäume oder Installationen und keine Bearbeitungen des Eltern-Themes oder des Beispiel-Childs. Die Pattern-Bibliothek des Eltern-Themes und die Kompositionen des Beispiels dienen als Nachweise zum Lesen, nicht als Dateien zum Forken.