Discussion :

[Michael Guilloux]

W3Tech : plus de 60 % des sites Web tournent sur PHP 5.x
une version qui ne sera plus supportée après le 31 décembre 2018

Passé le 31 décembre 2018, aucune version de PHP 5.x ne va encore bénéficier de mise à jour de sécurité, puisque PHP 5.6, la dernière version de la branche, sera également coupée de ces mises à jour. Cela n'est toutefois pas une nouvelle, car c'est bien connu de la communauté PHP depuis plus d'un an. Ce qui devrait donc avoir laissé suffisamment de temps aux sites Web utilisant PHP 5.x pour migrer vers PHP 7.1+ (la fin des mises à jour de sécurité de PHP 7.0 étant prévue pour le 3 décembre).

Mais le constat est que des millions de sites internet utilisent encore PHP 5.x à 10 semaines de la fin des mises à jour de sécurité de cette branche du langage de programmation Web. C'est en tout cas ce que révèlent les dernières statistiques de W3Tech.

Pour information, W3Techs (World Wide Web Technology Surveys) est un site spécialisé dans les enquêtes sur l’utilisation des technologies du Web. Il produit donc régulièrement des statistiques sur les technologies Web les plus populaires selon différentes catégories, y compris les langages utilisés pour le développement de sites Web.

D'après W3Tech, la version 5.x de PHP est utilisée par 78,3 % des sites Web utilisant PHP. Or au mois d'octobre 2018, PHP est de très loin le langage de programmation Web côté serveur le plus utilisé. Le même baromètre indique en effet que PHP est utilisé par 78,9 % de tous les sites Web dont il a pu identifier le langage côté serveur. Ce qui veut dire qu'environ 62 % de tous les sites Web utilisent PHP et pourraient donc être exposés après le 31 décembre 2018.

Le fait qu'autant de sites internet utilisent PHP 5.x n'est pas un problème en soi, en théorie, puisqu'il y a encore un peu de temps pour migrer. Mais il est probable que la grande majorité ne se soucie guerre de la fin des mises à jour de sécurité de PHP 5.6, comme l'avait déjà montré Semaphore CI, un fournisseur de solutions de Continous Integration & Delivery, également connu pour ses publications régulières sur les versions de langages open source qui sont utilisées dans des projets commerciaux.

Fin décembre 2017, Semaphore annonçait que les versions 5.3, 5.4 et 5.5 de PHP, qui n'étaient plus supportées, étaient utilisées dans 34 % des projets PHP. Pendant ce temps, 37 % des projets PHP utilisaient la version 5.6, dont la période de support actif s'est terminée le 19 janvier 2017.

D'après Semaphore CI, cela peut être dû au fait que le processus de mise à jour de 5.x à 7.x est complexe, avec par exemple de nombreuses erreurs fatales converties en exceptions, beaucoup de changements dans la gestion des variables et des entiers, entre autres.

Mais la lenteur dans la migration vers les nouvelles versions de PHP peut également s'expliquer par le manque d'effort collectif pour pousser les sites Web à passer aux versions plus récentes de PHP. Lorsqu'on regarde par exemple les gros propulseurs de PHP sur le web, les systèmes de gestion de contenu (CMS) écrits en PHP, seul Drupal a décidé de passer à PHP 7.x comme version minimale exigée, mais il faudra encore attendre mars 2019 pour que ce changement entre en vigueur, alors que PHP 7.0 ne va plus recevoir de mise à jour de sécurité le 3 décembre prochain. Pendant ce temps, la version minimale est PHP 5.3 pour Joomla et PHP 5.2 pour WordPress. Précisons que WordPress représente 59,5 % des parts sur le marché des CMS et est utilisé par 32 % de tous les sites Web, d'après les dernières statistiques de W3Tech.

Sources : W3Tech, Support PHP

Et vous ?

Qu'en pensez-vous ?
Qu'est-ce qui pourrait freiner la migration vers les dernières versions de PHP ?
Utilisez-vous PHP ? Pourquoi et quelles versions ?

[Uther]

Ce qui serait intéressant de savoir c'est combien de ces sites sont déjà sur des versions non maintenues de PHP ? Je serais prêt à parier que c'est le cas de la plupart d'entre eux.

La plupart de ceux qui se soucient de la sécurité ont depuis longtemps planifié la migration. La plupart des autres n'auraient pas fait les mises à jour de sécurité de la branche 5.x si elle avait continué de toute façon.

[ShigruM]

