Parse error: syntax error, unexpected… : erreur de syntaxe PHP

Parse error: syntax error, unexpected token ";"

En anglais : Parse error: syntax error, unexpected token ";"

Juste après avoir collé un extrait de code dans functions.php, enregistré un fichier de thème ou mis à jour une extension, votre site affiche une ligne du type « Parse error: syntax error, unexpected token "}" in /…/functions.php on line 42 », ou bien la page d’erreur critique, ou encore une page blanche. Selon le fichier fautif, le site public, l’administration ou les deux sont inaccessibles.

Cette erreur est la plus facile à diagnostiquer, car PHP vous donne le fichier et la ligne. Elle signifie que le code est mal écrit : il n’a pas pu être lu, donc rien de ce fichier ne s’est exécuté.

Ce que signifie cette erreur

Avant d’exécuter un fichier PHP, le moteur le découpe en éléments (les « tokens ») et vérifie la grammaire du langage. Si le découpage échoue, il s’arrête avec une erreur de type E_PARSE. Le texte « unexpected token » signale que PHP a rencontré un élément à un endroit où il n’en attendait pas ; la fin du message précise parfois ce qu’il attendait (expecting ";", par exemple). Il ne s’agit pas d’un message WordPress, et il n’est donc pas traduit.

WordPress sait intercepter cette erreur : E_PARSE figure dans la liste des erreurs gérées par wp-includes/class-wp-fatal-error-handler.php, qui affiche alors la page d’erreur critique et, si le fautif est une extension ou un thème, le met en pause. Ce gestionnaire n’est cependant actif qu’une fois WordPress chargé : une faute dans wp-config.php ou dans un fichier chargé avant lui n’est pas interceptée et produit une page blanche, ou le message brut si l’affichage des erreurs est activé.

Le message varie selon la version de PHP. Depuis PHP 8, il est de la forme unexpected token "}", unexpected variable "$b" ou unexpected end of file. Les versions 7 affichaient unexpected '$b' (T_VARIABLE). PHP 8 a aussi ajouté des messages plus parlants comme Unclosed '{' on line 2 ou Unmatched '}'.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
unexpected variable "$b" sur une ligne qui commence par une variable	Point-virgule oublié à la ligne précédente	La ou les lignes juste avant celle indiquée
unexpected end of file ou Unclosed '{'	Accolade, parenthèse ou guillemet non fermé	La fin du fichier ; compter les { et }
Unmatched '}'	Accolade fermante en trop	Le bloc situé juste avant la ligne
Erreur à la ligne 1 d’un fichier qui semble correct	Marque BOM ou encodage altéré par un transfert FTP	Début du fichier en hexadécimal ; mode de transfert FTP
Erreur après avoir copié un extrait depuis une page web	Guillemets typographiques ou espaces insécables collés	Remplacer par des guillemets droits ' et "
Erreur après un changement de version de PHP	Syntaxe trop récente pour votre version, ou obsolète	Version de PHP (Santé du site), documentation de l’extension

Les causes les plus fréquentes

1. Un extrait de code collé dans functions.php ou un snippet, incomplet ou mal copié (accolade finale oubliée, guillemets typographiques).
2. Un point-virgule, une virgule ou une parenthèse manquants après une modification à la main.
3. Un fichier tronqué ou altéré par un téléversement interrompu, un transfert FTP en mode texte ou une marque BOM (voir l’article Parse error après un import FTP mal encodé).
4. Une syntaxe incompatible avec la version de PHP : fonction fléchée (fn), match, opérateur ?-> ou types union sur un PHP ancien.
5. Une mise à jour d’extension interrompue, qui laisse un fichier à moitié écrit.
6. Des balises PHP mal fermées (?> suivi de code, ou balise courte <? désactivée) dans un gabarit de thème.

Solutions pas à pas

Avant toute manipulation, copiez le fichier concerné (ou sauvegardez wp-content/). Du moins invasif au plus technique :

1. Lire le message jusqu’au bout

Notez trois informations : le chemin du fichier, le numéro de ligne et le début du message. Si vous ne voyez rien à l’écran parce que l’affichage des erreurs est désactivé, récupérez-les dans l’e-mail du mode de récupération (« Votre site connaît un problème technique ») ou dans le journal :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

tail -n 20 wp-content/debug.log

