Blocs Gutenberg Nextora

Blocs Nextora

Détient le contrat de code d'un bloc : métadonnées, enregistrement, interface d'édition, rendu dynamique, script de vue, consommation de la sortie de construction. Les règles d'apparence sont détenues par nextora-design-system ; les modèles et les patrons par nextora-site-composition ; l'échafaudage des thèmes enfants par nextora-child-themes. Chargez le skill du système de conception chaque fois qu'une demande touche à l'apparence d'un bloc, et chargez les deux chaque fois qu'un bloc doit suivre des préréglages ou le commutateur de visiteur.

Charger ces références en premier

Lisez uniquement ce dont la tâche a besoin, par chemin relatif depuis ce fichier :

Fichier	Lire pour
references/block-contract.md	Structure des dossiers, clés block.json, comportement de l'enregistreur, coercition des catégories, le générateur, le shim esbuild/window.wp et sa liste de 14 dépendances, sémantique save, contrats de rendu et de vue.
references/editor-and-repeaters.md	Les deux vrais éditeurs de listes (team-section et le repeater.tsx enfant), leurs sémantiques exactes de commit/annulation, les aides pour le texte enrichi et les médias.
../nextora-ecosystem/references/source-map.md	D'où vient chaque règle et comment la revérifier ; vocabulaire de résolution racine.
../nextora-ecosystem/references/quality-gates.md	Portails de données, parité, actifs, sécurité, i18n, accessibilité et les recettes d'acceptation en aval partagées (§8).

Ne traitez jamais une valeur citée dans une référence comme actuelle : relisez les fichiers propres du thème cible avant d'éditer.

Workflow ordonné

1. Résoudre la cible et le thème hôte du bloc

Identifiez la racine du thème parent et la racine du thème actif (enfant) à partir de l'installation en direct ou du dépôt fourni — get_template_directory() et get_stylesheet_directory(), ou les en-têtes style.css. Un bloc enfant n'existe que si l'enfant l'enregistre ; l'enregistreur parent lit uniquement le répertoire de modèle. Ne revendiquez jamais la compatibilité Nextora sans la source réelle de Nextora.

2. Lire les propres preuves de la cible

Dans cet ordre, en préférant les valeurs en direct à tout ce qui est écrit ici :

1. blocks/blocks.php — l'enregistreur, son glob, s'il vérifie la lisibilité, les filtres de catégorie, et quels fichiers PHP par bloc il inclut.
2. blocks/*/block.json — noms existants, catégories, supports, pointeurs d'actifs.
3. Les fichiers edit.tsx, render.php, view.ts facultatif, save.tsx, register-styles.php/register-editor.php du bloc existant le plus proche.
4. scripts/build-blocks.mjs — les globs d'entrée exacts et le shim.
5. package.json + .nvmrc — les commandes et la version de Node qui existent réellement.
6. theme.json — les slugs de palette, police, dégradé, taille de police et espacement auxquels le bloc devrait faire référence.

3. Décider de la réutilisation avant la création

Étendez un bloc existant lorsque la structure d'édition demandée existe déjà (un autre champ de titre, une autre liste, un autre bouton à bascule). Créez un bloc uniquement lorsque le comportement ou la structure d'édition demandé ne peut pas être exprimé par un bloc existant, un bloc de base, un motif ou une variation de style de bloc. Indiquez quel bloc existant vous avez réutilisé, ou pourquoi rien ne convenait — et indiquez-le dans le livrable, pas seulement dans la conversation : un docblock dans l'entrée d'éditeur du bloc plus une ligne dans le README du thème (nommant les candidats les plus proches que vous avez rejetés et ce qui manque à chacun). Un enregistreur qui ne lit que le dépôt doit pouvoir trouver cette décision.

4. Écrire les métadonnées en premier

block.json avec apiVersion: 3, namespace/textdomain/category (nextora + nextora dans le parent ; <slug-enfant> dans un enfant), attributs typés avec des valeurs par défaut réelles, supports pour l'apparence du wrapper, et des pointeurs d'actifs qui nomment des fichiers construits : editorScript: "file:./index.js", render: "file:./render.php", viewScript: "file:./view.js". La catégorie dans les métadonnées est cosmétique — PHP et l'éditeur forcent tous deux la catégorie du namespace — donc ne vous fiez jamais à theme ou à un autre slug pour placer le bloc.

5. Décider de save, puis construire l'éditeur

• Dynamique (PHP rend à partir des attributs) : render + save: () => null.
• Persiste les blocs imbriqués : save doit retourner useBlockProps.save() encapsulant <InnerBlocks.Content />.
• Statique : enregistrez exactement ce que l'analyseur attend.

Puis écrivez edit.tsx avec des champs natifs — RichText pour le texte visible, InnerBlocks pour le contenu imbriqué, les API médias pour les pièces jointes, les contrôles de lien de base pour les URL — et InspectorControls/PanelBody pour les paramètres, en réutilisant le vocabulaire de panneau existant. Les données répétées suivent references/editor-and-repeaters.md. Pas d'état UI persistant.

6. Écrire render.php (blocs dynamiques)

get_block_wrapper_attributes() sur la racine ; vos propres data-*/style fusionnés dans son tableau d'arguments ; échappement par contexte (esc_html, esc_attr, esc_url, wp_kses_post) ; couleurs limitées résolues via l'aide du thème ; chaque chaîne traduite dans le domaine du thème cible. Gardez les noms de classe de render.php alignés avec la feuille de style du bloc.

