miketropi/nextora-child-themes

Thèmes enfants Nextora

Crée et audite les thèmes enfants de Nextora : l'amorçage, le pipeline d'actifs et l'enregistreur de blocs enfant. Les conventions de niveau parent vivent dans le parent lui-même ; les détails internes des blocs appartiennent à ../nextora-gutenberg-blocks/SKILL.md, et tout ce qui concerne la palette, les polices ou le sélecteur visiteur appartient à ../nextora-design-system/SKILL.md.

Références à charger

Lisez ces fichiers avant d'écrire un quelconque fichier, par chemin relatif :

• references/child-contract.md — la table de substitution slug/préfixe, la recette exacte des répertoires, l'en-tête, le code d'amorçage et d'enfilement, l'enregistreur, les conventions PHP, les défauts observés de l'exemple et la recette d'acceptation WordPress en aval. Chargez-le à l'étape 3 et n'écrivez pas de code avant de l'avoir fait.
• source-map.md — d'où provient chaque règle, avec des étiquettes de provenance et les faits souvent mal cités.
• quality-gates.md — les critères de qualité que le thème enfant terminé doit respecter. Chargez-le avant de déclarer la tâche terminée.

La lecture des sources locales prime sur la lecture de ces fichiers. Chaque valeur citée dans un skill ou une référence est une ancre, pas un fait actuel.

Workflow ordonné

1. Résoudre les racines, ne pas les supposer

Dans une installation active, le parent est le répertoire des templates et l'enfant est le répertoire des feuilles de style :

get_template_directory();      // racine parent
get_stylesheet_directory();    // racine du thème actif (enfant quand il est actif)

En dehors d'une installation, trouvez un fichier style.css avec Theme Name: Nextora pour le parent et un avec Template: nextora pour l'enfant. Si la source du parent est vraiment manquante, dites-le et arrêtez de revendiquer la compatibilité Nextora ; terminez uniquement le travail qui n'en dépend pas. Ne fabriquez jamais une ancre et ne substituez jamais un autre thème silencieusement.

2. Lire les preuves avant de proposer quoi que ce soit

Depuis le thème enfant cible — ou l'enfant exemple, quand c'est l'exemple qui est porté :

1. style.css — l'en-tête réel : Template, Version, Requires at least, Requires PHP, Tested up to, Text Domain, License.
2. functions.php — l'ordre de chargement et ce que le thème nécessite au niveau fichier.
3. theme.json — version, slugs de palette/polices, customTemplates, templateParts.
4. package.json et .nvmrc — quels scripts de construction existent, et sur quel Node.
5. inc/, blocks/, resources/, assets/ — ce qui existe déjà.

Depuis le parent : style.css, functions.php, inc/assets/assets.php, blocks/blocks.php. Ce sont ceux dont dépend un thème enfant, donc leurs noms de gestionnaire et le comportement de l'enregistreur sont le contrat, pas la documentation.

3. Corriger la table de nommage avant d'écrire des fichiers

