Relier les ressources manquantes au modèle qui affiche la page
Une page WordPress s’affiche, mais plusieurs éléments ne fonctionnent plus : le menu ne s’ouvre pas, un composant reste vide et des styles ont disparu. Si ces ressources manquent seulement sur une famille de pages, le modèle qui produit ces pages mérite d’être contrôlé. Il peut avoir omis un point où WordPress et les extensions ajoutent leur code au document.
Dans un thème classique, des fonctions du cœur déclenchent des actions, aussi appelées hooks. Le thème appelle wp_head() dans la partie head du document, puis wp_footer() avant la fin de body. Les composants qui se branchent sur ces actions peuvent y imprimer des ressources ou d’autres informations. Si une action manque, plusieurs fonctions sans rapport apparent peuvent tomber ensemble.
Ce guide vise la page publique d’un WordPress autohébergé utilisant des modèles PHP, avec accès aux fichiers par le développeur ou l’exploitant. Un administrateur qui n’a que l’éditeur de contenu peut réunir les preuves sans toucher au code. La réparation doit faire réapparaître les ressources prévues sur le modèle fautif et préserver le fonctionnement des pages qui étaient déjà saines.
Vérifier si le navigateur reçoit une instruction de chargement
Avant d’ouvrir le thème, choisissez une page en panne et une page comparable qui fonctionne. Le meilleur témoin utilise le même composant et des conditions similaires : même état de connexion et mêmes réglages du composant. Une extension qui ne charge son script que sur une page donnée peut expliquer une différence normale.
L’onglet Réseau montre ce que le navigateur tente de charger. Le code source reçu montre ce que le serveur a livré, tandis que l’inspecteur des éléments peut déjà inclure des modifications faites par JavaScript. Examinez les deux selon la question. Un fichier explicitement demandé puis refusé en 403 ou introuvable en 404 relève d’abord de sa requête. Une ressource attendue absente du document et des requêtes invite à remonter à sa génération.
- Sur les deux pages, ouvrez les outils du navigateur, onglet Réseau, puis rechargez.
- Recherchez le nom d’un script ou style associé au composant et relevez son état.
- Comparez le code source de la réponse autour de la fin de head et de body.
- Gardez une URL témoin et une ressource dont le chargement est normalement attendu. Ne concluez pas à partir d’un seul nom manquant.
Identifier le fichier réellement utilisé pour cette URL
Dans Apparence puis Thèmes, relevez le thème actif et, s’il s’agit d’un thème enfant, son parent. Identifiez ensuite le type de page qui échoue. L’accueil, une page avec modèle choisi, une archive et une page introuvable peuvent passer par des fichiers différents. L’éditeur d’une page peut indiquer le modèle assigné, mais il ne montre pas nécessairement tous les fichiers PHP inclus au rendu.
Dans les sources de la livraison, suivez le modèle correspondant à l’URL et les appels qui chargent ses parties communes. Un appel get_header avec un nom peut chercher une variante telle que header-landing.php, tandis qu’un appel sans nom vise header.php. Le même principe s’applique à get_footer. Vérifiez la variante et son éventuel repli, puis l’existence d’une surcharge enfant.
Un fichier qui contient le bon appel ne suffit pas si la page passe par un autre chemin. Cherchez aussi un retour anticipé ou une condition qui empêche d’atteindre le pied de page. Si seule une page d’atterrissage est touchée, commencez par sa variante. Si plusieurs types de pages partagent la panne, cherchez la partie commune réellement utilisée.
Préparer une correction sur une copie représentative
Travaillez dans les sources du thème contrôlé par l’équipe ou dans une copie privée qui reproduit la panne. Relevez la version de WordPress, les versions du thème parent et du thème enfant, et le nom du modèle. Une copie qui sert un autre modèle ou n’a plus les mêmes extensions n’est pas un bon témoin. Choisissez une action sans effet externe pour les contrôles du navigateur, comme l’ouverture d’un menu.
Avant d’éditer, gardez le fichier initial et identifiez le mécanisme de déploiement ou de remise en place. Si le thème vient d’un éditeur, demandez si la version actuelle corrige déjà l’omission. Une modification directe d’un thème parent tiers risque d’être écrasée par une mise à jour et de compliquer le suivi du support.
- Associez chaque page témoin au fichier qui ouvre ou ferme son document.
- Vérifiez que l’appel manque réellement dans ce trajet et qu’il n’existe pas ailleurs dans le même document.
- Sauvegardez les fichiers et préparez une correction limitée à ces points.
- Choisissez le retour prévu : remettre le fichier précédent ou revenir à la livraison précédente.
Rétablir wp_head() à la fin de l’en-tête HTML
Dans un modèle classique qui écrit son en-tête, repérez la fermeture </head> dans le fichier actif. Il peut s’agir de header.php, d’une variante ou du modèle autonome lui-même. Ajoutez uniquement l’appel manquant juste avant cette balise. Le reste du document, y compris les balises meta et les styles du thème, doit rester à sa place.
L’extrait montre la position attendue quand le fichier est à cet endroit en mode HTML. La balise de fermeture est normalement déjà présente : n’en ajoutez pas une seconde. Si le fichier est déjà à l’intérieur d’un bloc PHP à cet endroit, insérez seulement l’instruction wp_head(); avant le retour au HTML. Ne mettez pas l’appel dans functions.php, un bloc de contenu ou une fonction qui s’exécute trop tôt.
Contrôlez ensuite la réponse de la page sur la copie. Les balises attendues de l’en-tête doivent pouvoir y être produites une seule fois ; choisissez une ressource dont vous connaissez la condition de chargement. Si le modèle appelle déjà wp_head() dans une partie qu’il inclut, ne le rappelez pas ici : cherchez plutôt pourquoi la ressource n’est pas déclarée ou a été retirée.
<?php wp_head(); ?>
</head>Rétablir wp_footer() à la fin du corps du document
Repérez le fichier qui ferme le corps HTML. Le pied de page visible n’est pas forcément ce fichier : un composant peut afficher le bandeau final sans fermer body, et un modèle peut fermer body sans afficher de bandeau. Placez le point d’insertion avant la fermeture réelle du corps, après le contenu et les parties déjà affichés. Ce parcours rétablit notamment la possibilité d’imprimer des scripts destinés au pied de page.
Dans la copie, ajoutez uniquement l’appel absent. Comme pour l’en-tête, ne dupliquez pas la balise de fermeture ni les marqueurs PHP si l’instruction s’insère déjà dans du PHP. Si la page n’atteint jamais ce point à cause d’une branche conditionnelle, corrigez d’abord son parcours. Déplacer l’appel au milieu du contenu peut masquer le défaut et faire exécuter le même crochet à deux endroits.
L’appel wp_body_open() correspond à un troisième point, juste après l’ouverture de body. Contrôlez-le si une intégration le requiert ; il ne remplace ni wp_head() ni wp_footer(). Gardez les rôles et les emplacements distincts lorsque vous comparez la structure avec une page qui fonctionne.
<?php wp_footer(); ?>
</body>Raccorder un modèle autonome aux parties communes
Une page peut utiliser un fichier PHP qui réécrit toute l’enveloppe HTML alors que le reste du thème s’appuie sur des parties communes correctes. Comparez les sources avant d’ajouter les fonctions une par une. Si ce modèle devait simplement changer la zone centrale, le raccordement à l’en-tête et au pied de page existants peut être plus durable.
Dans le dossier du thème, généralement sous wp-content/themes, ouvrez le fichier PHP du modèle assigné. Vérifiez que les parties à réutiliser contiennent déjà les appels nécessaires et qu’elles acceptent la structure de votre page. Dans le code PHP du modèle, appelez get_header() avant le contenu et get_footer() après lui, en conservant la boucle et les éléments spécifiques au modèle. Si le thème utilise une variante, gardez son nom et ses paramètres prévus. Enlevez uniquement l’enveloppe redondante que ces parties produisent désormais.
- Repérez quelles balises et zones sont produites par les parties communes.
- Raccordez le modèle sur la copie, sans conserver un deuxième document à l’intérieur du premier.
- Contrôlez les ressources et le rendu du menu, du contenu et du pied de page.
- Si le modèle devait rester minimal, revenez au fichier sauvegardé et restaurez seulement les points d’insertion nécessaires.
Choisir une réparation durable pour un thème tiers
Si une version corrigée est disponible auprès de l’éditeur, comparez son fichier au modèle que vous utilisez et essayez cette version sur la copie. Vérifiez qu’une surcharge enfant ne continue pas à remplacer le fichier corrigé. Une mise à jour du parent ne répare pas automatiquement un ancien fichier encore présent dans l’enfant.
Quand aucune version corrigée n’est disponible, une surcharge ciblée dans un thème enfant peut convenir si le fichier passe par le mécanisme de recherche des modèles. Pour un thème enfant existant, sauvegardez sa variante et reportez uniquement les changements nécessaires. Si le fichier est inclus par un chemin imposé vers le parent, copier un fichier du même nom dans l’enfant peut n’avoir aucun effet : faites adapter ce chargement ou demander un correctif à l’éditeur.
Créer et activer un nouveau thème enfant peut modifier d’autres aspects du site selon la configuration. Vérifiez les menus et les personnalisations sur la copie avant de retenir cette approche. Si elle demande davantage de changements que le correctif, privilégiez une version maintenue du thème ou un retour à une livraison déjà validée. Gardez le fichier précédent disponible tant que les contrôles ne convergent pas.
Distinguer un crochet absent d’une ressource qui n’y est pas inscrite
Si les appels sont présents et atteints, la cause peut se trouver ailleurs. Sur le site public, wp_enqueue_scripts est l’action prévue pour déclarer les styles et scripts. Un composant peut limiter son chargement à un type de page, faire retirer un fichier par du code personnalisé ou dépendre d’une optimisation qui transforme la sortie. Vérifiez les conditions du composant concerné avant de modifier le thème de nouveau.
Un thème de blocs ordinaire suit un autre chemin. Ses fichiers de modèles HTML et les parties visibles dans l’Éditeur de site ne sont pas l’enveloppe PHP entière. WordPress produit normalement cette enveloppe et y appelle les fonctions. Ne collez pas de PHP dans un modèle de blocs ni dans un bloc HTML personnalisé. Si une extension remplace l’enveloppe, faites identifier le code qui produit réellement la page avant toute correction.
Un essai comparatif peut aider lorsque les fichiers ne suffisent pas à trancher : sur la copie privée, reproduisez la même fonction avec un thème compatible déjà disponible et des conditions comparables. Rétablissez ensuite le thème initial. Un résultat différent resserre la recherche sur le rendu du thème ou ses conditions, sans prouver à lui seul qu’un point d’insertion manque.
Contrôler la syntaxe et appliquer le correctif ciblé
Sur une copie, relisez les différences avant d’essayer la page. Le correctif devrait toucher seulement le fichier qui n’exécutait pas le crochet, ou les quelques fichiers nécessaires au raccordement. Vérifiez que vous n’avez ni déplacé du contenu, ni laissé une balise ouverte, ni ajouté un second appel dans une partie commune. Ne modifiez pas le cœur WordPress.
Si vous disposez déjà du terminal de développement, contrôlez chaque fichier PHP modifié avec le PHP compatible avec l’hébergement. Remplacez le chemin fictif dans la commande par celui de votre copie. L’option -l vérifie la syntaxe sans exécuter le modèle ; elle n’indique pas que ce fichier est sélectionné ni que le menu fonctionne. Si PHP signale une erreur, corrigez le fichier avant de le déployer.
Lorsque la copie valide la correction, utilisez le processus de livraison du site et conservez la version précédente. Faites une mise à jour de cache ciblée seulement si la réponse publique sert encore une copie de l’ancienne page. Une purge générale ne fait pas entrer en service un fichier qui a été déployé dans le mauvais thème.
php -l "/chemin/de/la-copie/wp-content/themes/mon-theme/header.php"Vérifier que le navigateur et les visiteurs retrouvent le comportement attendu
Reprenez l’URL et la ressource notées au départ, dans les mêmes conditions de connexion. Le résultat attendu comporte deux éléments : la ressource requise arrive ou le code attendu est présent dans la réponse, et le comportement observé revient. Un script peut réapparaître tout en étant bloqué ensuite ; un bouton peut sembler rétabli grâce à une version encore chargée en mémoire. Vérifiez les deux aspects.
Si la correction imprime deux fois le même composant, inspectez les appels hérités et le fichier de page. Deux ressources portant un nom similaire ne suffisent pas à prouver un doublon ; comparez leur URL et leur rôle. Si le correctif déclenche une erreur PHP ou casse le rendu d’autres pages, revenez au fichier ou à la livraison sauvegardée avant de reprendre le diagnostic.
- Vérifiez la page en panne et la page témoin, puis au moins une autre page qui utilise la même partie commune.
- Comparez le code source et les requêtes pour la ressource choisie.
- Rejouez l’interaction prévue sans déclencher d’envoi réel.
- Contrôlez les nouvelles erreurs et le rendu des pages voisines.
- En cas de retour, refaites les mêmes lectures pour confirmer que la version précédente est effectivement servie.
Éviter qu’un nouveau modèle oublie les mêmes points
Lorsqu’un développeur crée une page très différente du reste du site, encouragez la réutilisation des parties communes si elles répondent au besoin. Un modèle minimal peut garder son propre document ; dans ce cas, la revue doit vérifier ses points d’insertion et leur emplacement, ainsi que les éventuelles branches qui court-circuitent leur exécution. Un contrôle limité à la page d’accueil ne verra pas une variante rarement utilisée.
Pour un thème enfant, gardez une note sur chaque surcharge de modèle et la raison qui la justifie. Comparez ces fichiers après une mise à jour du parent. Si la version maintenue intègre la correction, vérifiez qu’il est possible de retirer la surcharge devenue inutile sans perdre d’autres personnalisations. Testez ce retrait sur une copie comme une modification ordinaire.
Si vous n’avez pas accès aux sources, remettez au responsable l’URL, le type de page, le nom du modèle supposé, la ressource attendue et les différences observées. Cela lui permet de vérifier le bon fichier sans rechercher à l’aveugle. Aucun module d’optimisation supplémentaire n’est nécessaire pour restaurer un point d’insertion. Lorsque les ressources sont présentes mais que le comportement reste cassé, poursuivez plutôt avec les erreurs du navigateur et le composant responsable.
