Système de design Nextora
Autorité unique pour l'apparence dans cette suite. Le code des thèmes enfants, le code des blocs, les modèles et les motifs se réfèrent tous ici pour la palette, la typographie, les jetons, les variations de style et le sélecteur. Chargez cette compétence avec nextora-child-themes pour tout nouvel enfant, et avec nextora-gutenberg-blocks pour tout bloc restylisé ou nouveau bloc.
Charger ces références en premier
| Fichier | À lire pour |
|---|---|
references/presets-and-switching.md | Identité canonique des préréglages, variables de rôle, stockage délimité des couleurs et résolution PHP, les deux mécanismes de style, le verrouillage de fonctionnalité, ce qu'un enfant apporte, les règles de découverte/fusion, la sémantique de scheme-switcher.json, la priorité d'exécution, les valeurs par défaut des rôles :root pour un nouvel enfant, et la liste des contre- revendications. |
../nextora-ecosystem/references/source-map.md | Vocabulaire de provenance et résolution racine. |
../nextora-ecosystem/references/quality-gates.md | Portes qualité et les recettes partagées d'acceptation en aval (§8). |
Les valeurs citées dans la référence sont des ancres, pas des données actuelles. Relisez le theme.json de la cible, son point d'entrée CSS, l'arborescence styles/ et les fichiers du sélecteur avant d'éditer.
Flux de travail ordonné
1. Résoudre la cible et identifier les sources d'apparence actives
Identifiez la racine du thème parent et la racine du thème actif. Lisez ensuite, dans l'ordre :
theme.json (palette, dégradés, familles de polices, tailles, espacements, styles,
customTemplates), le point d'entrée CSS livré (resources/css/app.css pour le
parent, le point d'entrée de l'enfant), l'arborescence styles/ et
scheme-switcher.json. Ne prenez jamais une valeur de palette depuis une compétence, une capture d'écran ou un exemple d'enfant.
2. Décider quel mécanisme est correct
| Besoin | Utiliser |
|---|---|
| L'auteur choisit une couleur/typographie/espacement pour un wrapper de bloc | Prise en charge native du bloc supports + get_block_wrapper_attributes() |
| Une couleur à l'intérieur de la surface propre du bloc | Un attribut délimité, stocké comme slug de préréglage, résolu en variable de préréglage à la sortie (§5) |
| Un aspect alternatif à l'échelle du site que le propriétaire choisit et conserve | Une variation de style de theme.json (styles/*.json, styles/typography/*.json) |
| Un choix de prévisualisation pour le visiteur | Le sélecteur, et uniquement derrière son verrouillage (§6) |
| Une valeur par défaut de marque pour un thème enfant complet | Une contribution de palette/police de l'enfant plus les valeurs par défaut des rôles :root (§7) |
Privilégiez d'abord les prises en charge natives. Ajoutez une substitution délimitée uniquement lorsque les styles globaux ne peuvent pas l'exprimer, et n'inventez jamais un deuxième système d'apparence en dehors de ceux-ci.
3. Modifier les préréglages de manière additive et par identifiant
Ajoutez des slugs ; ne renommez pas et ne redirigez pas un slug parent que le contenu hérité utilise déjà.
Chaque surface lit var(--wp--preset--color--<slug>),
var(--wp--preset--gradient--<slug>) ou var(--wp--preset--font-family--<slug>),
donc un hexadécimal littéral dans le CSS du thème exclut cette surface des changements de palette et du sélecteur. Ne reflétez les alias @theme Tailwind que là où la construction CSS les consomme, et vérifiez ce que chaque alias pointe réellement plutôt que de copier un bloc d'alias depuis un guide plus ancien — le --color-secondary du parent se résout actuellement au préréglage paragraph.
4. Router la typographie à travers les rôles Nextora
La typographie du corps, des titres et des boutons se résout via --nextora-font-body,
--nextora-font-heading et --nextora-font-button. theme.json utilise
var(--nextora-font-body) ; le sélecteur écrit ces trois propriétés en ligne sur
<html> avec une pile de familles concrète. Une surface qui lit directement une variable de préréglage ne suivra pas un changement de police du visiteur. Ajoutez ou modifiez une famille de polices dans
theme.json (avec les ressources fontFace lorsqu'il ne s'agit pas d'une pile système) et chargez-la avant de la proposer comme choix de préréglage.
5. Stocker les couleurs délimitées comme préréglages, les résoudre à la sortie
Suivez le modèle d'assistant existant dans blocks/advanced-icon/color-utils.ts
(normalizeColorForStorage, colorValueForPicker) et ses homologues PHP
(nextora_icon_resolve_color, nextora_icon_hex_to_preset_slug,
nextora_ac_resolve_color) : un préréglage choisi stocke son slug ; un hexadécimal
à opacité totale correspondant à une entrée de palette se normalise en slug de cette entrée ; les couleurs personnalisées et les hexadécimaux partiellement opaques à 8 chiffres restent littéraux ; les dégradés conservent l'identité du préréglage de la même manière.
À la sortie, un slug stocké devient var(--wp--preset--color--<slug>) afin qu'un changement
change la palette atteigne la surface, et les hexadécimaux à 8 chiffres sont traités avant
sanitize_hex_color(). Une valeur vide signifie « valeur par défaut du thème » et n'émet rien.
Réutilisez les signatures réelles ; n'écrivez pas un résolveur parallèle. Rappelez-vous qu'un contrôle de couleur
n'est pas un assainisseur : le HTML stocké passe toujours wp_kses_post().
6. Respecter le verrouillage du sélecteur et contribuer des données plutôt que du code
Le sélecteur pour visiteur existe uniquement lorsque NEXTORA_COLOR_SCHEME_SWITCHER est strictement
true. En dehors de cela, il n'y a pas de charge utile, pas de script, pas de CSS de thème de page et pas
popover — et aucune substitution du côté enfant ne doit être écrite pour combler le vide. Un enfant
contribue des données : styles/color-scheme/*.json, styles/font-preset/*.json,
éventuellement styles/*.json pour une variation incluse, et une liste d'autorisation
scheme-switcher.json facultative. Lors de la création d'un nouvel enfant, définissez les rôles par défaut propres de l'enfant
sur :root dans son CSS chargé ultérieurement (§7 de la référence) au lieu de fixer une police de préréglage. N'ajoutez jamais d'implémentation de sélecteur à un enfant.
7. Vérifier sur les surfaces réelles
Construisez avec le script propre de la cible (npm run build:css ou npm run build) — ne modifiez jamais
la sortie assets/css/*, et ne déclarez jamais qu'une construction régénère
assets/js/scheme-switcher.js, qui est maintenu manuellement et en dehors du pipeline.
Appliquez ensuite ../nextora-ecosystem/references/quality-gates.md et sa recette §8
du système de design ainsi que les étapes spécifiques aux préréglages dans
references/presets-and-switching.md §10.
Limites strictes
- Ne codez pas en dur une palette de marque. Les valeurs proviennent des préréglages actifs de la cible.
- Ne propagez pas d'hexadécimaux de secours obsolètes provenant d'anciens documents dans le nouveau CSS du thème.
- Ne réimplémentez pas le sélecteur et ne prétendez pas qu'il fonctionne parce qu'un exemple d'enfant semble correct : l'exemple fixe ses propres polices et ajoute des entrées de palette réservées aux enfants.
- Ne promettez pas qu'un paramètre d'URL de couleur remplace un thème groupé déjà résolu, ou que Réinitialisation efface les styles de l'éditeur de site.
- Ne restylisez pas l'interface
wp-adminà partir d'une feuille de style de thème ; les réinitialisations d'éditeur restent à l'intérieur du canevas de l'éditeur. - Ne réduisez pas silencieusement la version minimale déclarée de WordPress/PHP — mettez en surface l'exigence à la place.
- Ne modifiez pas le thème parent ou l'exemple d'enfant pendant la réalisation de ce travail.
Vérifications d'achèvement
- Thème cible résolu ; chaque préréglage, police, dégradé et jeton référencé existe dans
le
theme.json/variations de ce thème. - Le tableau des mécanismes à l'étape 2 a été suivi ; les prises en charge natives utilisées lorsqu'elles suffisent.
- La typographie se résout via les rôles
--nextora-font-*et suit un changement de préréglage. - Les couleurs délimitées stockent un slug de préréglage lorsque la couleur correspond à un préréglage, conservent les valeurs personnalisées et partiellement opaques littéralement, et se rendent via des variables de préréglage.
- Le verrouillage du sélecteur est respecté ; la contribution d'un enfant est uniquement des données ; toute paire
par défaut d'un nouvel enfant est déclarée sur
:rootvia les rôles. - Les variations de style (persistantes) et le sélecteur (prévisualisation à l'exécution) sont décrits et testés comme des choses différentes.
- Les étapes d'acceptation du §8 ont été exécutées sur des styles calculés, ou la surface non vérifiée est rapportée clairement.
Limites
Instructions Markdown et références sourcées uniquement : pas de scripts d'exécution, de générateurs,
d'arbres de thèmes copiés, de gestion de paquets ou d'automatisation d'installation, et
aucune modification des sources du thème parent ou enfant. Les commandes de construction et de vérification
en aval dans le navigateur appartiennent au thème cible et sont listées dans
../nextora-ecosystem/references/quality-gates.md.