Serveur dédié: passage à PHP 7.4

C’est Noël avant l’heure : PHP 7.4 est disponible, et l’installation sur serveur dédié se fait proprement avec PHP-FPM, nginx et les bons paquets d’extensions.

PHP 7.4 a marqué une vraie étape dans la modernisation du langage : propriétés typées, fonctions fléchées, covariance et contravariance limitées, déballage dans les tableaux, séparateurs numériques, weak references, préchargement OPcache et plusieurs dépréciations importantes. Le changelog officiel PHP liste ces nouveautés dans l’annonce de PHP 7.4.0. Voir l’annonce officielle PHP 7.4.

Dans mon cas, l’objectif était simple : migrer un serveur dédié de PHP 7.3 vers PHP 7.4, installer les extensions nécessaires, adapter les pools PHP-FPM, puis modifier les server blocks nginx pour pointer vers le nouveau socket.

Note importante : PHP 7.4 est aujourd’hui une version legacy. La page officielle des versions supportées de PHP précise qu’une version en fin de vie ne reçoit plus de correctifs et expose les utilisateurs à des vulnérabilités non corrigées. Voir les versions PHP supportées. Cet article garde volontairement PHP 7.4 pour les serveurs ou projets qui doivent rester sur cette branche, par exemple pour compatibilité applicative, migration progressive ou environnement historique.

Avant de migrer vers PHP 7.4

Avant de toucher au serveur, vérifiez ce qui tourne déjà. Une migration PHP ne se limite pas à installer un paquet : il faut savoir quelle version est utilisée par la CLI, par PHP-FPM, par nginx, et par chaque site.

Vérifiez la version PHP en ligne de commande :

php -v

Listez les paquets PHP déjà installés :

dpkg -l | grep -E '^ii\s+php'Code language: JavaScript (javascript)

Vérifiez les services PHP-FPM actifs :

systemctl list-units --type=service | grep phpCode language: PHP (php)

Vérifiez les sockets PHP-FPM disponibles :

ls -la /run/php/

Sur un serveur nginx, cherchez les sites qui pointent déjà vers une version PHP précise :

grep -RIn "fastcgi_pass.*php" /etc/nginx/sites-available /etc/nginx/sites-enabledCode language: JavaScript (javascript)

Cette étape évite de migrer le mauvais site, ou de croire que PHP 7.4 est actif alors que nginx continue tranquillement à envoyer les requêtes vers PHP 7.3. nginx est très bon pour obéir. Même quand on lui donne l’ancienne instruction.

Étape 1 : ajouter le dépôt PHP d’Ondřej Surý

Sur Ubuntu, le dépôt d’Ondřej Surý permet d’installer plusieurs versions de PHP côte à côte, dont PHP 7.4. Le site DEB.SURY.ORG indique que les dépôts contiennent des paquets PHP coinstallables, dont PHP 7.0 à 7.4 et plusieurs versions PHP 8.x, avec le PPA Ubuntu ppa:ondrej/php.

Installez les prérequis :

sudo apt update
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https

Ajoutez le PPA :

sudo add-apt-repository ppa:ondrej/php

Mettez à jour la liste des paquets :

sudo apt update

Si vous êtes sur Debian, n’utilisez pas le PPA Ubuntu. Utilisez plutôt le dépôt Debian adapté depuis DEB.SURY.ORG. Mélanger un PPA Ubuntu avec Debian, c’est souvent le début d’un roman policier sans coupable heureux.

Étape 2 : installer PHP 7.4 et ses extensions

L’idée consiste à reprendre les extensions déjà installées pour PHP 7.3, puis à installer leurs équivalents en PHP 7.4.

Pour un serveur web classique avec WordPress, WooCommerce, Redis, Imagick, IMAP, SOAP et OPcache, on peut installer :

sudo apt install php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-soap php7.4-xml php7.4-zip php-imagick php-igbinary php-redisCode language: CSS (css)

Quelques remarques utiles :

