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

> « Parse error: syntax error, unexpected… » : lisez le message PHP, trouvez le fichier fautif, annulez la modification et contrôlez-le avec php -l.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/erreur-syntaxe-php/

> PHP n’a pas pu lire un fichier à cause d’une faute de syntaxe (point-virgule, accolade ou guillemet manquant). Ouvrez le fichier et la ligne indiqués dans le message, annulez la dernière modification, puis vérifiez avec php -l.

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](https://www.wpmoderne.fr/erreurs-wordpress/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](https://www.wpmoderne.fr/erreurs-wordpress/ecran-blanc/), 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é](https://www.wpmoderne.fr/themes/parse-error-import-ftp-encodage/)).
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](https://www.wpmoderne.fr/tips/wp-debug-log-bons-reflexes-debogage-wordpress/)). 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](https://www.wpmoderne.fr/themes/editeur-code-desactive-reactiver-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](https://www.wpmoderne.fr/securite/sauvegardes-plan-de-reprise-wordpress/).

## 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