PHP 5.6 sur serveur dédié : migrer vers PHP 8 proprement

PHP 5.6 a eu son heure de gloire. À sa sortie, il représentait une vraie mise à jour pour les serveurs encore bloqués en PHP 5.4 ou 5.5. Sur Debian Wheezy, on pouvait même passer par les dépôts Dotdeb pour installer rapidement PHP 5.6 avec PHP-FPM.

Aujourd’hui, le problème a changé. PHP 5.6 n’est plus une version à installer sur un serveur de production. C’est une dette technique à sortir proprement.

Si votre site, votre application métier ou votre vieux WordPress dépend encore de PHP 5.6, l’objectif n’est donc pas de prolonger l’ancien serveur. L’objectif est d’auditer, isoler, corriger, tester, puis migrer vers une version PHP maintenue.

PHP 5.6 est obsolète

PHP 5.6 n’est plus maintenu. Cela signifie qu’il ne reçoit plus de correctifs officiels de sécurité, ni de corrections de bugs, ni de support normal dans les distributions modernes.

Le sujet n’est donc plus “comment installer PHP 5.6 ?”, mais plutôt : “comment sortir d’un serveur qui dépend encore de PHP 5.6 sans casser le site ?”.

Un vieux site peut parfois continuer à fonctionner longtemps. C’est même le piège. Tant que rien ne bouge, tout semble stable. Puis un plugin se met à jour, une extension disparaît, l’hébergeur change de version, OpenSSL évolue, Composer refuse de travailler, ou une fonction PHP obsolète casse toute la page. Le réveil pique.

Pourquoi l’ancien tutoriel ne doit plus être appliqué

L’ancien article montrait comment ajouter les dépôts Dotdeb pour installer PHP 5.6 sur Debian 7. Cette méthode correspondait à une époque précise : Debian Wheezy, PHP 5.x, Apache ou PHP-FPM ancienne génération, et un écosystème serveur très différent.

Ne reprenez plus ce type de configuration sur un serveur actuel :

• Debian 7 est obsolète ;
• Dotdeb n’est plus une base saine pour un serveur moderne ;
• PHP 5.6 n’est plus maintenu ;
• les extensions PHP 5 ne correspondent plus aux paquets actuels ;
• les bibliothèques système ont changé ;
• les applications modernes ne testent plus cette version ;
• WordPress, WooCommerce, Composer et les frameworks récents ciblent PHP 7.4+ ou PHP 8.x.

Le vieux tutoriel reste utile comme trace historique, mais pas comme procédure à suivre. C’est un peu comme une carte routière de 2015 : elle explique d’où l’on vient, pas forcément comment éviter les travaux aujourd’hui.

Quand trouve-t-on encore PHP 5.6 ?

PHP 5.6 apparaît encore dans plusieurs cas typiques :

• vieux WordPress jamais migré ;
• WooCommerce très ancien ;
• thème premium abandonné ;
• plugin critique non maintenu ;
• application métier développée sur mesure ;
• intranet oublié mais encore utilisé ;
• serveur Debian ou Ubuntu jamais vraiment mis à niveau ;
• code PHP utilisant encore mysql_*, anciens constructeurs, fonctions supprimées ou comportements permissifs ;
• application qui dépend d’une extension PHP ancienne.

Dans ces situations, la migration demande de la méthode. Passer brutalement de PHP 5.6 à PHP 8 peut créer des erreurs fatales immédiates. Mais rester en PHP 5.6 expose le serveur à un risque permanent. Entre les deux, il y a une vraie stratégie de migration.

Ce qu’il ne faut plus faire

Évitez les fausses bonnes idées suivantes :

• installer PHP 5.6 depuis un dépôt exotique sur un serveur public ;
• compiler PHP 5.6 à la main sans maintenance de sécurité ;
• forcer un vieux paquet Debian sur une distribution récente ;
• exposer une application PHP 5.6 directement à Internet ;
• laisser un vieux WordPress en ligne parce qu’il “fonctionne encore” ;
• utiliser PHP 5.6 pour une nouvelle installation ;
• mettre à jour WordPress, le thème et les plugins directement en production ;
• mélanger plusieurs versions PHP sans comprendre Apache, PHP-FPM ou les pools ;
• utiliser le compte SQL root pour une application legacy ;
• repousser la migration sans calendrier.