Ces trois lignes se placent dans wp-config.php, au-dessus de « That’s all, stop editing! » (détails dans notre article sur WP_DEBUG_LOG). Retirez-les ensuite. Gardez en tête que PHP signale la ligne où il a compris qu’il y avait un problème : la vraie faute se trouve souvent une ou deux lignes plus haut.

2. Utiliser le mode de récupération

Si la faute est dans une extension ou un thème et que vous avez reçu l’e-mail du mode de récupération, ouvrez son lien, connectez-vous, puis désactivez l’extension ou le thème, ou corrigez-le. La marche à suivre complète figure dans la fiche sur l’erreur critique de WordPress.

3. Annuler la dernière modification

Le plus rapide est de revenir à l’état précédent. Connectez-vous en SFTP (ou via le gestionnaire de fichiers de l’hébergeur), ouvrez le fichier cité et supprimez ou commentez le code que vous venez d’ajouter. Si vous avez perdu l’accès SFTP et que l’éditeur de fichiers est désactivé, consultez l’article éditeur de code désactivé : réactiver en urgence. Pour une extension, remplacez simplement son dossier par une copie saine :

wp plugin install nom-de-l-extension --force
wp theme install nom-du-theme --force

Cette commande réinstalle la version publiée sur wordpress.org ; elle n’est utile que pour les extensions et thèmes de ce dépôt. Les réglages, stockés en base, sont conservés, mais toute modification que vous aviez faite dans les fichiers est perdue.

4. Vérifier la syntaxe avec php -l

Une fois le fichier corrigé, testez-le avant de recharger le site. L’option -l (lint) lit le fichier sans l’exécuter :

php -l wp-content/themes/mon-theme/functions.php

La réponse « No syntax errors detected in … » confirme que la syntaxe est valide ; sinon PHP affiche la même erreur qu’à l’écran. Pour parcourir un dossier entier (utile après un transfert massif) :

find wp-content -name '*.php' -print0 | xargs -0 -n1 php -l 2>&1 | grep -v 'No syntax errors'

Attention : si plusieurs versions de PHP sont installées, le php de la ligne de commande n’est pas forcément celui du site. Utilisez le binaire correspondant (par exemple php8.2).

5. Corriger les caractères invisibles et l’encodage

Si le fichier paraît correct, regardez ses premiers octets : une marque BOM (ef bb bf) ou des guillemets typographiques collés en sont les coupables habituels.

head -c 16 wp-content/themes/mon-theme/functions.php | xxd
file wp-content/themes/mon-theme/functions.php

Réenregistrez le fichier en « UTF-8 sans BOM » dans votre éditeur, et remplacez les guillemets courbes « “ ” ‘ ’ » du code par des guillemets droits. Lors d’un transfert FTP, utilisez le mode binaire (ou SFTP).

6. Adapter la version de PHP

Si l’erreur est apparue après un changement de version de PHP, ou si une extension récente exige PHP 8, vérifiez la version utilisée dans Outils > Santé du site > Info > Serveur. Dans le panneau de l’hébergeur, changez la version de PHP du site (revenez en arrière en urgence, puis planifiez la montée de version sur un double du site). Quand la faute vient de fichiers du cœur, restaurez-les :

wp core verify-checksums
wp core download --force --skip-content

Ces deux commandes comparent puis remplacent les fichiers du cœur sans toucher à wp-content/, à wp-config.php ni à la base.

Sans accès à l’administration

Tout se fait par SFTP, par le gestionnaire de fichiers de l’hébergeur ou en SSH avec WP-CLI. Si l’erreur est dans wp-config.php, comparez-le avec votre sauvegarde ou avec wp-config-sample.php et testez-le avec php -l wp-config.php avant de rouvrir le site. Une sauvegarde récente vous évite tout cela : voir sauvegardes et plan de reprise.

Prévenir l’erreur

• Ne modifiez pas le code en production : travaillez en local ou sur un double du site, et déployez par Git ou SFTP.
• Utilisez un éditeur avec coloration et contrôle syntaxique (ou lancez php -l automatiquement avant chaque envoi).
• Préférez une extension de snippets à l’édition directe de functions.php : elle teste le code avant de l’activer.
• Testez les mises à jour de PHP sur un double, extension par extension, avant la bascule.
• Gardez une sauvegarde récente des fichiers, restaurable en quelques minutes.

Questions fréquentes