franchement le passage de php 5.6 à 7 se fait sans douleur.
Pour peut que les sites maintiennent leurs code à jour je ne pense que cela pose trop de probleme de passer à php7, surtout que maintenant tous les outils/libs ont migrer dessus (sauf quelque rare truc mort depuis longtemps)
je veut dire c'est pas non plus le passage de python2 à python3 non plus.

php5 (et 7) reste quand même un langage qui a évolué au fils des années de manière douce et progressive.
un bon éleve dans ce domaine

et surtout php7 à un argumente solide, une amélioration des perf très conséquente, sur mon site j'ai eu une amélioration de 40% quand même !

[Zefling]

franchement le passage de php 5.6 à 7 se fait sans douleur.
Pour peut que les sites maintiennent leurs code à jour je ne pense que cela pose trop de probleme de passer à php7, surtout que maintenant tous les outils/libs ont migrer dessus (sauf quelque rare truc mort depuis longtemps)
je veut dire c'est pas non plus le passage de python2 à python3 non plus.

Pour mon site, je crois que la migration m'a pris 1/2 heures à corrigé quelques points mineurs. (Juste parce que je suis en strict)
Dans l'ensemble, je pense c'est parmi les migration de version majeure les plus simple que j'ai eu à faire.

Le plus long, cela aura été d'attendre que certains outils que j'utilise fassent eux-aussi la migration.

et surtout php7 à un argumente solide, une amélioration des perf très conséquente, sur mon site j'ai eu une amélioration de 40% quand même !

Sur certaines pages je suis largement au dessus de 40%. Rien que sur le moteur de template ça a fait un bout d'environ 200%. En fait, aujourd'hui, sur mon site, c'est majoritairement les requêtes SQL qui font le temps de traitement.

[zayders]

Pour ma part je suis encore sous PHP 5.5 et malheureusement je vais devoir y rester. Des problemes liés à mon service IT et certains elements qui font que la migration est impossible et je n'ai pas la main dessus

[Steinvikel]

Qu'en pensez-vous ?
Il y a toujours une forte inertie sur les langages "populaires" qui agrègent beaucoup d'amateurs /passionnés en plus du corps de métier, d'autant plus que la courbe d'apprentissage /mise_à_jour est plate.
PHP ne devrai pas opposer autant de réticence /difficulté, ce genre de constat d'obsolescence est étonnamment toujours à la fois prévisible et surprenant.

Qu'est-ce qui pourrait freiner la migration vers les dernières versions de PHP ?
Quand se décider à passer à une version plus récente d'un langage ? --> Quand la nouvelle version est supportée par les technologies que j'utilise.
Mais aussi : dès que la migration est plutôt facile à faire, quand j'estime que la nouvelle version intègre suffisamment de nouveautés intéressantes.

Il faut que les organismes de formations aient le temps de se mettre à jour, que les développeurs se forment ou soient formés, ainsi que les éditeurs qui publient des livrent sur le sujet pour compléter / expliciter les releases notes officielles parfois obscures.
D'une part par le manque de maîtrise pour le programmeur qui doit se taper la p'tite doc de 1000 pages (C++ toise les 1600 pages) en anglais qui accompagne chaque révision (les traductions arrivant une à deux années après... quand elles arrivent), Et d'autre part l’absence de recule quant à la fiabilité du nouveau bordel (c'est pas comme si l'industrie IT n'avait jamais connu de grosses foirades lors de release/beta).
Les solutions développés ont une durée de vie nettement supérieure à celle estimée par leurs auteurs. De plus les auteurs n'assument que rarement la maintenance de leur bébé (car la tâche est chronophage et non valorisée/rémunéré).
Voilà pour le coté web-dev, question "nouveautés/sorties", question fin de support, obsolescence, sécurité... ça diffère tout de même pas tant que ça, il y a de nombreux points communs.

Quand il est dit que près de 80% des sites n'ont toujours pas migré à PHP 7+, j'imagine que plus de la moitié de cette part concerne des non dev-web ...combien utilisent des solutions clé en main, font leur propre site de présentation, porte-folio... ? Ces gens là ne souhaitent qu'une chose : que ça fonctionne (facilement). C'est créé une fois, puis mis dans un tiroir, seul le contenu est mise à jour.
A moins de rendre inopérantes les solutions tournant sous des versions obsolètes, une part non négligeable du web restera en version 5+. Il n'y a plus qu'à miser sur les mises à jour /migrations automatiques ? (pour les non dev-web)

