Une bonne organisation de design doit permettre de répondre rapidement à trois questions : où se trouve cette section, quelle donnée l’alimente et quel fichier change son apparence ? Avec Phoenix, le dossier propre au projet sert de frontière pratique pour ces décisions.
L’objectif est de personnaliser le site en conservant les composants communs réutilisables et une livraison compréhensible.
Donner un rôle à chaque dossier
Dans parts/, placez les présentations Twig des blocs et des contenus classiques. hero.twig présente une introduction, about.twig une section de présentation et single-post.twig un article WordPress.
Le dossier php/part/ contient des fragments PHP appelables par load_design(). Ils sont utiles lorsqu’un petit traitement WordPress est plus naturel en PHP. php/templates/ sert aux parcours particuliers qui justifient une logique plus importante.
Les feuilles CSS, scripts, images et polices vont dans assets/. Leur registre reste assets/styles.json. Cette séparation permet de comprendre la dépendance entre une interface et les fichiers nécessaires à son rendu.
mon-design/
parts/
hero.twig
about.twig
single-post.twig
ui/button.twig
php/
part/article-content.php
templates/
assets/
styles.json
css/design.css
js/navigation.js
Séparer les données des décisions visuelles
Un titre, une adresse courriel ou la destination d’un bouton ne devraient pas être recopiés dans plusieurs fichiers lorsqu’un réglage natif existe. Utilisez les champs de bloc pour les contenus locaux, settings pour les valeurs globales et les menus WordPress pour la navigation.
En revanche, une grille de deux colonnes, un espacement ou une transition appartiennent au design. Cette frontière devient particulièrement utile au moment de modifier l’identité d’un site : les contenus peuvent être conservés pendant que sa présentation évolue.
Lisez le contrat des fonctions du projet. Par exemple, load_design() et les helpers Twig ne prennent pas nécessairement les mêmes arguments qu’une fonction WordPress portant un nom voisin.
Créer de petits éléments partagés
Un bouton possède plusieurs règles : destination interne ou externe, libellé présent, échappement de l’URL et comportement lorsque des valeurs manquent. Plutôt que de réécrire ce traitement dans chaque section, créez un fragment comme parts/ui/button.twig.
Gardez cependant une responsabilité précise par fragment. Un composant qui décide à la fois du menu, des requêtes et de tous les styles devient difficile à relire. La réutilisation doit réduire les endroits à modifier.
Versionner le design proprement
Avant une modification, examinez l’état du dépôt. Une différence locale dans vendor/ n’appartient pas au design : elle peut disparaître lors d’une installation des dépendances et mérite d’être traitée dans le dépôt du package concerné.
git status --short
git diff -- parts/hero.twig assets/styles.json
Versionnez les fichiers sources du design et la documentation utile. Les mots de passe, clés privées, exports de contacts et sauvegardes de production n’ont pas leur place dans une archive publique d’exemples.
Pour une équipe, gardez des commits qui correspondent à une évolution identifiable : une variante de hero, une correction mobile ou une ressource éditoriale. Une revue devient plus facile lorsque le changement est limité et vérifiable.
Préparer une livraison qui se relit
Une archive de design doit indiquer son dossier racine, les fichiers modifiés, ses prérequis et les contrôles effectués. Précisez également ce qu’elle ne contient pas, notamment le cœur Phoenix ou les contenus de la base lorsque ceux-ci sont livrés séparément.
Testez l’extraction dans un dossier temporaire. Une double arborescence mon-design/mon-design/ ou des chemins absolus dans le ZIP compliquent une installation qui devrait rester simple.
Éprouver l’organisation avec une vraie modification
Demandez à un développeur qui découvre le projet de changer le libellé du bouton global, puis la couleur d’une carte. Il devrait trouver une source de contenu et une source de style différentes, sans chercher dans l’ensemble du thème.
Poursuivez avec le chargement du CSS et du JavaScript, puis le choix entre Twig et PHP.
