miketropi/nextora-composition-site

Composition de site Nextora

Possède la couche de composition d'un thème bloc provenant de Nextora : templates/, parts/, patterns/ et les déclarations theme.json qui les décrivent. Les internes des blocs sont dans ../nextora-gutenberg-blocks/SKILL.md ; les données d'apparence et de préréglages sont dans ../nextora-design-system/SKILL.md ; le bootstrap enfant et les assets sont dans ../nextora-child-themes/SKILL.md.

Références à charger

• references/templates-and-patterns.md — la hiérarchie des templates avec les vrais noms de fichiers, la propriété des parties et les règles de surcharge, les conventions d'en-tête et de catégorie des motifs, la recette du motif caché plus template mince, la composition des requêtes et les aides à l'assainissement, la personnalisation fichiers vs base de données, les défauts observés, et la recette d'acceptation WordPress en aval. Chargez-la avant l'étape 3.
• source-map.md — provenance de chaque ancre nommée ici.
• quality-gates.md — les portes qui décident si la composition est terminée.

Les fichiers locaux l'emportent sur toute valeur citée dans ces références.

Flux de travail ordonné

1. Résoudre les racines du thème et lire les surfaces locales

Le thème parent est le répertoire des templates, le thème actif est le répertoire de la feuille de style :

get_template_directory();      // racine parent
get_stylesheet_directory();    // racine du thème actif (enfant lorsqu'un est actif)

Lire, dans cet ordre : theme.json (customTemplates, templateParts), templates/, parts/, patterns/, les noms blocks/*/block.json de la cible, et inc/ pour les aides de requête ou de template. Une copie enfant d'un template ou d'une partie écrase le fichier parent de même nom, donc ce qui existe déjà décide la plupart de la réponse.

2. Trouver ce qui existe déjà avant de composer quoi que ce soit

La réutilisation l'emporte sur l'invention, dans cet ordre :

1. Un motif existant qui est déjà la section.
2. Un bloc existant (parent nextora/* ou propre à l'enfant) qui rend déjà la section.
3. Un nouveau motif enfant composé de blocs existants.
4. Un template mince qui assemble ces motifs.
5. Une surcharge de partie enfant — uniquement pour une surface que l'enfant possède réellement.
6. Un nouveau bloc — uniquement lorsque le comportement demandé ou la structure d'édition ne peut être exprimé par aucun bloc existant.

Ne jamais livrer d'articles factices en tant que contenu de production, et ne jamais cloner le backend du formulaire de contact parent : le parent livre déjà le bloc nextora/contact-form, et la page de contact de l'exemple le compose à l'intérieur d'un groupe wrapper enfant.

3. Placer la composition dans le bon template

Appliquer la hiérarchie de references/templates-and-patterns.md :

• front-page.html gouverne la page d'accueil lorsqu'elle est présente ; home.html est l'index des articles, pas un synonyme de la page d'accueil ; index.html est le fallback.
• Les templates d'archive, d'article unique, de recherche et spécifiques à une page précèdent le fallback index.
• Un nom déclaré dans theme.json customTemplates doit avoir un templates/<name>.html correspondant dans le thème qui le déclare.

Lire la liste templates/ du thème lui-même plutôt que de deviner les noms de fichiers : le parent livre 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 ; l'enfant exemple livre son propre ensemble, nommé différemment.

4. Décider de la propriété des parties, puis référencer la partie

Une référence wp:template-part se résout d'abord sur le répertoire de la feuille de style, donc une parts/header.html enfant remplace l'en-tête parent partout où il est utilisé.

• Garder l'en-tête/pied de page parent si l'enfant n'a aucune raison de les posséder : ne pas ajouter une partie copiée.
• Si l'enfant possède une partie, lui donner un corps possédé par l'enfant et le dire dans la référence ; ne pas laisser un attribut theme qui épingle la copie parent.
• La parts/header.html et parts/footer.html de l'enfant exemple sont chacune une référence de bloc (nextsaas/site-header, nextsaas/site-footer) ; la partie en-tête du parent compose nextora/scrolling-promotion et nextora/header.
• La syntaxe de référence dans les sources est {"slug":"header","tagName":"div"} chez l'enfant et {"slug":"header","tagName":"header","area":"header"} chez le parent. Suivre la propre convention de la cible ; ne jamais coder en dur un chemin de système de fichiers.

5. Créer les motifs en tant que fichiers PHP avec un véritable en-tête

Les motifs vivent dans patterns/*.php. Leur enregistrement provient de l'en-tête du fichier, pas d'un appel register_block_pattern() — aucun thème source ne l'appelle ; tous deux n'enregistrent que des catégories en PHP. Les champs d'en-tête requis et les règles de slug sont dans references/templates-and-patterns.md :

• Title, Slug: <slug-enfant>/<slug-motif> (unique), Categories, et une Description qui dit quand l'utiliser.
• Le corps du motif est le balisage de bloc sérialisé que l'éditeur insère, commençant après la fermeture */ du commentaire d'en-tête.
• Il doit être analysable, utiliser uniquement des blocs enregistrés, et rester modifiable après insertion.