J'ajouterai que :
PHP - turn over de 3 ans
possède un cycle de 12 mois entre version MINEURE, supporté durant 3ans
que j'entends dire que le processus de mise à jour de 5.x à 7.x est complexe (mais pas ici), et entraine de nombreux changement profond du langage (et la disparition d'Unicode de la roadmap)

résultat, en janvier 2018 :
34% des projets sont développé sur une version déjà obsolète
65% une version qui date au plus tard de 2015-08 (v5.6)
9% utilisent une version publié d'il y a moins d'un an (7.1+)

puis, en octobre 2018 :
??% des projets sont développé sur une version déjà obsolète
??% une version qui date au plus tard de 2015-12 (v7.0)
??% utilisent une version publié d'il y a moins d'un an (7.2+)
on constate que 79,1% sont sur des sites sont sur des versions en passe d'être obsolètes dans un mois (quand elles ne le sont pas déjà).

[greg91]

C'est peut être facile de migrer un code de PHP 5.x à 7.x mais cela représente tout de même un coût.... Que beaucoup de société ne veulent pas faire (ça marche alors pourquoi tu me demande des sous).

Tout les sites web ne sont pas des CMS populaires, il y aussi tout les développements en internes qui fonctionnent, rendent le service mais dont le créateur est partit depuis longtemps.
Et là on ne parle plus de coût mineurs.

En tant que petit hébergeur j'ai encore pas mal de projet en 5.3 sur mes serveurs. Pas le choix, le client est roi.

[Zefling]

C'est peut être facile de migrer un code de PHP 5.x à 7.x mais cela représente tout de même un coût.... Que beaucoup de société ne veulent pas faire (ça marche alors pourquoi tu me demande des sous).

Tout les sites web ne sont pas des CMS populaires, il y aussi tout les développements en internes qui fonctionnent, rendent le service mais dont le créateur est partit depuis longtemps.
Et là on ne parle plus de coût mineurs.

En tant que petit hébergeur j'ai encore pas mal de projet en 5.3 sur mes serveurs. Pas le choix, le client est roi.

Sauf que niveau sécurité, au bout d'un moment ça peut devenir problématique.
Si tu as un problèmes de sécurité, c'est eux ou toi le responsable ?

Prendre quelques jours pour une migration, ça coût donc moins cher que prendre un risque.

[Uther]

Ça a certes un coup et si le client ne veut pas le payer, on peut pas le forcer à le faire. Mais dans ce cas là vaut quand même mieux acter qu'il a bien été informé de la situation, qu'il comprend le risque que ça représente et qu'il accepte ce risque.

[byrautor]

Et oui, c'est la pagaille en informatique bien plus qu'ailleurs, d'ailleurs !
Faire confiance à qui ? la défiance à tous !
j'ai l'impression qu'on est dans le fonctionnement moyenâgeux des poids et mesures et des langages pour chaque village.
faire et défaire c'est toujours travailler !

[Zefling]

Et oui, c'est la pagaille en informatique bien plus qu'ailleurs, d'ailleurs !
Faire confiance à qui ? la défiance à tous !
j'ai l'impression qu'on est dans le fonctionnement moyenâgeux des poids et mesures et des langages pour chaque village.
faire et défaire c'est toujours travailler !

Le problème est plutôt que l'on essaie de faire fonctionner le monde du web, comme celui d'un logiciel déconnecté : ça veut dire en niant les menaces. Un « client lourd » n'as pas vraiment à se soucier des menaces extérieures, un serveur si.
Internet c'est un peu comme un corps avec les maladies. Dès qu'il y en a des nouvelles, soit prier pour ne pas tomber malade (et si c'est le cas se soigner après coups si c'est possible), soit faire de la prévention pour éviter de tomber malade. Le problème c'est que dans certains cas, le second peut éviter certaines morts. L'analogie n'est pas superbe, mais c'est un peu l'impression que j'ai. Et à titre perso, j'essaie de tenir mon serveur perso à jour autant que je le peux. Ça demande régulièrement du temps à y consacrer, mais c'est toujours mieux que se retrouver un jour avec plus rien, ce qui me demanderait infiniment plus de temps pour tout remonter. J'ai fait une petite estimation à plus d'un mois... ce qui fait que j'ai pas franchement envie que ça arrive.
Suivant la criticité du serveur, après on peut relativiser.

[D56_adg]

J’avais un site ISO-8859-1 dont les routines php sur les string n’étaient pas encore du type mb_string. Pour passer à php 7.x j’ai dû modifier toutes les routines et ajouter le charset parce que le server ne me permettait pas de modifier le php.ini

[PBernard18]

