Un bloc vide, une page sans style ou un formulaire qui ne confirme rien peuvent avoir des causes très différentes. Modifier plusieurs fichiers au hasard rend le diagnostic plus difficile et peut masquer le problème initial.
Avec Phoenix, commencez par séparer trois pistes : les données, le chargement du design et le comportement du composant.
Décrire le symptôme de façon reproductible
Notez la page concernée, le type de contenu, la session utilisée et l’action qui déclenche le problème. Précisez si le défaut touche toutes les pages ou une seule variante.
Une description comme « le bouton du deuxième CTA n’apparaît pas lorsque sa destination externe est renseignée » permet de rechercher une condition précise. « Le site ne marche pas » ne donne pas le même point de départ.
Conservez un état de référence avant les essais : fichiers modifiés, capture utile et message d’erreur. N’incluez pas de secrets dans les traces partagées.
Vérifier la source des contenus
Pour un titre absent, contrôlez le bloc et le nom du champ. Le modèle attend-il title, une donnée d’article ou un réglage global ? Le schéma installé correspond-il à celui de l’exemple repris ?
Pour une image, vérifiez l’existence du média et le résultat du helper. Un identifiant présent dans un champ ne garantit pas qu’une URL puisse encore être obtenue.
Pour un lien interne, examinez l’identifiant de page et la fonction de résolution. Une destination copiée depuis un environnement précédent peut ne plus exister.
Confirmer le design et le fichier réellement chargés
Repérez le design actif, son dossier et le mécanisme de sélection. Vérifiez le rôle de design.json ou du réglage effectivement utilisé par le bootstrap de votre version.
Ajoutez temporairement un repère non sensible dans une copie de développement si vous devez confirmer un chemin de rendu. Retirez-le après le contrôle.
Un article classique peut utiliser single-post.twig, tandis qu’un événement utilise single-evenement.twig. Un modèle générique mal choisi peut expliquer une présentation sans rapport avec le type de contenu.
Examiner les ressources dans le navigateur
Si la page paraît sans style, ouvrez l’onglet Réseau et retrouvez les fichiers déclarés dans assets/styles.json. Vérifiez leur URL, leur contenu et le code de réponse.
Une erreur de casse, un fichier absent ou une réponse HTML renvoyée à la place du CSS ne se résolvent pas en ajoutant davantage de règles CSS. Contrôlez d’abord le chemin et le chargeur.
Pour le JavaScript, lisez la première erreur de console et son fichier. Une initialisation qui suppose un élément absent peut interrompre les interactions suivantes.
Isoler une modification récente
Utilisez Git pour comparer les fichiers concernés. Un diff limité donne souvent plus d’informations qu’une relecture de tout le thème.
git status --short
git diff -- parts/hero.twig assets/styles.json
Si les différences se trouvent dans vendor/, identifiez leur origine avant une mise à jour des dépendances. Une modification locale du package peut disparaître lors d’un déploiement.
Annulez une hypothèse seulement après avoir conservé le travail nécessaire. Une restauration globale n’est pas un outil de diagnostic proportionné à un défaut local.
Tester les traitements et l’environnement séparément
Pour un formulaire, distinguez l’affichage, la validation, l’enregistrement et l’envoi du courriel. Une étape réussie ne prouve pas automatiquement les suivantes.
Pour un téléchargement, vérifiez le dossier privé, les droits de lecture et le nom exact du ZIP. Pour un événement, contrôlez le format brut de la date et le fuseau WordPress avant de modifier le texte affiché.
Après une correction, rejouez le scénario initial et un cas voisin. Videz le cache approprié pour vérifier le rendu d’un visiteur déconnecté.
Le guide de livraison aide à documenter la correction. Un diagnostic utile explique la cause, le changement effectué et la limite des vérifications réalisées.
