Table des matières
Ouvrir table des matières
Migrer votre application PHP vers PHP 7
Cet article a été réécrit pour la magazine Programmez! Vous pouvez retrouver l’article ainsi que les sources directement sur ce lien 🔗.
Une des choses les plus redoutées lorsque vous avez une application en production datant de plusieurs années s’est effectuée sa migration tant niveau hardware qu’au niveau logiciel. La première application que j’ai créée c’est l’ERP de la société dans laquelle je travaille et elle est toujours utilisée quotidiennement par une vingtaine d’utilisateurs.
Malgré que je sois Chef de Projets depuis presque 3 ans, j’ai toujours la casquette de « Web Application Developer » que je porte fièrement depuis plus de 7 ans. L’ERP, en PHP/MySQL, à 7 ans depuis quelques mois et il n’a jamais réellement subi de refonte au niveau du code ni même d’upgrade au niveau technologie (nous sommes toujours en PHP 5.5).
Et naturellement, des soucis commencent à se faire sentir : lenteurs dans certaines parties de l’application, bases de données grandissantes, limites technologiques.
Il y a un an, nous avons migré en version de base de données de MySQL (5.5 vers la 5.7) sur un serveur dédié à l’ERP (la base de données était hébergée sur un serveur mutualisé qui contenait les bases de données des ERP de nos clients). En plus de bénéficier des correctifs et de nouvelles fonctionnalités, nous avons observé de meilleures performances au niveau des exécutions des requêtes et donc au niveau de l’ERP.
Hélas, cela ne suffisait pas à optimiser complètement l’application comme on l’aurait souhaité. Mais nous avons d’autres idées en réserve :
- Migrer l’application en PHP 7
- Retravailler certaines requêtes SQL dans l’application présentant des latences
Nous avons entrepris les 2 en parallèle, mais je vais me concentrer dans cet article sur la migration vers PHP 7.
Pourquoi migrer vers PHP 7 ?
Il y a plusieurs raisons à citer, mais je prendrais 2 très légitimes.
La première raison c’est le côté nouveauté et performance du nouveau moteur.
Il faut bien comprendre que PHP est resté très figé pendant de nombreuses années surtout entre les 2 dernières versions :
- PHP 3 : 1998
- PHP 4 : 2000
- PHP 5 : 2004
- PHP 5.3 : 2009
- PHP 5.4 : 2012
- PHP 5.5 : 2013
- PHP 5.6 : 2014
- PHP 6 : début du développement en 2005 pour être finalement abandonné en 2010
- PHP 7 : 2016
L’échec de PHP 6 en est la principale cause et même s’il y eut des bonnes évolutions entre PHP 5.3 et PHP 5.6, il n’en restait pas moins que le langage traînait dernière lui un moteur vieillot et qui commencé à ne plus être aussi performant qu’à l’époque.
Et les benchmarks sur internet sont très tentants :
Mais on peut se poser la question : « est-ce le cas en réalité » ? Et pour avoir testé PHP 7, je peux vous dire que vous allez voir une nette différence de chargement de vos pages pour n’importe laquelle de vos applications PHP. Car grâce à son nouveau moteur, PHP 7 est capable, de faire beaucoup de traitements en beaucoup moins de temps et la compilation de votre résultat pour être affiché à l’écran est devenu nettement plus rapide.
Et ce dernier point est très important, car en PHP 5.5 nous observions des latences de chargements de certaines pages sur l’ERP. La partie cliente en est-elle la cause ? (dans notre cas JQuery). Nous avons pensé à migrer sur des technologies plus récentes et plus performantes comme « Angular » ou « React », mais lorsque que l’on a effectué fait un test avec PHP7, nous en avons tout de suite conclu que c’était la partie serveur la cause.
La deuxième raison c’est tout simplement la mise en place des bonnes pratiques et des meilleures normes en termes de programmation. Car PHP n’est pas un très bon élève à ce sujet. En effet, c’est un des rares langages de programmation où vous pouvez vous abstenir complètement du typage de vos variables, fonctions ou méthodes des classes par exemple.
Et même si PHP 7 n’oblige pas complètement encore à le faire, le langage ouvre une porte aux programmeurs pour les utiliser petit à petit. Ce qui fait que (je l’espère) PHP pourra être conseillé comme langage de programmation vous donnant les bonnes habitudes et les bonnes pratiques en termes de programmation pure.
Comment migrer en PHP 7 ?
La nouvelle version de PHP 7 a donné naissance à de nouvelles fonctionnalités comme le typage au niveau de vos fonctions ou méthodes, un nouvel opérateur ou encore des nouvelles syntaxes d’écritures de test plus légères qu’auparavant. Je ne vais pas m’attarder sur ces nouveautés, mais sur ce qui va nous gêner si l’on migre son application vers cette version.
Depuis le début de la version 5, pas mal de fonctions de PHP on était déclaré « DEPRECATED » et beaucoup sont maintenant obsolètes dans la version 7, c’est-à-dire qu’elle n’existe plus. Et si vous les utilisez en PHP 7, vous aurez droit à une belle erreur fatale. Et la liste est tellement longue que les citer ici n’aurait aucun intérêt.
Autre chose : certaines conventions de nommages ne sont plus supportées comme les anciens constructeurs PHP 4 et pas mal de librairies en utilisent encore si vous ne les avez pas mises à jour régulièrement.
Alors, comment vérifier que votre application est compatible PHP 7 ? Rassurez-vous ! Il existe des outils pour cela. L’un des plus connus est Phan, mais cela fait partie d’une de ses nombreuses fonctionnalités. Il vaut mieux en prendre un qui est dédié pour cela et facile à utiliser et à installer.
PHP 7 Compatibility Checker
J’ai choisi l’outil PHP7cc qui fait très bien son travail comme son nom l’indique.
Que fait-il exactement ? Il va analyser vos fichiers PHP et vous notifiez les problèmes sous forme warning (en jaune) ou error (en rouge). Naturellement si vous avez des erreurs de syntaxes dans votre code, il vous le dira également.
Le projet est disponible directement sur Github : https://github.com/sstalle/php7cc 🔗. Pour l’installer, on peut utiliser Composer pour le mettre dans son projet.
Néanmoins, je n’ai pas utilisé cette méthode puisque cet outil va juste me permettre de faire la transition entre PHP 5.5 vers PHP 7. J’ai préféré utiliser un conteneur Docker et notamment celui-là : https://hub.docker.com/r/ypereirareis/php7cc/ 🔗.
Une fois celui-ci téléchargé, il suffit d’utiliser cette commande pour lancer le projet :
docker run -it --rm -v path/to/app:/app ypereirareis/php7cc php7cc —extensions=php /app
Et voici quelques exemples de résultat :
- Le programme va vous donner plusieurs informations comme le fichier présentant une anomalie, son numéro de ligne, la partie de code qui pose problème et l’information que PHP 7 vous donnera en temps normal
- Les lignes en jaune sont des warning c’est-à-dire qu’il est conseillé de voir ce qui se passe à la ligne de code indiqué, mais que votre code sera tout de même fonctionnel
- Les lignes en rouge sont des errors c’est-à-dire que votre code va présenter une erreur fatale sous PHP 7 et il faut donc corriger la ligne de code obligatoirement
Passons à l’action !
PHP7cc m’a donné tous les problèmes liés à mon application, il est temps de corriger les erreurs une à une et manuellement. Je sais ça prend du temps, mais on n’a pas trop le choix dans ce cas présent non ? Le plus simple c’est de se préoccuper des errors avant les warnings, car il faut bien commencer par quelques choses et bien évidemment les errors sont prioritaires.
Mais comment les résoudre efficacement ?
La première chose à faire c’est de mettre à jour toutes vos librairies et dépendances pour bénéficier de leur compatibilité avec PHP 7.
Ensuite quand vous avez une erreur du style « Removed fonction ’Nom de la fonction’ called », il suffit de taper le nom de la fonction en question sur la documentation de PHP (php.net) et de trouver son remplaçant.
Un exemple avec la fonction « split »
Voici l’erreur :
Et voici ce que dit la documentation PHP :
Ici, j’ai choisi « explode » car au niveau du passage des paramètres ce sont les mêmes et on remplace la ligne de code suivante :
Par celle-ci :
Une fois le fichier sauvegardé, relancer la commande docker pour PHP7cc, l’erreur ne sera plus affichée.
Un autre exemple avec « PHP 4 constructors are now deprecated »
Voici l’erreur :
En PHP 4 (et dans d’autres langages de programmation), on crée le constructeur d’une classe en créant une méthode du même nom de la classe comme c’est le cas ici :
Mais PHP 7 ne comprend plus cette syntaxe et pour ce faire, il suffit de renommer la méthode avec la méthode magique « __construct » ce qui donne le résultat suivant :
Un petit coup de PHP7cc après le correctif et vous verrez que l’error ne va plus apparaître.
Ces 2 exemples d’erreurs sont résolus facilement avec la documentation de PHP et c’est souvent cela qui peut apparaître.
Le plus embêtant c’est lorsque vous avez une classe qui utilise un mot réservé en PHP 7. Dans mon cas par exemple, je possède une classe « Error » et ce mot-clé est réservé. J’ai dû renommer ma classe avec un autre nom pour pallier au problème, mais le souci c’est qu’il faut aussi modifié l’ensemble des parties de l’application qui instance la classe (et il y en a pas mal).
Heureusement, lorsqu’on utilise un IDE, on bénéficie d’une fonctionnalité appelée « refactoring » qui va en plus de renommer le nom de la classe modifier l’ensemble de votre application pour modifier son appel automatiquement.
En résumé, certaines erreurs seront plus difficiles que d’autres à modifier.
Et ensuite ?
Vous vous doutez bien que si vous corrigez votre code pour qu’il soit compatible PHP 7, vous allez devoir le tester. Si vous avez mis en place des tests unitaires dans votre code, alors cela sera certainement très simple de vérifier que votre adaptation n’a pas tout cassé votre application.
Si vous n’avez pas de tests unitaires, alors vous n’aurez pas le choix de tester chacun de vos changements manuellement et l’un après l’autre.
Et croyez-moi cela sera long et pénible comme tâche?
Enfin, vous devrez tester l’ensemble de votre application sur votre nouvel environnement PHP 7 comme test final pour valider définitivement vos changements.
Conclusion
Sur le principe passé à PHP 7 n’est pas compliqué quand on utilise les bons outils, mais dans la pratique (et suivant les adaptations à faire) cela peut être long, très pénible et fastidieux.
Néanmoins, il ne faut pas perdre de vue le gain futur apporté à votre application sur ce nouveau moteur.
C’est un mal aujourd’hui pour un bien pour demain !