7. Câbler le comportement et les styles

Ajoutez view.ts uniquement si le bloc a besoin d'un comportement frontal : initialisation idempotente protégée par des attributs d'état, permutation chargement → prêt, espace de mise en page réservé, chemins à mouvement réduit et sans JS. Le CSS frontal est rédigé dans le style.css du bloc (ou l'import CSS du script de vue) et référencé via style/editorStyle ; le CSS de l'inspecteur et de l'aperçu du canevas reste limité au bloc, jamais au chrome wp-admin.

8. Construire, puis vérifier sur les surfaces réelles

Exécutez le script propre de la cible depuis la racine du thème (npm run build:blocks, ou npm run build, ou npm run build:blocks de l'enfant). Ne modifiez jamais à la main index.js, index.asset.php, view.js ou view.css. Ensuite, appliquez ../nextora-ecosystem/references/quality-gates.md et sa recette de bloc §8 plus les étapes spécifiques au bloc dans references/block-contract.md §11.

Limites strictes

• Pas de second runtime React, pas de pipeline blanket @wordpress/scripts, pas de second bundler. Réutilisez la configuration esbuild du thème.
• Ajouter une importation @wordpress/* non listée se construit mais peut lire un global window.wp.* non défini : le manifeste d'actifs ne liste qu'un ensemble fixe de 14 poignées. Vérifiez le global et sa poignée avant d'importer, ou évitez l'importation.
• N'ajoutez pas de bibliothèque que le bloc n'utilise pas ; les bibliothèques déjà dans package.json sont des plages, donc lisez le lockfile avant de vous fier à une API.
• Ne modifiez pas la forme d'un attribut persistant sans une entrée deprecated ou une migration unique, et ne convertissez jamais un schéma de liste indexé par clé en un schéma indexé par ID (ou vice-versa) pour rendre un outil d'édition pratique.
• N'ajoutez pas de routes REST, de cache, de télémétrie, de pages d'administration ou d'abstractions non liées pour satisfaire une demande de bloc.
• Ne modifiez pas les thèmes sources lors de la livraison de skills ou de documentation.

Vérifications d'achèvement

• Thème cible et hôte du bloc identifiés à partir de leurs propres fichiers ; rien de revendiqué ne repose sur une source non lue.
• Décision de réutilisation indiquée, ou raison concrète pour laquelle le bloc devait être nouveau.
• block.json nomme une paire namespace/catégorie/textdomain réelle et pointe uniquement vers des actifs construits ; le bloc apparaît sous la catégorie du namespace dans l'insertion.
• save correspond au type de stockage du bloc, vérifié par enregistrement → rechargement → ré-enregistrement sans avertissement de validation de bloc.
• Le texte visible, le contenu imbriqué, les médias et les URL utilisent des contrôles d'édition natifs ; l'éditeur d'élément est une boîte de dialogue unique ; aucun état UI n'est persistant.
• render.php échappe par contexte et traduit dans le domaine cible ; les couleurs limitées se résolvent via l'aide du thème et les valeurs vides suivent les valeurs par défaut du thème.
• Le comportement de la vue est idempotent, réserve la mise en page et respecte le mouvement réduit et le sans JS.
• La sortie de construction est régénérée avec le script propre de la cible ; les fichiers générés ne sont pas touchés à la main.
• Les étapes d'acceptation pertinentes §8 sont exécutées, ou la surface non vérifiée est rapportée clairement.

Limites

Instructions Markdown et références basées sur le code source uniquement. Ce skill ne livre pas de scripts runtime, de générateurs, d'arbres de thèmes copiés, de gestion de paquets ou d'automatisation d'installation, et il ne modifie pas les sources du thème parent ou enfant.