Erreur de syntaxe PHP dans WordPress : restaurer puis corriger

Une erreur de syntaxe PHP empêche l’analyse d’un fichier. Si elle suit une modification, le premier objectif est de retrouver ce qui a changé et de remettre une version saine en place. La correction se prépare ensuite dans la source, avec le bon PHP et un contrôle de chargement. Ajouter des essais directement sur le site en panne complique le retour.

Retrouver le fichier analysé et le message complet

Relevez le message Parse error ou syntax error, le fichier indiqué et la ligne. La documentation de ParseError décrit une erreur liée à l’analyse du code PHP. Une page blanche ou un statut 500 ne suffit pas à confirmer ce diagnostic. En l’absence de message précis, le guide de l’erreur 500 WordPress aide à identifier la couche qui échoue avant de toucher aux fichiers.

Gardez l’heure, l’action concernée et le dernier changement connu. Le fichier signalé peut être inclus par un autre composant, et la ligne correspond à l’endroit où PHP ne comprend plus la suite. Une chaîne ouverte ou une accolade manquante peut se trouver auparavant. Conservez donc le message complet dans un relevé privé, sans publier le chemin d’hébergement ni les éventuelles données qu’il contient.

Consultez les journaux de l’hébergement et, lorsque WordPress démarre suffisamment, ses outils de débogage. Un arrêt précoce peut empêcher l’écriture dans le journal WordPress attendu. Ne concluez pas à l’absence d’erreur parce que ce seul fichier reste vide. La journalisation doit rester protégée et l’affichage des détails aux visiteurs désactivé pendant le diagnostic.

Rétablir le fichier sain avant d’essayer des corrections

Vérifiez une sauvegarde récente et restaurable, puis retrouvez la version du fichier ou du composant avant modification. La sauvegarde WordPress couvre des éléments différents : fichiers et base doivent être distingués. Une faute dans un fichier PHP ne justifie pas, à elle seule, de réimporter une ancienne base qui ferait perdre les contenus ou commandes reçus depuis.

Si WordPress propose son mode de récupération, utilisez le lien personnel avec les précautions habituelles. La pause d’un composant dans cette session ne signifie pas que le site public est réparé. Le guide de l’erreur critique WordPress explique cette distinction. Si ce mode est inaccessible, l’hébergeur ou un intervenant disposant des accès documentés peut remettre les fichiers validés en place.

Limitez le retour au périmètre nécessaire, tout en gardant un composant cohérent. Un déploiement de plusieurs fichiers ou une migration de données ne se ramène pas toujours au remplacement d’un fichier isolé. Faites vérifier la compatibilité de la version restaurée avec les autres fichiers et la base courante. Évitez les copies partielles visibles pendant un transfert ; utilisez le mécanisme de publication prévu pour le projet.

Contrôler la syntaxe avec le bon PHP

Sur la copie de travail, le contrôle php -l vérifie la syntaxe du fichier fourni sans exécuter son programme. Le manuel des options PHP précise aussi ses limites. Vérifiez chacun des fichiers modifiés : analyser le fichier principal ne teste pas automatiquement le contenu de tous les fichiers qu’il inclura au chargement de WordPress.

Utilisez la version de PHP correspondant à celle du parcours en erreur. Le PHP lancé dans un terminal peut différer de celui du serveur web ou d’une tâche planifiée. Une syntaxe acceptée par une version récente peut être refusée par une autre. Comparez les versions et les prérequis du composant, en vous appuyant sur les branches PHP maintenues, sans changer toute la plateforme simplement pour contourner une faute de code.

Un lint réussi ne valide pas les fonctions appelées, les classes disponibles, les droits d’accès ou les interactions entre extensions. Ces problèmes demandent l’exécution du parcours dans un environnement adapté. Gardez donc deux étapes distinctes : contrôle de syntaxe, puis test de chargement et de fonctionnement. Le résultat du premier ne doit pas être présenté comme une preuve que l’ensemble du site fonctionne.

