Des erreurs PHP sont apparues après un changement de version
Changer la version de PHP est le geste qui améliore le plus vite les temps de réponse d’un site, et c’est aussi le plus brutal. Le langage a supprimé au fil des versions des comportements tolérés depuis longtemps : ce qui produisait un avertissement discret devient une erreur qui arrête la page. Le message affiché contient toujours la réponse.
Lire le message plutôt que le craindre
Un message d’erreur PHP contient quatre informations : la nature du problème, le fichier, la ligne, et la suite d’appels qui y a mené. Le fichier suffit presque toujours à désigner le responsable. S’il se trouve dans le répertoire d’un module ou d’un thème, c’est ce composant qu’il faut mettre à jour ou remplacer — pas le cœur du CMS, et pas la version de PHP.
Les familles de messages sont peu nombreuses. Une fonction supprimée du langage produit une erreur d’appel à une fonction inexistante. Un type de donnée devenu strict produit une erreur sur un argument. Un accès à une valeur absente d’un tableau, longtemps toléré, remonte désormais bien plus fort. Ces trois cas couvrent la grande majorité des ruptures que je rencontre.
Cadrer avant de corriger
-
Vérifier la version réellement active
Beaucoup d’hébergements permettent une version différente pour le site web et pour les commandes en ligne. Une tâche planifiée peut donc échouer alors que le site fonctionne, ou l’inverse.
-
Compter les composants concernés
Si un seul module apparaît dans les messages, la correction est bornée. Si le thème et cinq modules apparaissent, la question devient celle de leur remplacement, pas de leur réparation.
-
Vérifier la compatibilité annoncée du CMS
Chaque version de PrestaShop ou de WordPress annonce les versions de PHP qu’elle supporte. Utiliser une version plus récente que celle prévue produit des erreurs même sans aucun module tiers.
-
Regarder les modifications faites dans le cœur
Un site dont le cœur a été modifié directement ne bénéficie plus des correctifs de compatibilité publiés en amont. C’est souvent là que se concentrent les erreurs.
-
Tester sur une copie
La version de PHP se change en quelques secondes dans le panneau d’hébergement, mais l’essai se fait sur une copie du site, jamais en production un jour de forte activité.
Corriger, remplacer, ou revenir
- Corriger quand le code fautif vous appartient : surcharge, module sur mesure, thème adapté. C’est le cas le plus simple et le plus durable.
- Mettre à jour quand le composant est maintenu : la version récente est presque toujours compatible, et le problème disparaît sans écrire une ligne.
- Remplacer quand le composant est abandonné : maintenir soi-même un module qui n’est plus suivi coûte plus cher qu’il n’y paraît.
- Revenir à la version précédente reste possible et immédiat, mais ce n’est qu’un délai supplémentaire, pas une solution.
Continuer sur la bonne page
-
Passer à PHP 8 sur PrestaShop
Les points de rupture connus et la marche à suivre côté PrestaShop.
-
PHP et WordPress
La montée de version côté WordPress, extensions comprises.
-
Versions de PHP en fin de vie
Pourquoi rester sur une version ancienne devient un problème de sécurité.
-
Activer le mode debug
Pour faire apparaître le message complet plutôt qu’une page blanche.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.