Prolonger PHP 5.6 sans plan de sortie revient à garder une rallonge électrique brûlée “parce qu’elle marche encore”. Techniquement, oui. Jusqu’au non.

Étape 1 : identifier la version PHP réellement utilisée

Commencez par vérifier la version PHP en ligne de commande :

php -v

Mais attention : la version CLI n’est pas toujours celle utilisée par Apache, nginx ou PHP-FPM.

Listez les paquets PHP installés :

dpkg -l | grep -E '^ii\s+php|^ii\s+libapache2-mod-php'Langage du code : JavaScript (javascript)

Vérifiez les services PHP-FPM :

systemctl list-units --type=service | grep phpLangage du code : PHP (php)

Sur un serveur nginx avec PHP-FPM, cherchez les sockets configurés :

grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/nullLangage du code : JavaScript (javascript)

Sur Apache, vérifiez les modules PHP actifs :

apache2ctl -M | grep php

Si plusieurs versions de PHP cohabitent, notez quel site utilise quelle version. Sans cet inventaire, une migration PHP ressemble vite à une partie de bonneteau avec des fichiers de configuration.

Étape 2 : auditer les sites et applications du serveur

Avant de toucher à PHP, listez les sites hébergés :

ls -lah /etc/apache2/sites-enabled/ 2>/dev/null
ls -lah /etc/nginx/sites-enabled/ 2>/dev/nullLangage du code : JavaScript (javascript)

Identifiez ensuite les racines web :

grep -R "DocumentRoot" /etc/apache2/sites-enabled/ 2>/dev/null
grep -R "root " /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/nullLangage du code : JavaScript (javascript)

Pour chaque site, notez :

• le domaine ;
• le répertoire racine ;
• la version PHP utilisée ;
• le CMS ou framework ;
• les extensions PHP nécessaires ;
• la base de données associée ;
• les tâches cron ;
• les uploads ;
• les logs d’erreur ;
• le niveau de criticité.

Cette cartographie évite de casser une application métier discrète mais vitale, cachée derrière un sous-domaine oublié depuis sept ans. Le legacy aime vivre dans les placards.

Étape 3 : vérifier les extensions PHP utilisées

Listez les modules PHP chargés en CLI :

php -m

Pour PHP-FPM, vérifiez la configuration du pool et les paquets installés :

find /etc/php/ -maxdepth 3 -type f | sort
dpkg -l | grep -E '^ii\s+php.*(curl|gd|imagick|intl|mbstring|mysql|opcache|redis|soap|xml|zip)'Langage du code : JavaScript (javascript)

Les extensions à surveiller lors d’une migration PHP sont souvent :

• curl ;
• gd ;
• imagick ;
• intl ;
• mbstring ;
• mysqli ;
• pdo_mysql ;
• opcache ;
• redis ;
• soap ;
• xml ;
• zip.

Une migration PHP échoue parfois pour une raison très simple : le code est compatible, mais une extension manque. C’est vexant, mais facile à corriger quand on l’a identifié.

Étape 4 : sauvegarder avant toute migration

Ne migrez jamais un vieux PHP sans sauvegarde vérifiée. Sauvegardez les fichiers, les bases et la configuration serveur.

Exemple pour sauvegarder un site :

tar -czf /root/site-example-files-before-php-migration.tar.gz /var/www/example.comLangage du code : JavaScript (javascript)

Exemple pour sauvegarder une base MySQL ou MariaDB :

mysqldump --single-transaction --routines --triggers --events nom_de_base > /root/nom_de_base-before-php-migration.sqlLangage du code : JavaScript (javascript)

Sauvegardez aussi la configuration Apache, nginx et PHP :

tar -czf /root/server-config-before-php-migration.tar.gz \
/etc/apache2 \
/etc/nginx \
/etc/php \
/etc/cron.d \
/var/spool/cron \
2>/dev/nullLangage du code : JavaScript (javascript)

Une sauvegarde non testée est une hypothèse. Une restauration testée est une assurance. Et sur un vieux serveur, les hypothèses aiment se venger.

Étape 5 : créer un environnement de staging