6. Donner à une composition pleine page exactement une autorité

Pour une nouvelle composition pleine page, mettre la liste des sections dans un motif caché du système de fichiers — Inserter: no dans l'en-tête — et la référencer depuis un template mince :

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

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

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

Ne pas répéter la liste des sections dans le template également. L'exemple contient actuellement la même liste deux fois (patterns/page-home.php et templates/front-page.html), et les templates parent intègrent du balisage de motif avec metadata.patternName ; cette duplication est ce que cette règle remplace pour les nouveaux travaux. Lors de la simple édition d'un bloc existant, garder la duplication existante — mettre à jour les autres copies uniquement si le contenu de la section a effectivement changé.

7. Composer les requêtes avec les blocs core et un contexte explicite

• Archives, index des articles, recherche et détail d'article délèguent à wp:query avec "inherit":true, donc la requête principale fournit le contexte ; les index.html, home.html, archive.html et search.html de l'exemple font tous cela.
• Construire la boucle avec core/post-template plus les blocs core/post-*, ajouter wp:query-pagination, et toujours fournir wp:query-no-results.
• Utiliser wp:query-title, core/post-title, core/post-content, core/comments + core/comment-template + wp:comments-pagination + wp:post-comments-form pour la surface d'article unique plutôt qu'une boucle classique.
• Un bloc qui démarre sa propre boucle passe des attributs assainis : réutiliser les aides du inc/blocks/query.php enfant là où elles existent, sinon limiter les tailles de page et valider les types d'articles, taxonomies et termes par rapport aux valeurs autorisées. Le SQL préparé n'est pas un substitut à cette validation.

8. Maintenir les déclarations theme.json précises

Déclarer les entrées customTemplates et templateParts uniquement pour les surfaces que le thème possède, et uniquement pour les noms qui ne sont pas des templates core. Voir references/templates-and-patterns.md pour la re-déclaration observée dans l'exemple et la règle pour les nouveaux travaux.

9. Tenir compte de l'éditeur de site

Les templates et parties de template du système de fichiers peuvent être masqués par des personnalisations en base de données sauvegardées dans l'éditeur de site. Si une modification de fichier ne change pas le frontal, chercher un template ou un style sauvegardé avant de toucher au fichier. Ne jamais écraser silencieusement les personnalisations d'un vrai site ; inspecter ou réinitialiser uniquement un environnement jetable.

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

Résoudre chaque template et partie dans le frontal, confirmer que les motifs s'insèrent et restent modifiables, confirmer le WordPress minimum demandé et la version supportée actuelle, et exécuter la recette navigateur dans references/templates-and-patterns.md. Marquer tout ce que vous n'avez pas exercé comme non vérifié.

Vérifications de complétion

• Chaque template et chaque partie utilisé se résout sur le thème prévu ; aucun attribut theme égaré n'épingle une partie parent depuis un template enfant.
• Aucun nouveau bloc inutile, aucun template de page PHP classique, aucun contenu de production factice.
• Nouvelle composition pleine page : une autorité dans un motif caché, référencée depuis un template mince ; pas de liste de sections dupliquée.
• Les motifs s'analysent, utilisent des blocs enregistrés, gardent des slugs uniques, et leurs catégories sont celles que le thème enregistre en PHP.
• Les boucles de requête utilisent un contexte explicite, des attributs assainis et un état sans résultat.
• theme.json ne déclare que des noms de templates possédés, non core.
• quality-gates.md appliquées, y compris sa section d'acceptation de composition.

Limites

Instruction Markdown uniquement : pas de scripts runtime, générateurs, arbres de thèmes copiés ou installateurs, et aucune modification du parent ou de l'enfant exemple. La bibliothèque de motifs du parent et les compositions de l'exemple sont des preuves à lire, pas des fichiers à dupliquer.