Corriger l’origine dans la source suivie

Comparez le fichier fautif à la version attendue et inspectez quelques lignes avant le point indiqué. Vérifiez les délimiteurs, guillemets, parenthèses, accolades et commentaires ouverts. Corrigez la cause du déséquilibre plutôt que d’ajouter des signes jusqu’à faire taire le message. Une petite modification peut suffire, mais elle doit rester lisible et correspondre à l’intention du code d’origine.

Travaillez dans un éditeur de code et conservez l’encodage du projet. Un traitement de texte peut remplacer des guillemets ou introduire des caractères inadaptés. Pour une extension ou un thème fourni par un éditeur, privilégiez sa version corrigée ou un retour compatible ; une retouche directe peut disparaître à la prochaine mise à jour. Les adaptations propres au site doivent rester dans un emplacement maîtrisé et versionné, adapté à leur rôle.

Ne mélangez pas les familles d’erreurs. Un fichier valide peut ensuite produire une sortie qui empêche l’envoi des en-têtes. Ce cas relève du diagnostic Headers already sent, pas d’une erreur de syntaxe à corriger au hasard. Reprenez le nouveau message et son contexte après chaque changement, sans ajouter plusieurs corrections de nature différente dans le même essai.

Vérifier la provenance si la modification est inexpliquée

Si aucun déploiement connu n’explique le fichier modifié, conservez son état et les traces disponibles avant de l’écraser. Comparez les dates, l’historique de publication et les versions présentes. Une différence inexpliquée appelle un contrôle d’intégrité ; elle ne permet pas, à elle seule, d’affirmer que le site est compromis. Une simple correction de ponctuation ne répondrait pas non plus à une modification non autorisée confirmée.

Pour le cœur WordPress, la commande documentée wp core verify-checksums peut comparer les fichiers aux empreintes attendues. Ce contrôle porte sur le cœur et son périmètre propre. Il ne certifie pas tous les thèmes, extensions, fichiers personnalisés ou éléments de la base. Son résultat doit être lu avec la version et la langue du paquet réellement installées.

Pour un composant tiers, utilisez le paquet officiel correspondant ou le commit de référence du projet. L’absence d’empreintes publiques pour une extension commerciale ne constitue pas une preuve d’altération. Vérifiez sa provenance et les différences utiles avant de décider d’un remplacement. Si une anomalie est confirmée, faites traiter l’incident dans son ensemble, avec les accès et protections nécessaires, plutôt que de supprimer des fichiers inconnus sans analyse.

Tester le chargement et prévenir la prochaine erreur

Une fois le correctif validé en syntaxe, testez le parcours qui échouait et les fonctions directement concernées : page publique, administration, formulaire ou tâche planifiée. Utilisez une copie de test pour les écritures et les opérations sensibles. Ne créez pas de vraie commande ou de compte en production uniquement pour valider le chargement d’un fichier. Contrôlez aussi les permissions des utilisateurs concernés lorsque le code en dépend.

Vérifiez une visite déconnectée, les formats d’écran utiles et le contenu sans JavaScript lorsqu’il doit rester disponible. Consultez les journaux après le test et assurez-vous que la bonne version est servie, sans vous fier uniquement à une page en cache. Retirez la journalisation temporaire devenue inutile tout en gardant les preuves nécessaires. Un autre message d’erreur doit être qualifié, pas masqué pour obtenir un écran apparemment normal.

Conservez enfin le correctif dans le dépôt, son contrôle de syntaxe et les tests effectués. Ajoutez le lint des fichiers modifiés avant publication, avec le retour vers une version connue. Si l’accès reste bloqué ou si le composant est difficile à isoler, une intervention Urgence WordPress peut repartir du message et des traces déjà recueillis. La prévention repose sur cette chaîne vérifiable, pas sur des modifications successives en production.