• php7.4-fpm fournit le service PHP-FPM utilisé par nginx ;
• php7.4-cli sert aux commandes terminal, Composer, cron et WP-CLI ;
• php7.4-mysql est indispensable pour WordPress avec MySQL ou MariaDB ;
• php7.4-curl sert aux requêtes HTTP sortantes ;
• php7.4-gd et php-imagick servent au traitement d’images ;
• php7.4-opcache améliore les performances en mettant le bytecode PHP en cache ;
• php-redis sert si vous utilisez Redis Object Cache ou un cache applicatif Redis.

Vérifiez ensuite que PHP 7.4 est bien installé :

php7.4 -vCode language: CSS (css)

Vérifiez les modules chargés :

php7.4 -mCode language: CSS (css)

Étape 3 : configurer PHP 7.4 pour la CLI

Sur un serveur avec plusieurs versions de PHP, la commande php peut pointer vers une autre version que PHP 7.4.

Vérifiez :

php -v
which php

Pour sélectionner PHP 7.4 comme version CLI par défaut avec update-alternatives :

sudo update-alternatives --config php

Sélectionnez ensuite le chemin correspondant à PHP 7.4, souvent :

/usr/bin/php7.4

Vous pouvez aussi configurer les binaires liés :

sudo update-alternatives --config phar
sudo update-alternatives --config phar.pharCode language: CSS (css)

Sur certains serveurs, vous aurez aussi phpize et php-config si vous compilez des extensions :

sudo update-alternatives --config phpize
sudo update-alternatives --config php-config

Vérifiez de nouveau :

php -v

Attention : changer la version CLI ne change pas automatiquement la version utilisée par nginx. La CLI et PHP-FPM vivent leur petite vie chacun de leur côté.

Étape 4 : adapter php.ini pour PHP 7.4

PHP-FPM et la CLI ont chacun leur fichier php.ini.

Pour PHP-FPM :

sudo nano /etc/php/7.4/fpm/php.ini

Pour la CLI :

sudo nano /etc/php/7.4/cli/php.ini

Réglages courants pour un site WordPress ou WooCommerce :

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_vars = 3000
date.timezone = Europe/Paris

Pour WooCommerce, certains builders ou imports lourds, vous pouvez monter memory_limit à 512M si le serveur a assez de RAM. Mais évitez d’augmenter à l’aveugle : une limite mémoire trop large avec trop de workers PHP-FPM peut vider la RAM très vite.

Le manuel PHP documente ces directives centrales, dont memory_limit, max_execution_time, post_max_size et upload_max_filesize. Voir la documentation PHP des directives ini.

Étape 5 : vérifier et adapter le pool PHP-FPM

PHP-FPM utilise des pools. Le pool par défaut se trouve généralement ici :

/etc/php/7.4/fpm/pool.d/www.conf

Éditez le pool si nécessaire :

sudo nano /etc/php/7.4/fpm/pool.d/www.conf

Vérifiez le socket d’écoute :

listen = /run/php/php7.4-fpm.sockCode language: JavaScript (javascript)

Vérifiez aussi les droits du socket. Sur Ubuntu/Debian avec nginx, on utilise souvent www-data :

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

PHP-FPM utilise une syntaxe proche de php.ini pour ses fichiers de configuration et de pool. La documentation officielle indique que le paramètre listen définit l’adresse, le port ou le socket Unix sur lequel le pool reçoit les requêtes FastCGI. Voir la documentation PHP-FPM.

Vous pouvez aussi ajuster les limites du pool. Exemple prudent pour un petit serveur :

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Adaptez ces valeurs à la RAM disponible, au trafic, aux extensions chargées et au poids moyen d’un process PHP. Une migration PHP est un bon moment pour mesurer, pas pour jouer au loto avec pm.max_children.

Testez la configuration PHP-FPM :

sudo php-fpm7.4 -tCode language: CSS (css)

Redémarrez PHP-FPM :

sudo systemctl restart php7.4-fpmCode language: CSS (css)

Vérifiez son état :

sudo systemctl status php7.4-fpm --no-pagerCode language: CSS (css)

Étape 6 : modifier le server block nginx

L’étape finale consiste à modifier le server block nginx du site pour pointer vers le socket PHP 7.4.

