Enzo ILO - PHP / Symfony / WordPress
Migrer un WordPress vers PHP 8.x : compatibilité, tests, outils

Migrer un WordPress vers PHP 8.x : compatibilité, tests, outils

Publié le

Pourquoi migrer vers PHP 8.x ?

  • Sécurité & support : les versions obsolètes ne reçoivent plus de correctifs. Rester à jour est indispensable.
  • Performance : moteur plus rapide, optimisations d’OPcache, améliorations continues (8.0 → 8.3).
  • Compatibilité écosystème : la plupart des extensions premium & thèmes modernes ciblent 8.1+.
  • Qualité code : nouvelles fonctionnalités (types, attributes, enums 8.1, etc.) qui améliorent la robustesse.

Pré-requis & check de départ

  • Backups complets (fichiers + base de données) et restauration testée.
  • Accès : WP-CLI, FTP/SSH, gestion de version PHP côté hébergeur (ou Docker si VPS).
  • Environnement de staging (copie du site) pour simuler la migration avant la prod.
  • Inventaire : liste des plugins, thème parent/enfant, must-use (mu-plugins), snippets functions.php.
  • Version WordPress : mettre à jour le core et s’assurer que le site fonctionne déjà parfaitement en l’état.

Carte des risques spécifiques WordPress

  • Fonctions dépréciées dans WordPress, PHP, WooCommerce ou Divi (warnings, notices, deprecated).
  • Extensions abandonnées ou non testées sur PHP 8.x.
  • Snippets “rapides” (ex: filtres/shortcodes) qui supposent des types laxistes (null/array/string).
  • Compatibilité WooCommerce : templates surchargés, passerelles de paiement, hooks/filters.
  • Builder Divi : modules custom, hooks, shortcodes personnalisés.

Outils indispensables pour la migration

1) WP-CLI (audit, mises à jour, santé)

wp --info
wp core verify-checksums
wp plugin list --update=available
wp theme list
wp site health info

2) PHPCompatibility avec PHP_CodeSniffer

Analyse statique pour repérer les incompatibilités 8.x dans votre code (thème enfant, plugin custom…). 

# Installation locale (ex. via Composer)
composer require --dev dealerdirect/phpcodesniffer-composer-installer phpcompatibility/php-compatibility

# Exemple de ruleset phpcs.xml (simplifié ; < et > sont échappés) :
<?xml version="1.0"?>
<ruleset name="WP PHP 8.x">
  <rule ref="PHPCompatibility"/>
  <config name="testVersion" value="8.0-8.3"/>
  <file>wp-content/themes/votre-theme-enfant</file>
  <file>wp-content/mu-plugins</file>
  <file>wp-content/plugins/votre-plugin-custom</file>
</ruleset>

# Lancer l’analyse
vendor/bin/phpcs

3) Static analysis (PHPStan ou Psalm)

Monter progressivement le niveau (ex. PHPStan niveau 3 → 6) pour détecter types incohérents, nullables, retours manquants. 

composer require --dev phpstan/phpstan

# phpstan.neon (extrait)
parameters:
  level: 6
  paths:
    - wp-content/themes/votre-theme-enfant
    - wp-content/plugins/votre-plugin-custom
  ignoreErrors:
    - '#dynamic_property#'

4) Rector (optionnel, accélère les refactors)

Automatise certains ajustements (types, signatures). Toujours relire les diffs. 

composer require --dev rector/rector

# rector.php (extrait minimal)
<?php
return static function (Rector\Config\RectorConfig $rectorConfig): void {
  $rectorConfig->paths([
    __DIR__ . '/wp-content/themes/votre-theme-enfant',
    __DIR__ . '/wp-content/plugins/votre-plugin-custom',
  ]);
  $rectorConfig->sets([
    Rector\Set\ValueObject\SetList::PHP_80,
    Rector\Set\ValueObject\SetList::PHP_81,
    Rector\Set\ValueObject\SetList::PHP_82,
  ]);
};

5) Logs de dépréciations & Query Monitor

Activez WP_DEBUG_LOG en staging pour capter warnings/notice/deprecated, et installez Query Monitor pour les repérer rapidement. 

// wp-config.php (staging)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

6) Tests automatisés (quand c’est possible)

  • PHPUnit pour la logique PHP custom (plugins, librairies).
  • Playwright/Panther pour des parcours e2e (panier, paiement test, contact, recherche).

Environnement de staging (exemple Docker)

Si vous avez un VPS/localhost, isolez un environnement PHP 8.3 pour tester sans toucher la prod. 

# docker-compose.yml (exemple)
services:
  php:
    image: php:8.3-fpm
    volumes:
      - ./:/var/www/html
    environment:
      - PHP_MEMORY_LIMIT=512M
  web:
    image: nginx:alpine
    volumes:
      - ./:/var/www/html
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "8080:80"
  db:
    image: mariadb:10.6
    environment:
      - MARIADB_ROOT_PASSWORD=secret
      - MARIADB_DATABASE=wp