Si on regarde bien, PHP édite une nouvelle version chaque année.
La 7.0 date du 03/12/2015,
La 7.1 date du 01/12/2016,
la 7.2 date du 30/11/2017,
et on devrait selon toute logique voir arriver la 7.3 incessamment.

Il est évident que ce rythme pose soucis au moins pour les gros développements et les petites structures qui n'ont pas la capacité technique pour migrer dans de bonnes conditions. Bien souvent, le temps de s'habituer à la nouvelle version, tester l'applicatif et effectuer la migration, on arrive presque à la naissance d'une nouvelle version. Une solution serait donc d'augmenter la durée du support mais cela revient à gérer un nombre de versions grandissant avec un impact non négligeable sur les coûts d'édition.
L'idéal serait plutôt de réduire les versions actives pour n'en garder que deux ou trois, ce qui permettrait d'augmenter naturellement la durée du support. Je ne connais pas suffisamment PHP pour identifier si les évolutions de la 7.2 seraient applicables à la 7.1. A voir.

Le problème soulevé ici reste identique pour d'autres applicatifs. Il suffit de regarder le rythme d'évolution des principaux CMS pour s'en convaincre. Seul Joomla sort un peu du lot. Les autres versionnent à foison au moins sur leurs derniers produits. Si on considère DRUPAL, la version 7 est assez stable aujourd'hui. La version 8 versionnent rapidement (5/09/18 -> 8.6.0, 10/09/18 -> 8.6.1, 17/10/18 -> 8.6.2). Idem pour TYPO3 dont la dernière version tourne sur PHP 7.2.

Si la dessus, on remonte au niveau applicatif pur comme MANTIS ou LIMESURVEY, on arrive à une mise à jour par semaine pratiquement, ce qui devient rapidement ingérable.

Au niveau des mises à jour, il y a un autre aspect que je souhaite aborder. Chaque éditeur utilise ses propres conventions de nommage, de localisation des fichiers de mises à jour. Il est donc très compliqué d'automatiser la détection des nouvelles mises à jour. Il faut bien souvent utiliser l'application pour détecter la parution d'une nouvelle version ou aller manuellement sur le site éditeur. Il faudrait pouvoir parfaire la détection des mises à jour avant même d'utiliser le produit.

[Zefling]

J’avais un site ISO-8859-1 dont les routines php sur les string n’étaient pas encore du type mb_string. Pour passer à php 7.x j’ai dû modifier toutes les routines et ajouter le charset parce que le server ne me permettait pas de modifier le php.ini

J'avais anticipé ce genre de problème, toutes mes mb_string étaient rassemblées au même endroit. J'ai eu juste 2-3 méthodes à modifier. En général, j'essaie un peu d'abstraire ce qui me semble pas super bien foutu et qui pourrait évoluer, et clairement le support de l'Unicode en PHP en fait partie. Je l'ai aussi fait pour tous ce qui cryptage, SQL et d'autres petits trucs. Généralement quand j'ai un truc qui passe plus, c'est juste une classe impactée.

Après si t'as des mb_string partout… c'est sûr que t'as dû en chier.

[byrautor]

Si on regarde bien, PHP édite une nouvelle version chaque année.
La 7.0 date du 03/12/2015,
La 7.1 date du 01/12/2016,
la 7.2 date du 30/11/2017,
et on devrait selon toute logique voir arriver la 7.3 incessamment.

I...............................

Si la dessus, on remonte au niveau applicatif pur comme MANTIS ou LIMESURVEY, on arrive à une mise à jour par semaine pratiquement, ce qui devient rapidement ingérable.

Au niveau des mises à jour, il y a un autre aspect que je souhaite aborder. Chaque éditeur utilise ses propres conventions de nommage, de localisation des fichiers de mises à jour. Il est donc très compliqué d'automatiser la détection des nouvelles mises à jour. Il faut bien souvent utiliser l'application pour détecter la parution d'une nouvelle version ou aller manuellement sur le site éditeur. Il faudrait pouvoir parfaire la détection des mises à jour avant même d'utiliser le produit.

C'est la pagaille ! Bravo messieurs dames ! Et ils veulent gérer le futur................, bénévolement, gratuitement, sans responsabilités ........

[PBernard18]

Pour moi ce n'est pas la pagaille puisque le système des mises à jour fonctionne néanmoins correctement avec une adaptabilité certes assez lourde si on souhaite rester en conformité fonctionnelle et/ou de sécurité.
Il est juste perfectible.

Paris ne s'est pas monté en un jour et l'Open Source suit la même progression, parfois bénévolement et/ou gratuitement mais toujours de façon responsable.