Christophe Le Bot

Pratique de la conception numérique

PHP4, PHP5, PHP6 : la saison des grandes migrations

Logo PHP

Avec un été aux allures d’automne, j’ai eu envie de présenter un flux migratoire d’exception. Nul discours écologique dans mes propos, puisqu’il est question de PHP, le langage le plus répandu pour créer des applications web. Entre la mort de PHP4, la gestation de PHP6 et PHP5 qui tarde à s’imposer, voici un point sur la situation, les enjeux… et les risques.

PHP4 en fin de course

C’est maintenant officiel, PHP4 ne sera plus supporté à partir du 1er janvier 2008. En soit, l’annonce ne choque pas puisque PHP5 a pris le relais depuis 3 ans. Mais, sur le terrain, la percée de la version actuelle de PHP est moins évidente. En cause, les nombreuses applications PHP4 encore exploitées en ligne qui freinent les hébergeurs dans l’adoption de PHP5.

Migrer de PHP4 à PHP5

Sachant que la migration de PHP4 vers PHP5 devient obligatoire, comment la réaliser en douceur dans le temps imparti (5 mois) ?

Premier point : s’informer et comprendre la nécessité de migrer. Le site Go PHP5 est là pour ça !

Go PHP5
L’initiative Go PHP5 pour promouvoir une migration rapide vers PHP5.

Ensuite, il faut mettre le nez dans l’existant et y apporter les corrections ou les évolutions nécessaires pour le rendre compatible avec PHP5. On s’aidera des ressources mises à disposition par le PHP Group :

Préparer l’arrivée de PHP6

Maintenant, quid de PHP6 ? Quitte à migrer cet automne, autant en profiter pour préparer son arrivée ! On sait maintenant à quoi ressemblera la nouvelle mouture PHP et ce qu’elle implique pour les développeurs.

A la lecture de Prepare for PHP 6, on remarque vite que PHP sera beaucoup moins permissif. On ne regrettera pas le Register Globals, ni le Safe Mode (même s’il peut gêner quelques hébergeurs à la traîne).

Bien sûr, l’abandon des Magic Quotes imposera de retoucher de nombreuses applications PHP4 pour éviter les injections de commandes (pour attaquer une base de données, par exemple). On me rétorquera que PHP5 les désactive par défaut… ce qui veut dire qu’on peut les activer pour éviter de « perdre » du temps à mettre en conformité son code ! Avec PHP6, point de salut, il faut s’y coller !

Parmi les fonctionnalités les plus attendues, les namespaces pour la programmation orientée objet, le support natif d’Unicode, l’accélérateur APC par défaut.

Le plus inattendu est sans doute goto pour spécifier où continuer l’exécution du code ! A oublier de suite en programmation orientée objet…

Après le discours, la pratique. Voilà une petite check-list (tirée du magazine Programmez, juin 2007) pour faciliter l’arrivée de PHP6 :

  • Ne pas utiliser register_globals, mais $_POST, $_GET, $_COOKIE et $_REQUEST
  • Ne pas utiliser $HTTP_POST_VARS et $HTTP_SERVER_VARS, mais $_POST et $_SERVER
  • Mettre les directives magic_quotes_* à off
  • Ne pas spécifier le passage par référence dans l’appel de fonction, mais dans le prototype
  • Ne pas utiliser la fonction __autoload() (pratique mais très gourmande)
  • Ne pas mettre une variable derrière un break, mais une constante, un nombre… ou rien
  • Désactiver le safe_mode
  • Ne pas utiliser la librairie GD1 pour traiter les images, mais la GD2
  • Utiliser l’UTF-8 ou l’UTF-16

Le dernier point est, selon moi, le plus critique. Le support d’Unicode (UTF-8 ou UTF-16) impose de convertir la chaîne complète du développement : fichiers de code source, fichiers de données, base de données, navigateur web, etc. Or le support d’Unicode est loin d’être un réflex dans les projets web. Quel webdesigner se préoccupe de déclarer le support de l’Unicode dans Dreamweaver ? La question qui suit est : pourquoi la majorité des outils propose encore l’ISO-8851 ou CP1252 par défaut ? Bref, ce point dépasse le cadre des évolutions de PHP, mais deviendra un vrai Capharnaüm s’il n’est pas traité dans son ensemble.

Une opportunité pour les entreprises… et leurs prestataires

Inutile de tourner autour du pot : la migration nécessaire de PHP4 vers PHP5 demandera d’ici la fin de l’année un certain travail aux équipes de développement PHP de tous bords. Pour le bien des entreprises, c’est certain. Elles verront leur système d’information évoluer et gagner en maturité. Pour leurs prestataires aussi qui sauront profiter de l’opportunité pour aller plus loin qu’une simple mise en conformité iso-fonctionnelle.

4 commentaires

Auteur
eMeRiKa
Date de publication
22 juillet 2007 à 23h48

Dreamweaver CS3 est configuré en UTF8 de base 🙂

Par contre « Ne pas utiliser la fonction __autoload() (pratique mais très gourmande) », c’est bien dommage, je ne savais pas qu’elle était gourmande car elle est sacrément pratique. Pas besoin d’include ses classes.

Et que sont les namespaces pour la programmation orientée objet??


Auteur
Christophe
Date de publication
23 juillet 2007 à 23h33

Un bon point pour Dreamweaver ! Et un mauvais pour moi qui ne l’ai pas encore mis à jour…

Concernant __autoload(), j’ai toujours fait en sorte de l’éviter car il respecte peu les principes de la programmation orientée objet. Je lui préfère un design pattern factory. L’autoload de Zend Framework est un très bon exemple de ce qu’il vaut mieux faire.

Les namespaces permettent de regrouper des éléments similaires, par exemple regrouper des classes relatives à un ensemble de fonctionnalités. Ils sont très utilisés en Java, C++, C#, mais aussi dans des applications sémantiques (RDF, ontologie). Les utilisateurs PHP les réclament depuis longtemps… et j’en fait partie ! En voilà l’implémentation dans PHP6 :
http://www.rooftopsolutions.nl/article/139


Auteur
Jean-Philippe
Date de publication
15 septembre 2007 à 12h25

Effectivement, aprés quelques tests, les namespaces dans sont assez prometteurs, vous pouvez trouver quelques exemples sur mon blog :
http://www.jeanphi.fr/blog/show/stripped_title/php6-et-namespace#comments


Auteur
Christophe
Date de publication
19 septembre 2007 à 22h56

Ces exemples se passent d’explication. Merci !


* Informations obligatoires