La migration ne doit pas commencer en production. Créez un environnement de staging sur une VM, un conteneur, un sous-domaine protégé ou un autre serveur.

L’objectif du staging est simple :

• copier le site ;
• copier la base ;
• installer une version PHP moderne ;
• activer les mêmes extensions utiles ;
• afficher les erreurs ;
• corriger le code ;
• tester les parcours critiques ;
• préparer la bascule.

Pour WordPress, pensez aussi à désactiver l’indexation du staging et à protéger l’accès :

wp option update blog_public 0
wp option update siteurl 'https://staging.example.com'
wp option update home 'https://staging.example.com'Langage du code : JavaScript (javascript)

Adaptez les commandes à votre environnement. Et surtout, ne laissez pas un clone de production ouvert avec les mêmes données sensibles. Le staging n’est pas une vitrine.

Étape 6 : scanner la compatibilité PHP du code

Pour un projet PHP ou WordPress, commencez par un scan de compatibilité.

Avec PHPCompatibility pour WordPress, vous pouvez analyser un thème ou un plugin. Le projet PHPCompatibilityWP fournit un ruleset PHP_CodeSniffer adapté à WordPress, afin de limiter les faux positifs liés aux polyfills du cœur WordPress.

Installation typique dans un environnement de développement :

composer require --dev squizlabs/php_codesniffer phpcompatibility/phpcompatibility-wpLangage du code : JavaScript (javascript)

Exemple de scan vers PHP 8.3 :

vendor/bin/phpcs \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.3 \
  wp-content/themes/mon-themeLangage du code : JavaScript (javascript)

Pour un plugin :

vendor/bin/phpcs \
  --standard=PHPCompatibilityWP \
  --runtime-set testVersion 8.3 \
  wp-content/plugins/mon-pluginLangage du code : JavaScript (javascript)

Ce type d’outil ne remplace pas les tests fonctionnels, mais il repère rapidement les fonctions supprimées, signatures incompatibles, syntaxes obsolètes et comportements risqués.

Étape 7 : utiliser Rector pour accélérer la migration

Rector peut automatiser une partie des refactorings PHP. Il est particulièrement utile quand une base de code ancienne contient beaucoup de patterns répétitifs.

Installez Rector dans un environnement de développement, jamais directement en production :

composer require --dev rector/rectorLangage du code : JavaScript (javascript)

Créez un fichier rector.php minimal :

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Set\ValueObject\LevelSetList;

return static function (RectorConfig $rectorConfig): void {
    $rectorConfig->paths([
        __DIR__ . '/src',
        __DIR__ . '/wp-content/themes/mon-theme',
    ]);

    $rectorConfig->sets([
        LevelSetList::UP_TO_PHP_83,
    ]);
};Langage du code : HTML, XML (xml)

Lancez d’abord un dry-run :

vendor/bin/rector process --dry-run

Puis appliquez seulement si vous avez un contrôle de version, une branche dédiée et des tests :

vendor/bin/rector process

Rector peut faire gagner beaucoup de temps. Il peut aussi modifier beaucoup de code. Relisez les changements. Un outil automatique doit rester un assistant, pas un stagiaire laissé seul avec les clés du dépôt.

Erreurs fréquentes lors du passage de PHP 5.6 à PHP 8

Les migrations depuis PHP 5.6 exposent souvent les mêmes familles d’erreurs.

Ancien code	Problème	Approche de correction
mysql_connect()	Extension mysql supprimée	Passer à mysqli, PDO ou API WordPress.
Constructeurs PHP 4	Méthodes nommées comme la classe	Remplacer par __construct().
Accès tableau sur variable non tableau	Warnings ou erreurs plus strictes	Valider les types avant accès.
Paramètres obligatoires après optionnels	Signature invalide	Réordonner ou corriger les signatures.
each()	Fonction supprimée	Remplacer par foreach.
create_function()	Fonction supprimée	Remplacer par closure.
Propriétés dynamiques	Dépréciations PHP récentes	Déclarer les propriétés ou revoir le modèle objet.
Ancien code WooCommerce	APIs modifiées	Mettre à jour via hooks et méthodes officielles.

Dans WordPress, la bonne correction n’est pas toujours de “patcher vite”. Si un plugin abandonné est la source du problème, remplacez-le. Maintenir un plugin mort peut coûter plus cher que migrer vers une solution active.