Plan de migration pas à pas

Étape 1 — Mettre à jour sans casser

  1. Core WordPress à jour + traductions.
  2. Extensions & thèmes : mettez tout à niveau, supprimez le superflu.
  3. Vérifier le changelog des extensions sensibles (WooCommerce, SEO, cache, paiements, builder).

Étape 2 — Cloner en staging & activer PHP 8.x

  1. Copie fichiers + DB, reconfig wp-config.php (URL, DB).
  2. Basculer la version PHP du serveur de staging en 8.x (8.1/8.2/8.3 selon cible).
  3. Vider caches (plugin + OPCache) et wp transient delete --all.

Étape 3 — Scanner et corriger

  1. Lancer PHPCompatibility + PHPStan/Psalm.
  2. Corriger signatures, opérateurs, gestion null, cast explicites.
  3. Remplacer fonctions obsolètes, vérifier les librairies embarquées.

Étape 4 — Tests fonctionnels

  • Parcours critiques : panier → paiement (mode sandbox), formulaire de contact, recherche, inscription, upload.
  • Back-office : création d’article, média, mise à jour d’un produit, import/export CSV.
  • Divi : édition d’une page, modules dynamiques, global presets.
  • WooCommerce : variations, coupons, frais de port, facturation TVA.

Étape 5 — Performance & configuration PHP

Vérifiez OPcache et les limites. 

; php.ini (extraits recommandés)
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
memory_limit=512M
max_execution_time=120

Étape 6 — Go live contrôlé

  1. Fenêtre de maintenance courte, pages caches préparées.
  2. Basculer la prod sur PHP 8.x.
  3. Vérifier logs d’erreur, pages critiques et paiement réel de faible montant.

Points d’attention fréquents (et correctifs types)

Typage plus strict

PHP 8.x remonte plus d’erreurs là où 7.x “tolérait”. Exemples : 

// Avant : on supposait une string
$title = $post_meta['title'] ?? '';
echo trim($title);

// Mieux (défensif)
$title = isset($post_meta['title']) && is_string($post_meta['title']) ? $post_meta['title'] : '';
echo trim($title);

Comparaisons & opérateurs

  • Évitez les comparaisons lâches == quand le type peut varier ; préférez ===.
  • Verrouillez les retours de filtres/hooks : documenter les types attendus.

Callbacks, signatures & valeurs par défaut

// Mauvais : signature incompatible avec un hook qui envoie un objet
add_filter('my_filter', function(array $data) { ... });

// OK : accepter le type réel ou valider avant usage
add_filter('my_filter', function($payload) {
  if (!is_array($payload)) return $payload;
  ...
  return $payload;
});

Gestion des erreurs & Exceptions

Quelques fonctions lèvent maintenant des exceptions à la place de warnings. Entourez les appels sensibles : 

try {
  $image = imagecreatefromstring($blob);
} catch (Throwable $e) {
  error_log('Image error: '.$e->getMessage());
  $image = null;
}

WooCommerce : templates & hooks

  • Mettez à jour les template overrides du thème enfant (répertoire woocommerce/), supprimez les fichiers obsolètes.
  • Testez passerelles de paiement en mode test (Webhook, signature, retours).
  • Vérifiez les filtres de prix/TVA (arrondis, locales) avec PHP 8.x (intl/extension bcmath si utilisée).

Divi : modules custom

  • Vérifiez les modules personnalisés (classes PHP) : types de paramètres, shortcodes, données $_POST/$_GET filtrées.
  • Assurez-vous que tout JS/CSS dynamiques se base sur des APIs stables du builder.

Composer & gestion fine des dépendances

Si votre projet utilise Composer, verrouillez la plateforme pour tester localement le même runtime qu’en prod : 

{
  "config": {
    "platform": { "php": "8.3.0" }
  }
}

Mettez à jour les libs : 

composer update --with-all-dependencies

Qualité continue : intégrer au pipeline

  • CI : exécuter PHPCompatibility, PHPStan et, si possible, tests e2e sur chaque PR.
  • Snapshoot visuel (optionnel) pour détecter les régressions d’affichage (utile avec Divi).
  • Mesure de perf : TTFB, LCP côté front, temps moyen de génération PHP côté back.

Stratégie de rollback

Toujours prête avant la bascule :

  • Conserver l’option de retour à l’ancienne version PHP côté hébergeur (ou un tag Docker stable).
  • Snapshot base de données & fichiers juste avant la migration.
  • Plan clair : qui fait quoi si incident (réversibilité < 10 minutes).

Conclusion

Migrer un WordPress vers PHP 8.x est surtout une affaire de méthode : staging, analyses statiques, logs propres, tests fonctionnels, puis bascule encadrée et mesurée. Avec la check-list et les outils ci-dessus, vous minimisez le risque et profitez des gains de performances et de sécurité — sans surprises en production.