miketropi/nextora-child-themes

Nextora Child-Themes

Erstellt und auditet Child-Themes von Nextora: das Bootstrapping, die Asset-Pipeline und der Child-Block-Registrar. Konventionen auf Eltern-Ebene befinden sich im Eltern-Theme selbst; Block-Interna gehören zu ../nextora-gutenberg-blocks/SKILL.md, und alles, was Palette, Schriftarten oder den Besucher-Umschalter betrifft, gehört zu ../nextora-design-system/SKILL.md.

Zu ladende Referenzen

Lies diese, bevor du eine Datei schreibst, über relativen Pfad:

• references/child-contract.md — die Slug/Präfix-Ersetzungstabelle, das genaue Verzeichnisrezept, der Header, der Bootstrap- und Enqueue-Code, der Registrar, die PHP-Konventionen, die beobachteten Fehler des Beispiels und das Downstream-WordPress-Akzeptanzrezept. Lade es in Schritt 3 und schreibe keinen Code, bevor du es nicht getan hast.
• source-map.md — woher jede Regel stammt, mit Provenienz-Tags und den Tatsachen, die häufig falsch dargestellt werden.
• quality-gates.md — die Gates, an denen das fertige Child gemessen wird. Lade es, bevor du die Fertigstellung erklärst.

Das Lesen der lokalen Quellen hat Vorrang vor dem Lesen dieser Dateien. Jeder in einer Fähigkeit oder Referenz zitierte Wert ist ein Anker, keine aktuelle Tatsache.

Geordneter Workflow

1. Löse die Wurzeln auf, nimm sie nicht an

In einer Live-Installation ist das Eltern-Theme das Vorlagenverzeichnis und das Child-Theme das Stylesheet-Verzeichnis:

get_template_directory();      // Eltern-Wurzel
get_stylesheet_directory();    // Wurzel des aktiven Themes (Child, wenn eines aktiv ist)

Außerhalb einer Installation suche eine style.css mit Theme Name: Nextora für das Eltern-Theme und eine mit Template: nextora für das Child. Wenn die Eltern-Quelle tatsächlich fehlt, sage dies und höre auf, Nextora-Kompatibilität zu beanspruchen; schließe nur die Arbeit ab, die nicht davon abhängt. Erfinde niemals einen Anker und ersetze niemals stillschweigend ein anderes Theme.

2. Lies die Beweise, bevor du etwas vorschlägst

Vom Ziel-Child — oder vom Beispiel-Child, wenn das Beispiel das ist, was portiert wird:

1. style.css — der echte Header: Template, Version, Requires at least, Requires PHP, Tested up to, Text Domain, License.
2. functions.php — Ladereihenfolge und was das Theme im Datei-Scope benötigt.
3. theme.json — version, Palette/Schriftarten-Slugs, customTemplates, templateParts.
4. package.json und .nvmrc — welche Build-Skripte existieren und auf welchem Node.
5. inc/, blocks/, resources/, assets/ — was bereits existiert.

Vom Eltern-Theme: style.css, functions.php, inc/assets/assets.php, blocks/blocks.php. Diese sind das, wovon ein Child abhängt, daher sind ihre Handle-Namen und das Registrar-Verhalten der Vertrag, nicht die Dokumentation.

3. Korrigiere die Benennungstabelle, bevor du Dateien schreibst