Cas WordPress : migrer un vieux site PHP 5.6

Pour WordPress, procédez par étapes. Ne mettez pas tout à jour en même temps sans filet.

Commencez par inventorier la version du cœur, des thèmes et des plugins :

wp core version
wp plugin list
wp theme listLangage du code : PHP (php)

Exportez la liste des plugins actifs :

wp plugin list --status=active --fields=name,version,update,status --format=tableLangage du code : PHP (php)

Repérez les plugins abandonnés :

• plus de mise à jour depuis plusieurs années ;
• plugin absent du répertoire WordPress ;
• extension premium sans licence active ;
• compatibilité PHP 8 non annoncée ;
• erreurs dans les logs ;
• fonctions PHP 5 obsolètes.

Activez les logs sur staging, pas sur production publique :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Langage du code : JavaScript (javascript)

Puis testez les parcours critiques :

• connexion admin ;
• édition d’un article ;
• formulaires ;
• recherche ;
• uploads médias ;
• envoi d’email ;
• panier et commande WooCommerce ;
• paiement ;
• webhooks ;
• tâches cron ;
• exports/imports ;
• cache et purge.

Un site WordPress peut sembler compatible tant que vous ne testez que la page d’accueil. Les vraies erreurs vivent souvent dans le checkout, l’admin, un vieux shortcode ou une tâche cron oubliée.

Cas WooCommerce : redoubler de prudence

WooCommerce ajoute une couche de complexité : paiement, emails, webhooks, sessions, taxes, livraison, stock, extensions de prix, abonnements, memberships, facturation, ERP ou outils logistiques.

Avant de migrer PHP sur une boutique, testez au minimum :

• ajout au panier ;
• calcul des frais de port ;
• codes promo ;
• taxes ;
• paiement test ;
• emails de commande ;
• changement de statut ;
• webhooks Stripe, PayPal ou autre passerelle ;
• exports de commandes ;
• création de compte ;
• mon compte ;
• remboursement ;
• tâches Action Scheduler.

Une migration PHP réussie ne se mesure pas à “la boutique s’affiche”. Elle se mesure à “une commande complète passe, se paie, s’enregistre, s’envoie et se synchronise”. Le reste, c’est de la décoration.

Stratégie temporaire si PHP 5.6 est encore obligatoire

Parfois, vous ne pouvez pas migrer immédiatement. Une application métier peut dépendre d’un vieux framework, d’un module propriétaire ou d’un plugin introuvable. Dans ce cas, ne faites pas semblant que tout va bien. Isolez.

Mesures temporaires possibles :

• placer l’application dans une VM dédiée ;
• utiliser un conteneur isolé si vous maîtrisez l’image ;
• bloquer l’accès public par IP ou VPN ;
• désactiver les fonctions dangereuses non nécessaires ;
• restreindre les uploads ;
• mettre l’application derrière un reverse proxy ;
• forcer HTTPS ;
• activer des logs exploitables ;
• surveiller les erreurs et accès ;
• planifier une date de sortie ;
• documenter les dépendances exactes.

Ce n’est pas une solution durable. C’est une zone de quarantaine. Le mot est volontaire.

Installer plusieurs versions de PHP proprement

Sur un serveur moderne, vous pouvez parfois faire cohabiter plusieurs versions de PHP via PHP-FPM et des pools séparés. Cela permet de migrer site par site.

Le principe :

• chaque version PHP a son service PHP-FPM ;
• chaque site pointe vers le socket du bon pool ;
• les logs sont séparés ;
• les limites mémoire et temps d’exécution sont adaptées ;
• la bascule se fait vhost par vhost.

Exemple nginx avec un socket PHP-FPM moderne :

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm-example.sock;
}Langage du code : JavaScript (javascript)

Exemple de vérification des pools :

systemctl status php8.3-fpm --no-pager
ls -lah /run/php/

Ce modèle est excellent pour migrer progressivement. En revanche, évitez de multiplier les versions PHP sans suivi. Chaque version devient une surface de maintenance.

Plan de migration conseillé

Voici le plan que je recommande pour sortir d’un vieux PHP 5.6.