Chargez references/child-contract.md et remplissez sa table de substitution pour le slug demandé. Chaque identifiant généré — fonctions PHP, constantes, domaine de texte, noms de blocs, classes CSS, propriétés personnalisées, slugs de motifs, gestionnaires et noms de base de fichiers — provient de ce seul slug. Les noms appartenant au parent (nextora_*, NEXTORA_*, nextora/*, global-styles, nextora-app, nextora-main, les slugs de palette et polices du parent, les rôles --nextora-font-*) ne sont jamais renommés.

4. Disposer uniquement des répertoires dont le thème enfant a besoin

La recette est dans references/child-contract.md. Obligatoires : racine style.css, theme.json, functions.php. Ajoutez inc/, resources/, assets/, templates/, parts/, patterns/ selon le cas, blocks/<block-slug>/ uniquement quand l'enfant livre effectivement des blocs personnalisés, et les polices plus fichiers de licence uniquement quand les polices sont livrées. Ne créez pas d'échafaudage de fonctionnalités vides et ne clonez pas une arborescence de thème entière.

5. Écrire l'en-tête, puis la constante de version, puis l'amorçage

L'ordre compte : inc/bootstrap/version.php définit la constante <CHILD_PREFIX>_VERSION unique, l'en-tête Version: de style.css doit lui être égal, et le pipeline d'actifs y fait appel, donc la constante doit exister avant que quoi que ce soit n'utilise le pipeline. Dans l'en-tête, déclarez seulement les minimas réels — ne copiez jamais la valeur Tested up to d'un autre thème.

6. Écrire functions.php avec l'enfant avant le parent à l'esprit

WordPress charge le functions.php d'un thème enfant avant celui du parent, donc rien au niveau fichier ne peut appeler une fonction parent ou lire une constante NEXTORA_*. Définissez les constantes _DIR/_URI propres à l'enfant à partir du répertoire des feuilles de style, n'incluez l'autoloader Composer que s'il est lisible, et incluez les fichiers propres de l'enfant. Toute opération dépendant du parent appartient dans un hook, et référence les gestionnaires parent par leur nom et vérifie d'abord s'ils sont enregistrés.

7. Câbler le pipeline d'actifs

Feuille de style enfant sur wp_enqueue_scripts priorité 25, dépendant de global-styles et nextora-app du parent lorsqu'ils sont enregistrés ; script enfant sur priorité 30 dépendant de nextora-main lorsqu'il est enregistré ; styles de canevas d'éditeur sur after_setup_theme priorité 20 via add_editor_style(). Protégez chaque enfilement avec une vérification de fichier lisible, et utilisez des noms de base de sortie non conflictuels — un assets/css/app.css ou assets/js/main.js d'un enfant peut faire de l'ombre à l'actif du parent. Code complet et table des hooks : references/child-contract.md.

8. Ajouter l'enregistreur de blocs uniquement quand l'enfant livre des blocs

WordPress ne scanne pas le dossier blocks/ d'un thème. Enregistrez chaque répertoire qui contient un block.json lisible sur init à partir de get_stylesheet_directory(), ajoutez la catégorie d'insertion de l'enfant, et reflétez la coercition de catégorie côté client. Les métadonnées de bloc, l'UI d'édition et les moteurs de rendu sont dans ../nextora-gutenberg-blocks/SKILL.md. Pas de répertoire blocks/ signifie pas d'exigence d'enregistreur.

9. Confier l'apparence au système de design

Si l'enfant doit suivre la commutation de couleur/police prédéfinie ou visiteur, chargez ../nextora-design-system/SKILL.md dans la même session et laissez-le décider des liaisons de rôles, des familles de polices theme.json et des fichiers de préréglages. Le corps, les titres et les boutons d'un enfant se résolvent via les variables de rôles Nextora ; ils ne sont jamais liés directement aux polices d'un seul exemple de design.

10. Vérifier sur le site en cours d'exécution

Exécutez uniquement les commandes de construction que le package.json propre au thème enfant cible déclare, puis chargez une page front-end et le canevas d'éditeur et confirmez que les actifs sont effectivement enfilés et que la garde n'a pas caché une construction manquante. La recette d'acceptation dans references/child-contract.md est la preuve au niveau navigateur. Marquez tout ce que vous n'avez pas testé comme non vérifié.

Vérifications d'achèvement

• Parent et enfant résolus depuis leur propre style.css, pas supposés ou codés en dur.
• Template: nextora présent ; Version: de l'en-tête égal à <CHILD_PREFIX>_VERSION.
• Text Domain: égal au slug de l'enfant, et chaque chaîne traduisible dans le PHP/JS de l'enfant utilise ce domaine.
• Aucun appel de fonction parent et aucune lecture de NEXTORA_* au niveau fichier de l'enfant.
• Chaque enregistrement d'enfilement / de style d'éditeur est protégé par une vérification de fichier lisible et une vérification wp_style_is()/wp_script_is() avant d'ajouter un gestionnaire parent.
• Les noms de base des actifs de l'enfant n'entrent pas en conflit avec app.css / main.js du parent.
• L'enregistreur de blocs existe uniquement si blocks/ existe, utilise le répertoire des feuilles de style, ignore les block.json illisibles et enregistre la catégorie de l'enfant.
• references/child-contract.md suivi pour la structure, et quality-gates.md appliqué.
• Le front-end et le canevas d'éditeur chargent effectivement les actifs de l'enfant.

Limites

Ce skill est une instruction Markdown. Il ne livre aucun générateur, arborescence de thème de démarrage, gestionnaire de paquets ou installateur, et il ne modifie jamais le parent ou l'enfant exemple. L'échafaudage npm run gen du parent est réservé au parent ; un thème enfant est créé en écrivant les fichiers décrits ici.