Lade references/child-contract.md und fülle seine Ersetzungstabelle für den angeforderten Slug aus. Jeder generierte Bezeichner — PHP-Funktionen, Konstanten, Textdomain, Blocknamen, CSS-Klassen, benutzerdefinierte Eigenschaften, Pattern-Slugs, Handles und Datei-Basenamen — stammt von diesem einen Slug. Eltern-eigene Namen (nextora_*, NEXTORA_*, nextora/*, global-styles, nextora-app, nextora-main, die Eltern-Palette und Schriftarten-Slugs, die --nextora-font-*-Rollen) werden niemals umbenannt.

4. Lege nur die Verzeichnisse an, die das Child benötigt

Das Rezept steht in references/child-contract.md. Erforderlich: Wurzel-style.css, theme.json, functions.php. Füge inc/, resources/, assets/, templates/, parts/, patterns/ nach Bedarf hinzu, blocks/<block-slug>/ nur, wenn das Child tatsächlich benutzerdefinierte Blöcke ausliefert, und Schriftarten plus Lizenzdateien nur, wenn Schriftarten ausgeliefert werden. Erstelle kein leeres Feature-Gerüst und klone keinen ganzen Theme-Baum.

5. Schreibe den Header, dann die Versionskonstante, dann den Bootstrap

Die Reihenfolge ist wichtig: inc/bootstrap/version.php definiert die einzelne <CHILD_PREFIX>_VERSION-Konstante, die style.css-Header-Version Version: muss ihr entsprechen, und die Asset-Pipeline greift darauf zurück, daher muss die Konstante existieren, bevor irgendetwas die Pipeline benötigt. Deklariere im Header nur echte Mindestanforderungen — kopiere niemals den Tested up to-Wert eines anderen Themes.

6. Schreibe functions.php mit Child-vor-Eltern im Hinterkopf

WordPress lädt die functions.php eines Childs vor der des Eltern-Themes, daher darf nichts im Datei-Scope eine Eltern-Funktion aufrufen oder eine NEXTORA_*-Konstante lesen. Definiere die eigenen _DIR/_URI-Konstanten des Childs aus dem Stylesheet-Verzeichnis, binde den Composer-Autoloader nur ein, wenn er lesbar ist, und binde die eigenen Dateien des Childs ein. Jeder vom Eltern-Theme abhängige Vorgang gehört in einen Hook und referenziert Eltern-Handles beim Namen und prüft zuerst, ob sie registriert sind.

7. Richte die Asset-Pipeline ein

Child-Stylesheet auf wp_enqueue_scripts Priorität 25, abhängig von den global-styles und nextora-app des Eltern-Themes, wenn diese registriert sind; Child-Script auf Priorität 30, abhängig von nextora-main, wenn registriert; Editor-Canvas-Styles auf after_setup_theme Priorität 20 über add_editor_style(). Schütze jedes Einreihen mit einer Lesbarkeitsprüfung und verwende nicht kollidierende Ausgabe-Basenamen – ein Child assets/css/app.css oder assets/js/main.js kann das Asset des Eltern-Themes überschatten. Vollständiger Code und Hook-Tabelle: references/child-contract.md.

8. Füge den Block-Registrar nur hinzu, wenn das Child Blöcke ausliefert

WordPress scannt den blocks/-Ordner eines Themes nicht. Registriere jedes Verzeichnis, das eine lesbare block.json enthält, bei init über get_stylesheet_directory(), füge die Child-Einfügekategorie hinzu und spiegele die Kategorie-Erzwingung clientseitig. Block-Metadaten, Editor-UI und Renderer sind ../nextora-gutenberg-blocks/SKILL.md. Kein blocks/-Verzeichnis bedeutet keine Registrar-Anforderung.

9. Übergib das Erscheinungsbild an das Design-System

Wenn das Child den Voreinstellungen oder dem Besucher-Farb-/Schriftwechsel folgen muss, lade ../nextora-design-system/SKILL.md in derselben Sitzung und lasse es die Rollenbindungen, theme.json-Schriftfamilien und Voreinstellungsdateien festlegen. Der Body, Überschriften und Schaltflächen eines Childs werden über die Nextora-Rollenvariablen aufgelöst; sie werden niemals direkt an die Schriftarten eines Beispiel-Designs gebunden.

10. Überprüfe anhand der laufenden Website

Führe nur die Build-Befehle aus, die die package.json des Ziel-Childs selbst deklariert, lade dann eine Frontend-Seite und den Editor-Canvas und bestätige, dass die Assets tatsächlich eingereiht wurden und die Wächter keinen fehlenden Build versteckt haben. Das Akzeptanzrezept in references/child-contract.md ist der browser-seitige Beweis. Markiere alles, was du nicht getestet hast, als nicht verifiziert.

Abschlussprüfungen

• Eltern- und Child-Theme wurden aus ihrer eigenen style.css aufgelöst, nicht angenommen oder hartcodiert.
• Template: nextora vorhanden; Header Version entspricht <CHILD_PREFIX>_VERSION.
• Text Domain: entspricht dem Child-Slug, und jede übersetzbare Zeichenkette im Child-PHP/JS verwendet diese Domain.
• Kein Eltern-Funktionsaufruf und kein NEXTORA_*-Lesen im Child-Datei-Scope.
• Jede Enqueue/Editor-Style-Registrierung wird durch eine Lesbarkeitsprüfung und eine wp_style_is()/wp_script_is()-Prüfung geschützt, bevor ein Eltern-Handle hinzugefügt wird.
• Child-Asset-Basenamen kollidieren nicht mit den app.css / main.js des Eltern-Themes.
• Block-Registrar existiert nur, wenn blocks/ existiert, verwendet das Stylesheet-Verzeichnis, überspringt nicht lesbare block.json und registriert die Child-Kategorie.
• references/child-contract.md für die Struktur befolgt und quality-gates.md angewendet.
• Frontend und Editor-Canvas laden die Child-Assets tatsächlich.

Grenzen

Diese Fähigkeit ist Markdown-Anleitung. Sie liefert keinen Generator, keinen Starter-Theme-Baum, keinen Paketmanager und keinen Installer aus und bearbeitet niemals das Eltern-Theme oder das Beispiel-Child. Das npm run gen-Gerüst des Eltern-Themes ist nur für das Eltern-Theme; ein Child-Theme wird durch das Schreiben der hier beschriebenen Dateien erstellt.