nextora-gutenberg-blocks

Nextora Blöcke

Besitzt den Code-Vertrag für einen Block: Metadaten, Registrierung, Editor-UI, dynamisches Rendering, View-Skript, Build-Ausgabe-Konsum. Aussehensregeln werden von nextora-design-system verwaltet; Vorlagen und Patterns von nextora-site-composition; Child-Theme-Gerüste von nextora-child-themes. Lade das Design-System-Skill immer dann, wenn eine Anfrage das Aussehen eines Blocks betrifft, und lade beide, wenn ein Block Voreinstellungen oder den Visitor-Switcher befolgen muss.

Lade diese Referenzen zuerst

Lies nur, was die Aufgabe benötigt, relativ zu dieser Datei:

Datei	Lies sie für
references/block-contract.md	Ordnerstruktur, block.json-Schlüssel, Registrar-Verhalten, Kategorie-Erzwingung, den Generator, den esbuild/window.wp-Shim und seine 14-Handle-Abhängigkeitsliste, save-Semantik, Render- und View-Verträge.
references/editor-and-repeaters.md	Die beiden echten Listen-Editoren (team-section und das Child repeater.tsx), ihre exakten Commit/Cancel-Semantiken, Rich-Text- und Medien-Helfer.
../nextora-ecosystem/references/source-map.md	Woher jede Regel stammt und wie man sie erneut überprüft; Root-Auflösungsvokabular.
../nextora-ecosystem/references/quality-gates.md	Daten-, Paritäts-, Asset-, Sicherheits-, i18n-, Barrierefreiheits-Gates und die gemeinsamen Downstream-Abnahmerezepte (§8).

Behandle einen in einer Referenz zitierten Wert niemals als aktuell: Lies die Dateien des Ziel-Themes erneut, bevor du Änderungen vornimmst.

Geordneter Workflow

1. Bestimme das Ziel und das Host-Theme des Blocks

Identifiziere das Parent-Theme-Root und das aktive (Child-)Theme-Root aus der Live-Installation oder dem bereitgestellten Repository – get_template_directory() und get_stylesheet_directory(), oder die style.css-Header. Ein Child-Block existiert nur, wenn das Child ihn registriert; der Parent-Registrar liest nur das Template-Verzeichnis. Behaupte niemals Nextora-Kompatibilität ohne die echte Nextora-Quelle.

2. Lies die eigenen Nachweise des Ziels

In dieser Reihenfolge, bevorzuge Live-Werte gegenüber allem, was hier geschrieben steht:

1. blocks/blocks.php – der Registrar, sein Glob, ob er die Lesbarkeit prüft, Kategoriefilter und welche block-spezifischen PHP-Dateien er einbindet.
2. blocks/*/block.json – vorhandene Namen, Kategorien, supports, Asset-Pointer.
3. Das edit.tsx, render.php, optionale view.ts, save.tsx, register-styles.php/register-editor.php des nächstgelegenen vorhandenen Blocks.
4. scripts/build-blocks.mjs – die genauen Entry-Globs und der Shim.
5. package.json + .nvmrc – die Befehle und die Node-Version, die tatsächlich existieren.
6. theme.json – Palette, Schriftart, Verlauf, Schriftgröße und Abstand-Slugs, auf die der Block verweisen sollte.

3. Entscheide über Wiederverwendung vor Neuerstellung

Erweitere einen vorhandenen Block, wenn die angeforderte Bearbeitungsstruktur bereits existiert (ein weiteres Überschriftfeld, eine weitere Liste, ein weiterer Umschalter). Erstelle einen Block nur dann, wenn das angeforderte Verhalten oder die Bearbeitungsstruktur nicht durch einen vorhandenen Block, Core-Block, ein Pattern oder eine Blockstil-Variation ausgedrückt werden kann. Gib an, welchen vorhandenen Block du wiederverwendet hast, oder warum nichts passte – und gib es im Deliverable an, nicht nur im Gespräch: ein Docblock im Editor-Eintrag des Blocks plus eine Zeile im README des Themes (nenne die nächsten Kandidaten, die du abgelehnt hast, und was jedem fehlt). Ein Recorder, der nur das Repository liest, muss diese Entscheidung finden können.

4. Schreibe zuerst die Metadaten

block.json mit apiVersion: 3, Namespace/Textdomain/Kategorie (nextora + nextora im Parent; <child-slug> in einem Child), typisierte Attribute mit echten Standardwerten, supports für das Wrapper-Aussehen und Asset-Pointer, die gebaute Dateien benennen: editorScript: "file:./index.js", render: "file:./render.php", viewScript: "file:./view.js". Die Kategorie in den Metadaten ist kosmetisch – sowohl PHP als auch der Editor erzwingen die Namespace-Kategorie – verlasse dich daher niemals auf theme oder einen anderen Slug, um den Block zu platzieren.

5. Entscheide save, dann baue den Editor

• Dynamisch (PHP rendert aus Attributen): render + save: () => null.
• Bestehende verschachtelte Blöcke: save muss useBlockProps.save() zurückgeben, das <InnerBlocks.Content /> umschließt.
• Statisch: Speichere exakt das, was der Parser erwartet.

Schreibe dann edit.tsx mit nativen Feldern – RichText für sichtbaren Text, InnerBlocks für verschachtelte Inhalte, Medien-APIs für Anhänge, Core-Link-Steuerungen für URLs – und InspectorControls/PanelBody für Einstellungen, wobei das vorhandene Panel-Vokabular wiederverwendet wird. Wiederholte Daten folgen references/editor-and-repeaters.md. Kein persistierter UI-Zustand.

6. Schreibe render.php (dynamische Blöcke)

get_block_wrapper_attributes() auf der Wurzel; eigene data-*/Style in das Argument-Array eingefügt; Escaping nach Kontext (esc_html, esc_attr, esc_url, wp_kses_post); bereichsbezogene Farben über den Theme-Helfer aufgelöst; jeder String in der Domain des Ziel-Themes übersetzt. Halte die Klassennamen in render.php mit dem Block-Stylesheet konsistent.