1. Inventorier les sites, vhosts, bases et versions PHP.
2. Sauvegarder fichiers, bases et configuration.
3. Créer un staging isolé.
4. Installer une version PHP moderne sur staging.
5. Scanner le code avec PHPCompatibilityWP ou un outil équivalent.
6. Mettre à jour ou remplacer les dépendances abandonnées.
7. Corriger les erreurs fatales.
8. Tester les parcours critiques.
9. Mettre en place un plan de rollback.
10. Basculer la production hors heures sensibles.
11. Surveiller logs, erreurs PHP, accès et métriques.
12. Supprimer PHP 5.6 une fois la migration validée.

Le point le plus important : ne migrez pas “au feeling”. Les vieux serveurs récompensent rarement l’optimisme.

Commandes utiles pour préparer l’audit

# Version PHP CLI.
php -v

# Modules PHP CLI.
php -m

# Paquets PHP installés.
dpkg -l | grep -E '^ii\s+php|^ii\s+libapache2-mod-php'

# Services PHP-FPM.
systemctl list-units --type=service | grep php

# Sockets PHP-FPM.
ls -lah /run/php/ 2>/dev/null

# Configuration PHP.
find /etc/php/ -maxdepth 4 -type f | sort

# Vhosts Apache.
ls -lah /etc/apache2/sites-enabled/ 2>/dev/null
grep -R "DocumentRoot" /etc/apache2/sites-enabled/ 2>/dev/null

# Vhosts nginx.
ls -lah /etc/nginx/sites-enabled/ 2>/dev/null
grep -R "fastcgi_pass\|root " /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/null

# Logs PHP-FPM.
journalctl -u php8.3-fpm -n 100 --no-pager

# Logs nginx ou Apache.
journalctl -u nginx -n 100 --no-pager
journalctl -u apache2 -n 100 --no-pagerLangage du code : PHP (php)

Commandes utiles pour WordPress

# Version du cœur WordPress.
wp core version

# Liste des plugins.
wp plugin list

# Liste des thèmes.
wp theme list

# Plugins actifs avec versions.
wp plugin list --status=active --fields=name,version,update,status --format=table

# Vérifier l’intégrité du cœur.
wp core verify-checksums

# Vérifier la version PHP vue par WordPress.
wp eval 'echo PHP_VERSION . PHP_EOL;'

# Afficher les constantes DB utiles.
wp config get DB_NAME
wp config get DB_USER
wp config get DB_HOSTLangage du code : PHP (php)

Ces commandes ne remplacent pas un audit complet, mais elles donnent rapidement une vue de la dette technique.

Faut-il migrer directement vers la dernière version de PHP ?

Pas forcément. Pour un vieux site PHP 5.6, une migration directe vers la toute dernière branche peut exposer beaucoup d’erreurs d’un coup.

La bonne cible dépend du projet :

• pour un vieux WordPress très fragile, commencez parfois par une étape intermédiaire en staging ;
• pour un code sur mesure, utilisez les outils de compatibilité et corrigez branche par branche ;
• pour un site maintenu, visez une version PHP actuelle et supportée ;
• pour WooCommerce, testez chaque extension métier avant bascule.

Ce qui compte, c’est de sortir du non-maintenu. La migration idéale n’est pas la plus spectaculaire. C’est celle qui arrive en production sans réveiller les clients.

Que faire des vieux dépôts PHP ?

Si votre serveur contient encore des dépôts historiques liés à PHP 5.x, auditez-les.

grep -R "dotdeb\|php5\|sury\|ondrej" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/nullLangage du code : PHP (php)

Ne supprimez pas brutalement un dépôt avant d’avoir compris quels paquets en dépendent. Commencez par lister les origines :

apt-cache policy php php5-fpm php8.3-fpm 2>/dev/nullLangage du code : JavaScript (javascript)

Après migration, vous pourrez retirer les dépôts obsolètes, purger les vieux paquets et nettoyer les dépendances inutiles.

sudo apt update
sudo apt autoremove --purge

Ne gardez pas un dépôt mort “au cas où”. Ce “cas où” devient vite une bombe à retardement dans apt update.

Après migration : surveiller les logs

La migration ne s’arrête pas au moment où la page d’accueil s’affiche. Surveillez les logs pendant plusieurs jours.

# Logs PHP-FPM.
journalctl -u php8.3-fpm -f

