# Rector pour WordPress : moderniser automatiquement votre code PHP en sécurité

> Configurer Rector, appliquer des ensembles de règles PHP 7.4 à 8.1 sur une extension existante, et relire chaque changement généré avant de le fusionner.

- Auteur : Clément Hadrot
- Publié le : 2022-06-06
- Mis à jour le : 2022-06-06
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/rector-wordpress-moderniser-code-php/

## L’essentiel

- Rector réécrit le code, il ne se contente pas de l'analyser
- Toujours passer par un dry-run avant application
- Coupler Rector à la suite de tests avant de committer

Une agence héritait d'une extension de dix ans d'âge, écrite en PHP 5.6, à moderniser avant une migration serveur vers PHP 8.1. Réécrire à la main chaque tableau construit avec `array()`, chaque comparaison de type implicite et chaque fonction dépréciée aurait pris des semaines. Rector a permis d'automatiser l'essentiel de cette modernisation mécanique, tout en laissant les développeurs relire chaque changement avant de le fusionner — la vitesse de l'automatisation sans en perdre le contrôle.

Rector fonctionne différemment d'un linter : là où PHPCS ou PHPStan se contentent de signaler des problèmes, Rector réécrit directement le code source pour appliquer des règles de transformation, qu'il s'agisse de moderniser une syntaxe ou de migrer vers une nouvelle version de PHP.

## Installer et configurer un premier ensemble de règles

```
composer require --dev rector/rector

// rector.php
use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\LevelSetList;

return static function ( RectorConfig $rectorConfig ): void {
    $rectorConfig->paths( [ __DIR__ . '/src' ] );
    $rectorConfig->sets( [
        LevelSetList::UP_TO_PHP_81,
    ] );
};
```

`UP_TO_PHP_81` applique en cascade toutes les règles de modernisation depuis la version PHP minimale détectée jusqu'à 8.1, dans l'ordre correct, sans qu'il soit nécessaire de lister chaque règle individuellement.

## Toujours commencer par un dry-run

```
vendor/bin/rector process --dry-run
```

> L'essentiel à retenir : Rector réécrit le code, il ne se contente pas de l'analyser ; Toujours passer par un dry-run avant application ; Coupler Rector à la suite de tests avant de committer

Le mode `--dry-run` affiche un diff complet de chaque modification prévue, fichier par fichier, sans rien écrire sur le disque. Sur une base de code inconnue, c'est l'étape à ne surtout pas sauter : elle permet de repérer les transformations risquées avant qu'elles ne touchent réellement le code.

## Un exemple de transformation générée

```
// Avant (Rector détecte le array() ancien style)
$options = array(
    'taille' => 'M',
    'couleur' => 'bleu',
);

// Après (généré automatiquement par Rector)
$options = [
    'taille' => 'M',
    'couleur' => 'bleu',
];
```

Sur des transformations plus profondes, comme le remplacement de `list()` par une déstructuration de tableau moderne, ou l'ajout de types de retour explicites déduits du code existant, la relecture manuelle du diff devient indispensable : Rector peut se tromper sur un type ambigu, en particulier dans du code sans déclarations de type préalables.

## Coupler Rector à la suite de tests

La discipline la plus importante consiste à ne jamais appliquer Rector sur du code sans filet de sécurité :

- Lancer la suite de tests existante avant d'appliquer Rector, pour établir une base de référence
- Appliquer Rector avec `vendor/bin/rector process` (sans `--dry-run`) sur une branche dédiée
- Relancer immédiatement la suite de tests sur le code transformé
- Ne fusionner que si les deux exécutions donnent des résultats identiques

> Sur un projet sans aucun test existant, la règle appliquée en agence est de commencer par écrire une couche minimale de tests de caractérisation autour du code à moderniser, avant même de lancer Rector. Automatiser une réécriture sur du code non testé revient à piloter à l'aveugle.

## Cibler des règles WordPress spécifiques

Au-delà des ensembles génériques par version de PHP, la communauté maintient également `rector/rector-wordpress`, avec des règles conscientes des conventions du cœur, par exemple la conversion de certains appels dépréciés du cœur WordPress vers leurs équivalents actuels :

```
composer require --dev rector/rector-wordpress

use RectorWordPress\Set\WordPressSetList;

return static function ( RectorConfig $rectorConfig ): void {
    $rectorConfig->sets( [
        WordPressSetList::WORDPRESS_60,
    ] );
};
```

Combiner un ensemble PHP générique et un ensemble spécifique à WordPress dans la même configuration permet de traiter en une seule passe la modernisation du langage et celle des API du cœur, plutôt que de lancer deux campagnes de refactorisation séparées.

## Traiter les cas où Rector refuse de transformer

Sur certaines constructions trop ambiguës, en particulier du code sans déclaration de type dans une fonction appelée depuis plusieurs endroits avec des types différents, Rector laisse volontairement le code inchangé plutôt que de risquer une transformation incorrecte. Ces zones restent à traiter manuellement, ce qui est un signal utile en soi : un code que même un outil automatisé n'ose pas modifier mérite souvent une relecture humaine approfondie avant la migration de version PHP.

## En résumé

Rector accélère considérablement la modernisation mécanique d'une base PHP ancienne, mais reste un outil qui réécrit du code réel : dry-run systématique, relecture des diffs, et suite de tests avant/après restent non négociables. L'analyse statique avec PHPStan répond à un besoin complémentaire — détecter des erreurs sans jamais toucher au code — qui mérite sa propre configuration.