Repérez votre configuration :

grep -RIn "php7.3-fpm.sock\|php7.4-fpm.sock\|fastcgi_pass" /etc/nginx/sites-available /etc/nginx/sites-enabledCode language: JavaScript (javascript)

Éditez le fichier du site :

sudo nano /etc/nginx/sites-available/example.com

Ancien socket PHP 7.3 :

fastcgi_pass unix:/run/php/php7.3-fpm.sock;Code language: JavaScript (javascript)

Nouveau socket PHP 7.4 :

fastcgi_pass unix:/run/php/php7.4-fpm.sock;Code language: JavaScript (javascript)

Dans un bloc nginx classique pour PHP, cela peut ressembler à ceci :

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}Code language: JavaScript (javascript)

Testez nginx avant de recharger :

sudo nginx -t

Rechargez nginx :

sudo systemctl reload nginx

Si vous préférez redémarrer PHP-FPM et recharger nginx en une seule séquence :

sudo php-fpm7.4 -t
sudo nginx -t
sudo systemctl restart php7.4-fpm
sudo systemctl reload nginxCode language: CSS (css)

Étape 7 : vérifier que le site utilise PHP 7.4

Ne vous contentez pas de la version CLI. Vérifiez la version réellement utilisée par le site web.

Créez temporairement un fichier de test dans le webroot :

<?php

echo PHP_VERSION;Code language: HTML, XML (xml)

Ouvrez-le dans le navigateur, puis supprimez-le immédiatement :

rm php-version.phpCode language: CSS (css)

Vous pouvez aussi utiliser phpinfo() temporairement, mais supprimez le fichier juste après vérification :

<?php

phpinfo();Code language: HTML, XML (xml)

Pour un site WordPress avec WP-CLI, vérifiez la version CLI utilisée par WP-CLI :

wp --info

Et depuis WordPress lui-même :

wp eval 'echo PHP_VERSION . PHP_EOL;'Code language: JavaScript (javascript)

Gardez bien en tête que WP-CLI utilise la CLI. Cela ne prouve pas que nginx utilise le même PHP-FPM. Pour vérifier le web, utilisez un fichier temporaire ou la santé du site WordPress.

Étape 8 : tester le site après migration

Après passage à PHP 7.4, testez au minimum :

• la page d’accueil ;
• quelques articles ;
• l’administration WordPress ;
• les formulaires ;
• les tâches cron ;
• les uploads d’images ;
• le cache objet Redis si présent ;
• le checkout WooCommerce si le site vend en ligne ;
• les logs PHP-FPM et nginx.

Surveillez les logs en direct :

sudo tail -f /var/log/nginx/error.logCode language: JavaScript (javascript)

Selon votre configuration PHP-FPM, les logs peuvent aussi se trouver ici :

sudo journalctl -u php7.4-fpm -fCode language: CSS (css)

Ou dans un fichier dédié au pool, si vous l’avez configuré.

OPcache : vérifier l’activation avec PHP 7.4

OPcache est essentiel en production. Il évite à PHP de recompiler les scripts à chaque requête.

Vérifiez qu’il est chargé :

php7.4 -m | grep -i opcache

Dans /etc/php/7.4/fpm/php.ini, ou dans un fichier dédié comme /etc/php/7.4/fpm/conf.d/10-opcache.ini, vous pouvez vérifier ces réglages :

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

PHP 7.4 apporte aussi le préchargement OPcache, appelé OPcache preloading. C’est puissant, mais à configurer avec soin. Pour un site WordPress classique, je conseille de commencer par un OPcache simple et stable avant de jouer avec le préchargement.

Migrer un site WordPress vers PHP 7.4

PHP 7.4 a longtemps été une très bonne version pour WordPress, surtout comparée aux branches plus anciennes. Toutefois, une migration doit se préparer.

Avant bascule, vérifiez :

• la version de WordPress ;
• les extensions actives ;
• le thème parent et le thème enfant ;
• les plugins abandonnés ;
• les erreurs dépréciées en logs ;
• les tâches cron ;
• les intégrations externes ;
• les extensions PHP nécessaires.