# Logs nginx.
tail -f /var/log/nginx/error.log

# Logs Apache.
tail -f /var/log/apache2/error.log

# Logs WordPress si WP_DEBUG_LOG est actif.
tail -f wp-content/debug.logLangage du code : PHP (php)

Sur WooCommerce, surveillez aussi :

• les logs de paiement ;
• Action Scheduler ;
• les webhooks ;
• les emails transactionnels ;
• les erreurs côté admin ;
• les lenteurs inhabituelles.

Les erreurs PHP après migration ne se montrent pas toutes le premier jour. Certaines attendent une tâche cron hebdomadaire, un export mensuel ou un client qui commande avec un cas tordu. Comme toujours.

Besoin d’aide pour migrer un vieux site PHP 5.6 ?

Checklist de migration PHP 5.6 vers PHP 8

• Identifier la version PHP réellement utilisée par chaque site.
• Inventorier les vhosts Apache ou nginx.
• Lister les pools PHP-FPM et sockets actifs.
• Lister les extensions PHP nécessaires.
• Sauvegarder fichiers, bases et configuration serveur.
• Créer un staging isolé.
• Scanner le code avec PHPCompatibilityWP ou un outil équivalent.
• Tester Rector sur une branche dédiée si le projet s’y prête.
• Mettre à jour ou remplacer les plugins et thèmes abandonnés.
• Tester les parcours critiques WordPress ou WooCommerce.
• Préparer une bascule progressive par pool PHP-FPM.
• Prévoir un rollback clair.
• Surveiller les logs après migration.
• Purger PHP 5.6 et les dépôts obsolètes quand tout est validé.

FAQ : PHP 5.6 sur serveur dédié

PHP 5.6 est-il encore maintenu ?

Non. PHP 5.6 n’est plus maintenu officiellement. Il ne doit plus être utilisé comme base normale pour un serveur de production exposé à Internet.

Puis-je encore installer PHP 5.6 sur Debian ou Ubuntu ?

Techniquement, c’est parfois possible avec des dépôts tiers, de la compilation ou des conteneurs. Mais ce n’est pas recommandé pour un serveur public. Si une application en dépend encore, isolez-la temporairement et planifiez sa migration.

Pourquoi ne pas garder PHP 5.6 si le site fonctionne ?

Parce que l’absence d’erreur visible ne signifie pas absence de risque. PHP 5.6 ne reçoit plus de correctifs officiels, et les outils modernes ne le prennent plus correctement en charge.

Faut-il migrer directement vers PHP 8 ?

Sur staging, oui, il faut viser une version maintenue. Pour un très vieux code, vous pouvez avoir besoin d’étapes intermédiaires de correction. Le passage direct en production est rarement une bonne idée.

Comment tester un vieux WordPress avant migration PHP ?

Copiez le site en staging, activez les logs, mettez à jour progressivement le cœur, les thèmes et plugins, puis testez les fonctions critiques. Utilisez WP-CLI, PHPCompatibilityWP et les logs PHP pour repérer les erreurs.

Que faire d’un plugin qui bloque la migration ?

S’il est maintenu, mettez-le à jour. S’il est abandonné, remplacez-le ou réécrivez la fonctionnalité. Garder PHP 5.6 pour un seul plugin mort est rarement une bonne stratégie.

Puis-je isoler PHP 5.6 temporairement ?

Oui, dans une VM, un conteneur ou un environnement très restreint. Limitez l’accès par IP ou VPN, surveillez les logs, bloquez les uploads risqués et fixez une date de migration. L’isolation n’est pas une destination finale.

Sources

• PHP : versions actuellement supportées
• PHP : branches non maintenues
• PHP : anciennes versions et fin du support PHP 5
• WordPress.org : prérequis serveur
• PHPCompatibilityWP : ruleset PHP_CodeSniffer pour WordPress
• Rector : refactoring et migration PHP automatisés
• SkyMinds : WordPress et compatibilité PHP 8
• SkyMinds : installer PHP 8.5 sur Ubuntu Server
• SkyMinds : configurer un pool PHP pour chaque site
• SkyMinds : migration de MySQL vers MariaDB
• SkyMinds : nettoyer et optimiser la base de données WordPress

Report a typo