7. Verknüpfe Verhalten und Styles

Füge view.ts nur hinzu, wenn der Block Frontend-Verhalten benötigt: idempotente Initialisierung, geschützt durch Zustandsattribute, ein Lade-→Bereit-Wechsel, reservierter Layout-Platz, Wege für reduzierte Bewegung und kein JS. Frontend-CSS wird im style.css des Blocks (oder im CSS-Import des View-Skripts) verfasst und über style/editorStyle referenziert; Inspektor- und Canvas-Vorschau-CSS bleibt auf den Block beschränkt, niemals auf wp-admin-Chrome.

8. Baue, dann überprüfe auf den echten Oberflächen

Führe das eigene Skript des Ziels vom Theme-Root aus (npm run build:blocks, oder npm run build, oder das Child-eigene npm run build:blocks). Bearbeite niemals index.js, index.asset.php, view.js oder view.css von Hand. Wende dann ../nextora-ecosystem/references/quality-gates.md und dessen §8-Block-Rezept sowie die block-spezifischen Schritte in references/block-contract.md §11 an.

Harte Grenzen

• Keine zweite React-Laufzeit, keine pauschale @wordpress/scripts-Pipeline, kein zweiter Bundler. Verwende das esbuild-Setup des Themes wieder.
• Das Hinzufügen eines nicht gelisteten @wordpress/*-Imports baut zwar, kann aber eine undefinierte window.wp.*-Globale lesen: Das Asset-Manifest listet nur einen festen Satz von 14 Paket-Handles. Überprüfe die Globale und ihr Handle vor dem Importieren oder vermeide den Import.
• Füge keine Bibliothek hinzu, die der Block nicht verwendet; Bibliotheken, die bereits in package.json sind, sind Bereiche, also lies die Lockfile, bevor du dich auf eine API verlässt.
• Ändere die Form eines persistierten Attributs nicht ohne einen deprecated-Eintrag oder eine einmalige Migration und konvertiere niemals ein index-keyed Listenschema in ein ID-keyed (oder zurück), um einen Editor-Helfer bequemer zu machen.
• Füge keine REST-Routen, Caching, Telemetrie, Admin-Seiten oder nicht zusammenhängende Abstraktionen hinzu, um eine Block-Anfrage zu erfüllen.
• Ändere die Quell-Themes während der Bereitstellung von Skills oder Dokumentation nicht.

Abschlussprüfungen

• Ziel-Theme und Block-Host aus den eigenen Dateien identifiziert; nichts Behauptetes steht auf ungelesener Quelle.
• Wiederverwendungsentscheidung angegeben oder ein konkreter Grund, warum der Block neu sein musste.
• block.json benennt ein echtes Namespace/Kategorie/Textdomain-Paar und zeigt nur auf gebaute Assets; der Block erscheint unter der Namespace-Kategorie im Inserter.
• save passt zur Speicherart des Blocks, überprüft durch Speichern → Neu laden → Erneutes Speichern ohne Blockvalidierungswarnung.
• Sichtbarer Text, verschachtelte Inhalte, Medien und URLs verwenden native Bearbeitungssteuerungen; der Element-Editor ist ein einzelner Dialog; kein UI-Zustand wird persistiert.
• render.php escapet nach Kontext und übersetzt in der Zieldomain; bereichsbezogene Farben werden über den Theme-Helfer aufgelöst und leere Werte folgen den Theme-Standardwerten.
• View-Verhalten ist idempotent, reserviert Layout und respektiert reduzierte Bewegung und kein JS.
• Build-Ausgabe mit dem eigenen Skript des Ziels neu generiert; generierte Dateien nicht von Hand berührt.
• Relevante §8-Abnahmeschritte ausgeführt oder die nicht verifizierte Oberfläche klar gemeldet.

Grenzen

Nur Markdown-Anweisungen und quellgestützte Referenzen. Dieses Skill liefert keine Laufzeit-Skripte, Generatoren, kopierte Theme-Bäume, Paketverwaltung oder Installationsautomatisierung und es ändert keine Parent- oder Child-Theme-Quellen.