Commande utile pour lister les plugins WordPress :

wp plugin listCode language: PHP (php)

Commande utile pour lister le thème actif :

wp theme listCode language: PHP (php)

Pour détecter des fonctions PHP anciennes dans wp-content :

grep -RInE '\b(mysql_connect|mysql_query|ereg|eregi|split)\s*\(' wp-content/Code language: JavaScript (javascript)

Si cette commande remonte des résultats dans un plugin ou thème actif, il faut corriger ou remplacer le composant avant la migration.

Nettoyer l’ancienne version PHP après validation

Une fois PHP 7.4 validé sur tous les sites, vous pouvez envisager de supprimer les anciennes versions inutilisées. Ne le faites pas immédiatement si plusieurs sites partagent le serveur.

Vérifiez d’abord les références restantes :

grep -RIn "php7.3" /etc/nginx /etc/php 2>/dev/nullCode language: JavaScript (javascript)

Si plus aucun site n’utilise PHP 7.3 :

sudo systemctl disable --now php7.3-fpmCode language: CSS (css)

Puis, seulement si vous êtes sûr :

sudo apt purge 'php7.3*'
sudo apt autoremoveCode language: JavaScript (javascript)

Sur un serveur de production, je garde généralement l’ancienne version un court moment après migration. Pas éternellement, mais assez longtemps pour ne pas confondre prudence et panique.

Commandes récapitulatives

Ajouter le dépôt :

sudo apt update
sudo apt install software-properties-common ca-certificates lsb-release apt-transport-https
sudo add-apt-repository ppa:ondrej/php
sudo apt update

Installer PHP 7.4 :

sudo apt install php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-soap php7.4-xml php7.4-zip php-imagick php-igbinary php-redisCode language: CSS (css)

Tester PHP-FPM et nginx :

sudo php-fpm7.4 -t
sudo nginx -tCode language: CSS (css)

Redémarrer PHP-FPM et recharger nginx :

sudo systemctl restart php7.4-fpm
sudo systemctl reload nginxCode language: CSS (css)

Vérifier les services :

sudo systemctl status php7.4-fpm --no-pager
sudo systemctl status nginx --no-pagerCode language: CSS (css)

Résumé rapide

Pour passer un serveur dédié nginx vers PHP 7.4 :

1. listez les paquets PHP existants ;
2. ajoutez le dépôt ppa:ondrej/php sur Ubuntu ;
3. installez PHP 7.4 et les extensions nécessaires ;
4. adaptez /etc/php/7.4/fpm/php.ini ;
5. vérifiez le pool /etc/php/7.4/fpm/pool.d/www.conf ;
6. modifiez nginx pour pointer vers /run/php/php7.4-fpm.sock ;
7. testez php-fpm7.4 -t et nginx -t ;
8. redémarrez PHP-FPM et rechargez nginx ;
9. vérifiez la version réellement utilisée par le site ;
10. gardez un rollback possible vers l’ancien socket pendant la phase de validation.

Conclusion

Passer un serveur dédié à PHP 7.4 se fait proprement si l’on sépare bien les étapes : installation des paquets, configuration de PHP-FPM, adaptation du server block nginx, tests de configuration, puis validation côté site.

La partie la plus importante reste la vérification. php -v ne suffit pas : il faut aussi confirmer que nginx pointe vers le socket PHP 7.4 et que le site web utilise réellement cette version.

PHP 7.4 reste une branche intéressante pour des projets legacy, notamment ceux qui ne sont pas encore prêts pour PHP 8.x. Toutefois, comme elle n’est plus supportée officiellement, elle doit idéalement servir d’étape de transition, pas de destination finale.

Une fois la bascule faite, surveillez les logs, testez les workflows critiques, puis planifiez la suite. Et voilà! Bonnes mises à jour !

Sources utiles

• PHP manual : directives php.ini principales
• PHP.net : annonce officielle de PHP 7.4.0
• DEB.SURY.ORG : paquets PHP et PPA Ondřej
• PHP manual : configuration PHP-FPM

Report a typo