PHP 5.6 est sortie !

4 novembre 2014 php, php-5.6

PHP 5.6 a été publiée le 28 août, un peu plus d’un an après la sortie de PHP 5.5 — essayant ainsi de se conformer au planning de releases qui prévoit, depuis PHP 5.4 il y a deux ans, la sortie d’une version mineure par an.

Dans la suite logique de ce qui avait été fait pour PHP 5.4 et 5.5 il y a respectivement deux ans et un an, PHP 5.6 apporte plusieurs nouveautés destinées à faciliter la vie des développeurs travaillant avec le langage, en particulier au niveau de la syntaxe de celui-ci — sans toutefois révolutionner quoi que ce soit1.

Je vais, au cours de cet article, passer en revue quelques-uns des points qui attirent mon attention vers cette toute nouvelle version.


Fonctions variadiques et unpacking d’arguments

Les deux éléments qui sont le plus souvent cités lorsque l’on parle des nouveautés introduites par PHP 5.6 vont de pair : il s’agit des fonctions variadiques et de l’unpacking d’arguments.

Une fonction variadique se déclare en utilisant le symbole ... avant le dernier nom de variable dans sa liste de paramètres :

function ma_fonction_variadique($a, $b, ... $params) {
    var_dump($a, $b, $params);
}

Elle s’appelle ensuite comme n’importe quelle fonction PHP, sans que l’appelant soit limité dans le nombre de paramètres qu’il peut passer :

ma_fonction_variadique(10, 20, 30, 40, 50);

La fonction recevra les deux paramètres qu’elle attendait — ici $a et $b — et tous ceux passés ensuite lors de l’appel se verront regroupés au sein du tableau $params. La sortie obtenue en exécutant cet exemple sera donc la suivante :

int(10)
int(20)
array(4) {
  [0] => int(30)
  [1] => int(40)
  [2] => int(50)
  [3] => int(60)
}

Inversement, l’unpacking de paramètres permet à un tableau de données d’être passé à une fonction sous forme de plusieurs paramètres. Par exemple, considérons la portion de code suivante :

function ma_fonction($a, $b, $c, $d) {
    var_dump($a, $b, $c, $d);
}

$tableau = [30, 40, 50, ];
ma_fonction(10, 20, ... $tableau);

Lors de son exécution, notre fonction ne recevra pas un ni deux paramètre(s), ni même cinq, mais quatre : le tableau spécifié en troisième position lors de l’appel sera découpé en plusieurs arguments, grâce à l’utilisation de l’opérateur ... (et la dernière valeur de ce tableau, 50, sera perdue puisqu’aucun paramètre du prototype de la fonction n’existe pour la recevoir).


Expressions scalaires pour les constantes

Même si l’évolution suivante semble plus mineure, je suis persuadé que c’est celle qui sera le plus rapidement et le plus largement utilisée2 : PHP 5.6 permet d’utiliser des expressions pour les valeurs de constantes lors de leur déclaration — ou comme valeurs par défaut pour les paramètres de fonctions.

En effet, il est désormais possible d’utiliser des écritures de ce type :

class MaClasse {
    const CTE_01 = 1 << 4;
    const CTE_02 = "CTE_01 vaut " . self::CTE_01 * 1.5;

    public function method($a, $b = 15*60*10) {
        // ...
    }
}

var_dump(MaClasse::CTE_02);

Vous reconnaîtrez que pouvoir utiliser 1 << 4 et 15*60*10 améliore grandement la lisibilité de cette portion de code — et que pouvoir construire la seconde constante en concaténant une chaîne avec une autre constante est fort appréciable !


use functions et use const

La fonctionnalité d’espaces de noms introduite avec PHP 5.3 incluait un mot-clef use, qui permet de faire référence à une classe d’un autre espace de noms sans avoir à passer par son nom pleinement qualifié, ainsi que d’aliaser des classes.

PHP 5.6, par le biais de use function, permet d’effectuer la même manipulation pour des fonctions.

Par exemple, considérons un fichier autrenamespace.php contenant cette portion de code :

<?php
namespace autrenamespace;

function fonction_autrenamespace() {
    var_dump(__FUNCTION__);
}

Ce fichier et cette fonction peuvent désormais être utilisés depuis un autre fichier de la manière suivante :

<?php
namespace monnamespace;
require __DIR__ . '/autrenamespace.php';

use function \autrenamespace\fonction_autrenamespace;

fonction_autrenamespace();

Avant PHP 5.6 et sans disposer de use function, il aurait fallu utiliser, systématiquement, le nom pleinement qualifié de la fonction pour pouvoir l’appeler :

\autrenamespace\fonction_autrenamespace();

Suivant la même principe, use const a aussi été ajouté à PHP 5.6, pour répondre à cette problématique pour l’emploi de constantes.


Et plein d’autres améliorations !

Quelques autres évolutions, que je ne détaillerai pas réellement ici, font aussi leur arrivée avec PHP 5.6.

Un nouvel opérateur de puissance a été introduit : **. Je doute qu’il soit très souvent employé, mais il permettra de rendre certaines opérations plus lisibles que lorsque nous devions passer par la fonction pow().

Les extensions PHP ont désormais la possibilité de surcharger les opérateurs pour les classes qu’elles définissent. Ce principe est déjà utilisé par l’extension GMP, menant à une écriture beaucoup plus intuitive (par rapport à l’emploi de fonctions) des opérations réalisées avec des grands nombres. Notez que la surcharge d’opérateurs n’est pas rendue possible à l’espace utilisateur.

De nombreuses améliorations ont été apportées au niveau de SSL/TLS, visant à améliorer la sécurité des applications développées avec PHP (en particulier, lors de l’utilisation de paramètres par défaut — qui sont souvent ceux employés par les développeurs peu expérimentés en matière de sécurité). A ce sujet, vous pouvez lire la section Changements apportés à OpenSSL pour PHP 5.6 du manuel.

Et, pour finir :

  • PHP 5.6 intègre le débogueur phpdbg — qui n’est pas encore supporté par les IDE les plus répandus, ce qui limite pour l’instant son utilité.
  • L’encodage par défaut est défini par la directive default_charset qui vaut désormais par défaut UTF-8. Il est maintenant utilisé par les fonctions qui dépendent de l’encodage, comme htmlspecialchars().
  • Un support asynchrone a été mis en place pour ext/pgsql.


Quelques risques potentiels ?

Cette nouvelle version mineure de PHP respecte assez bien le principe qui veut qu’une version mineure n’introduise pas — ou peu — de problème de compatibilité par rapport à la version précédente.

Toutefois, quelques points méritent qu’on leur prête attention — je pense en particulier à ceux-ci :

  • La vérification de certificats SSL qui est activée par défaut posera probablement quelques problèmes, en particulier en environnement de développement où nous travaillons souvent avec des certificats auto-signés.
  • Plusieurs fonctions mcrypt_*() échoueront si on leur spécifie des clefs ou IVs incorrects — ce qui est une très bonne chose en termes de sécurité, puisque cela force l’emploi de paramètres corrects (au lieu de se rabattre sur des valeurs peu sûres).
  • Enfin, l’upload de fichiers avec curl en utilisant la syntaxe @fichier n’est désormais possible que si l’option CURLOPT_SAFE_UPLOAD est renseignée à false : il convient de préférer l’emploi de CURLFile.
  • Les ressources GMP sont désormais des objets — elles ne doivent donc, en particulier, plus être validées à l’aide de is_resource().
  • always_populate_raw_post_data génère désormais une erreur de niveau E_DEPRECATED et php://input devrait être utilisé au lieu de $HTTP_RAW_POST_DATA, qui sera supprimé dans le futur.

Plusieurs de ces points sont liés à des problématiques de sécurité — ce qui explique que ces changements aient été acceptés pour une version mineure.


Bien sûr, les différents éléments abordés au cours de cet article ne constituent pas une liste exhaustive et correspondent principalement à ce qui attire mon attention vers PHP 5.6. Avant d’attaquer une montée de version de votre côté, pensez à consulter le guide de migration de PHP 5.5 à 5.6 !

Comme pour PHP 5.5 l’an dernier, je suis content de voir une nouvelle version qui apporte plusieurs nouveautés intéressantes, sans qu’elle ne constitue pour autant une révolution qui rendrait son adoption difficile.

Je conclurai en disant que j’ai hâte de pouvoir réellement me pencher sur la migration PHP 5.5 → 5.6 de quelques unes de mes applications, j’espère sur les prochains mois !

Et vous, quand prévoyez-vous de passer à PHP 5.6 ?



  1. après tout, PHP 5.6 est une version mineure : la compatibilité ascendante est primordiale pour qu’elle soit adoptée par les utilisateurs ! 

  2. Il m’arrive encore occasionnellement, y compris en PHP 5.5, d’être désagréablement surpris de ne pouvoir utiliser d’expression scalaire dans mes déclarations de constantes — alors que je sais depuis des années que ce n’est pas supporté ! 

PHP versions statistics - October 2014

October 29, 2014 php, stats, english

Cet article est aussi disponible en français.

You can follow me @pascal_martin, and there is an RSS feed of the posts I write in English.

I have collected data and written about usage of each PHP versions a few times already — up until now, always in French: this is the first time I’m doing this in English. The first time I’ve done this was in September 2011 and the most recent one was almost one year ago, in November 2013. At that time, PHP 5.2 was still representing 34.4% of PHP installations, with PHP 5.3 ahead with 48.7%.

The data presented in this post have been collected during the week-end of October 2014 18th. Stable versions of PHP are PHP 5.4.34 (which is called old-stable), PHP 5.5.18 and PHP 5.6.2. PHP 5.3 is not maintained anymore, since August 2014 14th and PHP 5.2 has been out of support for almost 4 years.


Web Servers

Before talking about PHP versions, here’s the list of web-servers I identified the most often while collecting data:

  • Apache: 5,644,243 — 58.65%
  • IIS: 1,496,967 — 15.56%
  • nginx: 1,410,170 — 14.65%
  • Others: 456,985 — 4.75%
  • GSE: 312,448 — 3.25%
  • cloudflare-nginx: 134,131 — 1.39%
  • LiteSpeed: 107,378 — 1.12%
  • Oversee Turing v1.0.0: 61,127 — 0.64%

As a graph only representing the first few results:

Apache is still in the first place — and by far — but it loses ground bit by bit, especially to nginx, which rose in one year from 7.9% to 14.8%. IIS remains at the second place, but could very well fall down one step before my next post!


Major versions of PHP

When it comes to major versions of PHP, there is no real surprise:

  • PHP 3: 415 — 0.02%
  • PHP 4: 106,866 — 4.15%
  • PHP 5: 2,470,731 — 95.84%
  • PHP 6: 36 — 0.00%
  • PHP 7: 3 — 0.00%

PHP 5 is first in line, far from the other versions1 — which is, let’s admit it, quite logical.

Still, a great number of servers are still running PHP 4 — its last version having been released in August 2008.


Minor versions of PHP

Going on with minor versions of PHP, for PHP >= 3.x and PHP <= 7.x and only keeping versions that have been detected at least 10 times, we’d get the following data:

  • PHP 3.0: 402 — 0.02%
  • PHP 3.2: 12 — 0.00%
  • PHP 4.0: 834 — 0.03%
  • PHP 4.1: 1,823 — 0.07%
  • PHP 4.2: 1,967 — 0.08%
  • PHP 4.3: 22,537 — 0.87%
  • PHP 4.4: 79,702 — 3.09%
  • PHP 5.0: 2,500 — 0.10%
  • PHP 5.1: 39,144 — 1.52%
  • PHP 5.2: 586,490 — 22.75%
  • PHP 5.3: 1,141,116 — 44.26%
  • PHP 5.4: 583,423 — 22.63%
  • PHP 5.5: 113,582 — 4.41%
  • PHP 5.6: 4,464 — 0.17%
  • PHP 6.0: 34 — 0.00%

And, as a graph:

The first interesting thing is that PHP 5.3, which has not been supported anymore for a few month, is still the most used PHP version with 44.3%, far ahead of PHP 5.2 and 5.4 which are pretty much each as used as the other, with 22.8% and 22.6%.

PHP 5.5, released in June 2013, only gets the fourth place, far behind the other three versions. And PHP 5.6, the stable version released at the end of August 2014, is pretty much invisible on this chart, with a really small 0.2% of all identified versions.

With more than 2/3 of all servers running versions of PHP that are no longer officially maintained2, I’m coming back to what I say each time I take a look at those numbers: recent versions of PHP really are not adopted fast enough and too many servers aren’t updated often enough!


Patch versions of PHP

Finally, if we take a look at patch versions of PHP 5.x, only displaying in this list the versions that are used the most3, we get the following data:

  • Pour PHP 5.0: the most used version is 5.0.4, with 0.06%.
  • Pour PHP 5.1: PHP 5.1.6 gets the first place, at 1.40%.
  • Pour PHP 5.2: here are versions with more than 0.5%:
    • 5.2.4: 16,109 — 0.65%
    • 5.2.5: 12,966 — 0.52%
    • 5.2.6: 58,772 — 2.38%
    • 5.2.9: 24,504 — 0.99%
    • 5.2.10: 19,529 — 0.79%
    • 5.2.13: 16,225 — 0.66%
    • 5.2.14: 15,734 — 0.64%
    • 5.2.17: 376,304 — 15.23%
  • Pour PHP 5.3: here too, versions with more than 0.5%:
    • 5.3.2: 36,505 — 1.48%
    • 5.3.3: 249,448 — 10.10%
    • 5.3.6: 16,333 — 0.66%
    • 5.3.8: 30,140 — 1.22%
    • 5.3.10: 108,865 — 4.41%
    • 5.3.13: 33,579 — 1.36%
    • 5.3.15: 12,839 — 0.52%
    • 5.3.23: 16,950 — 0.69%
    • 5.3.26: 28,704 — 1.16%
    • 5.3.27: 91,395 — 3.70%
    • 5.3.28: 210,465 — 8.52%
    • 5.3.29: 195,469 — 7.91%
  • Pour PHP 5.4: here are versions at more that 0.5% (and the last released version):
    • 5.4.4: 82,126 — 3.32%
    • 5.4.23: 13,759 — 0.56%
    • 5.4.24: 13,475 — 0.55%
    • 5.4.25: 13,650 — 0.55%
    • 5.4.26: 17,978 — 0.73%
    • 5.4.27: 24,689 — 1.00%
    • 5.4.28: 20,568 — 0.83%
    • 5.4.29: 27,846 — 1.13%
    • 5.4.30: 43,200 — 1.75%
    • 5.4.31: 66,772 — 2.70%
    • 5.4.32: 104,195 — 4.22%
    • 5.4.33: 77,474 — 3.14%
    • 5.4.34: 2,023 — 0.08%
  • Pour PHP 5.5:
    • 5.5.0: 953 — 0.04%
    • 5.5.1: 691 — 0.03%
    • 5.5.2: 309 — 0.01%
    • 5.5.3: 7,059 — 0.29%
    • 5.5.4: 1,005 — 0.04%
    • 5.5.5: 913 — 0.04%
    • 5.5.6: 1,561 — 0.06%
    • 5.5.7: 1,710 — 0.07%
    • 5.5.8: 1,374 — 0.06%
    • 5.5.9: 31,366 — 1.27%
    • 5.5.10: 2,287 — 0.09%
    • 5.5.11: 2,969 — 0.12%
    • 5.5.12: 3,031 — 0.12%
    • 5.5.13: 3,059 — 0.12%
    • 5.5.14: 5,117 — 0.21%
    • 5.5.15: 5,343 — 0.22%
    • 5.5.16: 23,864 — 0.97%
    • 5.5.17: 19,893 — 0.81%
    • 5.5.18: 1,054 — 0.04%
  • Et pour PHP 5.6:
    • 5.6.0: 2,743 — 0.11%
    • 5.6.1: 1,026 — 0.04%
    • 5.6.2: 692 — 0.03%

As a chart presenting all 5.x.y versions at more than 0.5% or with a version number greater than 5.4.04, we’d get:

Looking at this chart and the corresponding data, a few versions seem used more than the others:

  • PHP 5.1.6 (released in August 2006) is still here, probably because it was the version available for some entreprise (or derived) distributions (Redhat Entreprise, or CentOS 5).
  • For PHP 5.2:
    • PHP 5.2.17 (released in January 2011) is still the most used patch version of PHP, even considering all minor versions, with 15.23%.
    • PHP 5.2.6 (released in May 2008) comes on second place amongst 5.2.x versions. It was the default version of Debian Lenny and is still at 2.38%.
  • For PHP 5.3:
    • PHP 5.3.3 is the most used 5.3 version, with 10.10%. It’s the version of Debian Squeeze or CentOS 6.
    • PHP 5.3.10 came down from 7.2% to 4.41% in the last year: it was the default version of Ubuntu Precise (12.04LTS).
    • The three most recent versions of PHP 5.3 come after that, at 3.70% for PHP 5.3.27, 8.52% for PHP 5.3.28 and 7.91% for PHP 5.3.29 — updates to these versions probably correspond to hosting services that tend to use the most recent patch version available, but don’t want to update to the next (and maintained) minor version.
  • For PHP 5.4:
    • PHP 5.4.4 is number two for the 5.4 branch, with 3.32%. It’s the version of PHP of Debian Wheezy.
    • The last four releases of 5.4 are at 2.70% for PHP 5.4.31, 4.22% for PHP 5.4.32 and 3.14% for PHP 5.4.33 — PHP 5.4.34, which has been released only a few days ago, is for now only at a pretty shy 0.08%.
  • For PHP 5.5:
    • 5.5.3 is at 0.29%. It’s the default version of Ubuntu Saucy (13.10).
    • The first place, for the 5.5 branch, goes to 5.5.9 with its 1.27%: it’s the version used by Ubuntu Trusty (14.04LTS)
    • The most recent versions are at 0.97% for PHP 5.5.16, 0.81% for PHP 5.5.17 and 0.04% for PHP 5.5.18.
  • PHP 5.6 makes a shy debut here, with 0.11% for PHP 5.6.0, 0.04% for PHP 5.6.1 and 0.03% for PHP 5.6.2.

It’s nice to see that, for each minor version, the most recent releases are, in general, the ones used the most — even if many servers keep using the default versions provided by their distributions (which, for some, backport security fixes of later versions, without changing the version number of PHP).


Evolution

I will not try to write a long analysis of “why” those numbers are what they are: it’s up to you, if you want to comment on the fact that old and obsolete versions are still used and that updates are not applied often enough…

That being said, as this is not the first time I do this kind of collection of data about installed PHP versions, I thought it might be interesting to draw a chart showing the evolution of these versions. As a consequence, the following chart presents the evolution of all minor versions of PHP, since September 20115:

PHP 5.5 and PHP 5.6, the current stable releases of PHP, are barely visible on this chart… It’s up to us to ensure this changes!


Method and amounts of data

To finish this post, here are a few notes about the way I got the data presented here:

  • I started with a list of more than 12 million domain names (from Alexa’s top 1M, wikipedia dumps, …).
  • Of those 12M domains, 10.4M have been resolved to IP addresses — the remaining 1.6M were probably too old and not valid anymore.
  • Amongst the 10.4 millions of HTTP requests I’ve done, around 25% of all responses have been identified as generated by PHP. More precisely, I’ve identified 2,578,278 responses as corresponding to some kind of PHP.

With this relatively high amount of data, statistics presented earlier should be quite correct, or, at least, give results and numbers close to reality…

The informations about software and PHP versions have been obtained from the X-Powered-By and Server headers of HTTP responses, after a HEAD request, for each one of the 10.4M domains, on domain.tld, with a fallback on www.domain.tld in case the first one failed.

If you want more informations, you can take a look at the two long comments — in French — I posted a while back, to answer to a few questions that had been asked to me: the first one, and the second one.


And, you, are you using an up-to-date version of PHP?



  1. As PHP 5 is far ahead other major versions, I won’t do a graph of those: it wouldn’t be of much interest! 

  2. Some distributions (especially the enterprises-oriented ones) backport security fixes to older PHP versions. Which means some PHP 5.2 and PHP 5.3 servers might not suffer from security problems that have been fixed only after official support ended for those versions. 

  3. With about one patch release each month on two maintained branches, the full list of path versions is getting a bit long — which means I will not reproduce it in full. 

  4. With that many patch versions of PHP, I chose to only display on this chart, so it remains easy to read, versions with more than 0.5% for the oldest ones, and all versions since PHP 5.4.0 (which means all patch versions of minor versions currently maintained). 

  5. Data presented on the evolution chart are in percents, to be independent of the number of hosts, which changes each time. Please note I haven’t collected those data regularly in time, which means there is not the same amount of time between each date! 

Statistiques de versions de PHP - octobre 2014

28 octobre 2014 php, stats

This post is also available in English.

J’ai plusieurs fois collecté des statistiques à propos de l’utilisation des différentes versions de PHP : la première fois était en septembre 2011 et la plus récente était il y a presque un an, en novembre 2013. À ce moment là, PHP 5.2 représentait encore 34.4% des installations de PHP, avec PHP 5.3 en tête à 48.7%.

Les données présentées dans cet article ont été collectées le week-end du 18 octobre 2014. Les versions stables de PHP sont alors PHP 5.4.34 (qui est qualifiée de old-stable), PHP 5.5.18 et PHP 5.6.2. PHP 5.3 n’est plus maintenue depuis le 14 août 2014 et PHP 5.2 n’est plus supportées depuis presque 4 ans.


Serveurs Web

Avant de commencer à parler de versions PHP, voici la liste des serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

  • Apache : 5,644,243 — 58.65%
  • IIS : 1,496,967 — 15.56%
  • nginx : 1,410,170 — 14.65%
  • Autres : 456,985 — 4.75%
  • GSE : 312,448 — 3.25%
  • cloudflare-nginx : 134,131 — 1.39%
  • LiteSpeed : 107,378 — 1.12%
  • Oversee Turing v1.0.0 : 61,127 — 0.64%

Sous forme graphique, en ne représentant que les premiers résultats :

Apache est toujours en première place — et de loin — mais il perd petit à petit du terrain, principalement au profit de nginx, qui est passé en un an de 7.9% à 14.8%. IIS reste en seconde place, mais pourrait bien descendre d’un cran d’ici à ma prochaine collecte de données !


Versions majeures de PHP

Aucune surprise au niveau des versions majeures de PHP :

  • PHP 3 : 415 — 0.02%
  • PHP 4 : 106,866 — 4.15%
  • PHP 5 : 2,470,731 — 95.84%
  • PHP 6 : 36 — 0.00%
  • PHP 7 : 3 — 0.00%

PHP 5 est en tête, de loin1 — ce qui est, admettons-le, fort logique.

Toutefois, un nombre important de serveurs sont encore sous PHP 4, dont la dernière version a été publiée en août 2008.


Versions mineures de PHP

Si on passe aux versions mineures de PHP, pour PHP >= 3.x et PHP <= 7.x et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

  • PHP 3.0 : 402 — 0.02%
  • PHP 3.2 : 12 — 0.00%
  • PHP 4.0 : 834 — 0.03%
  • PHP 4.1 : 1,823 — 0.07%
  • PHP 4.2 : 1,967 — 0.08%
  • PHP 4.3 : 22,537 — 0.87%
  • PHP 4.4 : 79,702 — 3.09%
  • PHP 5.0 : 2,500 — 0.10%
  • PHP 5.1 : 39,144 — 1.52%
  • PHP 5.2 : 586,490 — 22.75%
  • PHP 5.3 : 1,141,116 — 44.26%
  • PHP 5.4 : 583,423 — 22.63%
  • PHP 5.5 : 113,582 — 4.41%
  • PHP 5.6 : 4,464 — 0.17%
  • PHP 6.0 : 34 — 0.00%

Et sous forme d’un graphique :

Il est intéressant de noter que PHP 5.3, qui n’est plus maintenu depuis quelques mois, est toujours la version de PHP la plus utilisée avec 44.3%, loin devant PHP 5.2 et 5.4 qui sont quasiment à égalité, respectivement à 22.8% et 22.6%.

PHP 5.5, publiée en juin 2013, n’arrive qu’en quatrième place, loin derrière les trois autres versions. Et PHP 5.6, qui est la version stable publiée fin août 2014 fait une entrée timide dans ce classement, avec un petit 0.2% des installations identifiées.

Avec plus de deux-tiers des serveurs qui tournent sur des versions de PHP qui ne sont plus officiellement maintenues2, j’en reviens à ce que j’écris à chaque fois que je regarde ces chiffres : les versions récentes de PHP ne sont que beaucoup trop lentement adoptées et trop de serveurs ne sont pas suffisamment mis à jour !


Versions releases de PHP

Enfin, si on descend au niveau des versions release de PHP 5.x, en ne conservant pour l’affichage de cette liste que les versions qui sont le plus souvent utilisées3, on obtient les données suivantes :

  • Pour PHP 5.0 : la version la plus représentées est 5.0.4, avec 0.06% des installations.
  • Pour PHP 5.1 : PHP 5.1.6 remporte la première place, avec 1.40%.
  • Pour PHP 5.2 : voici les versions à plus de 0.5% :
    • 5.2.4 : 16,109 — 0.65%
    • 5.2.5 : 12,966 — 0.52%
    • 5.2.6 : 58,772 — 2.38%
    • 5.2.9 : 24,504 — 0.99%
    • 5.2.10 : 19,529 — 0.79%
    • 5.2.13 : 16,225 — 0.66%
    • 5.2.14 : 15,734 — 0.64%
    • 5.2.17 : 376,304 — 15.23%
  • Pour PHP 5.3 : ici aussi, voici les versions à plus de 0.5% :
    • 5.3.2 : 36,505 — 1.48%
    • 5.3.3 : 249,448 — 10.10%
    • 5.3.6 : 16,333 — 0.66%
    • 5.3.8 : 30,140 — 1.22%
    • 5.3.10 : 108,865 — 4.41%
    • 5.3.13 : 33,579 — 1.36%
    • 5.3.15 : 12,839 — 0.52%
    • 5.3.23 : 16,950 — 0.69%
    • 5.3.26 : 28,704 — 1.16%
    • 5.3.27 : 91,395 — 3.70%
    • 5.3.28 : 210,465 — 8.52%
    • 5.3.29 : 195,469 — 7.91%
  • Pour PHP 5.4 : voici les versions à plus de 0.5% (et la dernière version publiée) :
    • 5.4.4 : 82,126 — 3.32%
    • 5.4.23 : 13,759 — 0.56%
    • 5.4.24 : 13,475 — 0.55%
    • 5.4.25 : 13,650 — 0.55%
    • 5.4.26 : 17,978 — 0.73%
    • 5.4.27 : 24,689 — 1.00%
    • 5.4.28 : 20,568 — 0.83%
    • 5.4.29 : 27,846 — 1.13%
    • 5.4.30 : 43,200 — 1.75%
    • 5.4.31 : 66,772 — 2.70%
    • 5.4.32 : 104,195 — 4.22%
    • 5.4.33 : 77,474 — 3.14%
    • 5.4.34 : 2,023 — 0.08%
  • Pour PHP 5.5 :
    • 5.5.0 : 953 — 0.04%
    • 5.5.1 : 691 — 0.03%
    • 5.5.2 : 309 — 0.01%
    • 5.5.3 : 7,059 — 0.29%
    • 5.5.4 : 1,005 — 0.04%
    • 5.5.5 : 913 — 0.04%
    • 5.5.6 : 1,561 — 0.06%
    • 5.5.7 : 1,710 — 0.07%
    • 5.5.8 : 1,374 — 0.06%
    • 5.5.9 : 31,366 — 1.27%
    • 5.5.10 : 2,287 — 0.09%
    • 5.5.11 : 2,969 — 0.12%
    • 5.5.12 : 3,031 — 0.12%
    • 5.5.13 : 3,059 — 0.12%
    • 5.5.14 : 5,117 — 0.21%
    • 5.5.15 : 5,343 — 0.22%
    • 5.5.16 : 23,864 — 0.97%
    • 5.5.17 : 19,893 — 0.81%
    • 5.5.18 : 1,054 — 0.04%
  • Et pour PHP 5.6 :
    • 5.6.0 : 2,743 — 0.11%
    • 5.6.1 : 1,026 — 0.04%
    • 5.6.2 : 692 — 0.03%

Sous forme d’un graphique reprenant toutes les versions 5.x à plus de 0.5% d’utilisation ou dont le numéro est supérieur ou égal à 5.4.04, on obtient :

En consultant ce graphique et les chiffres correspondant, on identifie plusieurs tendances et plusieurs versions qui semblent plus utilisées que d’autres :

  • PHP 5.1.6 (qui a été publiée en août 2006) est toujours représentée, probablement parce que c’était la version disponible sur certaines distributions entreprise ou dérivées (Redhat Entreprise, ou CentOS 5).
  • Pour PHP 5.2 :
    • PHP 5.2.17 (publiée en janvier 2011) est encore la version release de PHP la plus utilisée, toutes versions mineures confondues, avec 15.23%.
    • PHP 5.2.6 (publiée en mai 2008) arrive en seconde position parmi les versions 5.2.x. Il s’agissait de la version proposée par défaut sous Debian Lenny et elle représente encore 2.38%.
  • Pour PHP 5.3 :
    • PHP 5.3.3 est la version la plus utilisée de la branche 5.3, avec 10.10%. Il s’agit de la version fournie sous Debian Squeeze ou CentOS 6.
    • PHP 5.3.10 est descendue de 7.2% à 4.41% en presque un an : il s’agissait de la version distribuée par Ubuntu Precise (12.04LTS).
    • Viennent ensuite les trois versions les plus récentes de PHP 5.3, à 3.70% pour PHP 5.3.27, 8.52% pour PHP 5.3.28 et 7.91% pour PHP 5.3.29 — les montées vers ces versions doivent correspondre à des hébergeurs qui ont tendance à utiliser la version release la plus à jour disponible, sans pour autant souhaiter effectuer une montée de version mineure (vers une version maintenue, s’entend).
  • Pour PHP 5.4 :
    • PHP 5.4.4 est numéro deux des versions 5.4, avec 3.32%. C’est la version fournie par Debian Wheezy.
    • Les quatre dernières versions de 5.4 sont quant à elles à 2.70% pour PHP 5.4.31, 4.22% pour PHP 5.4.32 et 3.14% pour PHP 5.4.33 — PHP 5.4.34, qui est sortie il y a quelques jours, n’étant pour l’instant qu’à un timide 0.08%.
  • Pour PHP 5.5 :
    • Pour ce qui est de PHP 5.5, la version 5.5.3 est à 0.29%. C’est la version fournie par défaut pour Ubuntu Saucy (13.10).
    • La première place, pour la branche 5.5, revient à PHP 5.5.9 avec ses 1.27% : c’est la version distribuée par Ubuntu Trusty (14.04LTS)
    • Les versions les plus récentes sont quant à elles à 0.97% pour PHP 5.5.16, 0.81% pour PHP 5.5.17 et 0.04% pour PHP 5.5.18.
  • PHP 5.6 fait une timide apparition, avec 0.11% de PHP 5.6.0, 0.04% de PHP 5.6.1 et 0.03% de PHP 5.6.2.

Il est agréable de constater que, sur chaque version mineure, les releases les plus récentes sont, globalement, les plus utilisées — même si de nombreuses installations restent sur les versions fournies par les distributions (qui, pour certaines, intègrent des correctifs de sécurité de versions supérieures, sans pour autant changer de numéro de version).


Évolution

Fidèle à mon habitude, je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présentés ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 20115 :

PHP 5.5 et PHP 5.6, les versions actuellement stables de PHP, sont à peine visible… À nous de faire en sorte que cela change !


Méthode et volumes de données

Pour terminer, voici quelques brèves notes à propos de la façon dont j’ai obtenu les chiffres présentés ici :

  • Je suis parti d’une liste de plus de 12 millions de noms de domaines (obtenue depuis le top 1M Alexa, des dumps wikipedia, …).
  • Sur ces 12M domaines, 10.4M ont pu être résolus vers une adresse IP — les 1.6M restant étant probablement trop vieux et plus valides.
  • Sur les 10.4 millions de requêtes HTTP effectuées, environ 25% des réponses ont été identifiées comme générées par du PHP. Plus précisément, j’ai identifié 2,578,278 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus haut devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…

Les informations de logiciels et de versions de PHP ont été obtenues en analysant les en-têtes X-Powered-By et Server des réponses HTTP obtenues en effectuant une requête HEAD, pour chacun des 10.4M de domaines, sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Pour ceux qui voudraient plus de détails, je vous invite à lire deux commentaires romans que j’avais postés suite à l’article de janvier 2013, en réponses à quelques questions qui m’avaient été posées : le premier, et le second.


Et vous, utilisez-vous une version à jour de PHP ?



  1. PHP 5 étant loin devant toutes les autres versions majeures, je ne présenterai pas de graphique : il n’aurait pas un grand intérêt ! 

  2. Certaines distributions (principalement celles orientées entreprise) backportent des correctifs de sécurités vers les vieilles versions de PHP. Certains installations en PHP 5.2 ou 5.3 ne souffrent donc peut-être pas des failles de sécurité corrigées après l’arrêt de la maintenance officielle de ces versions. 

  3. À raison d’environ une release par mois sur deux branches maintenues en parallèle, la liste complète des versions releases se fait un peu longue — je ne la reproduit donc pas intégralement ici. 

  4. Avec autant de versions release de PHP, j’ai choisi de n’afficher sur ce graphique, pour qu’il reste lisible, que les versions à plus de 0.5% pour les plus anciennes et toutes les versions depuis PHP 5.4.0 (pour présenter l’ensemble des versions release de versions mineures aujourd’hui maintenues). 

  5. Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. Notez que les collectes n’ont pas été effectuées de manière très régulière dans le temps ; il n’y a donc pas le même écart entre chaque date ! 

I, developer, survived two weeks without coffee!

October 9, 2014 stories, english

Cet article est aussi disponible en français.

When I was younger and/or still a student, I wasn’t really used to drinking coffee: I would have one every once in a while, but nothing more — and it was definitely not a habit.

The day I started working in a consulting firm1, I pretty much hadn’t taken a seat yet that one of my colleagues was asking me some “do you want a coffee?”. Considering the coffee machine would be a perfect way to get to know my colleagues2, I accepted. Same thing for other colleagues I took a coffee with the following days. Or even for new hires I welcomed later on, btw.

A couple of months after the end of my internship and my hiring, with a little help from the upcoming release of a large project and unreasonable work schedules, I was still fixing tickets, saying to myself “there, one last coffee”, at more than 9PM


I rapidly got to drinking 6 to 8 cups of coffee per day — you’d just have to count:

  1. A first one early in the morning, at home, just after waking up, while reading my RSS.
  2. A coffee when arriving at work around 8-9AM depending on the days, either while reading mails (alerts, crons, error reports, …) of the night, or having a coffee break speaking with other colleagues who had arrived early3.
  3. Another coffee in the middle of the morning, around 10AM.
  4. Yet another one at the end of the morning, around 11:45, before going to eat.
  5. A fifth one just before 2PM, before going back to work.
  6. A coffee in the middle of the afternoon, around 4PM — quite often, that one was the occasion for a coffee break spent with a colleague, speaking about a specific technical point of the project we were currently working on4.
  7. And, finally, a last one around 5:30PM, before ending the day.

It’s easy: counting the points above, I’m already at 7. And that was for a normal day: working longer in the morning and the evening, during days of rush, I would sometimes have one or two additional coffee(s)

Thinking about it, at a rate of about thirty (euro-)cents per coffee (especially during the years we had an automatic coffee dispenser at work) six or more times a day, it adds up to about 2€ (~ 2.5 USD) each day. Which represents a coffee-budget of about 400€ a year! And this doesn’t include the price of the one coffee I took every morning at home!


To those who, from time to time, were telling me “you’re drinking too much coffee”, I was answering “nah, no”: after-all, I wasn’t sleeping too bad and was feeling OK during the day (else, I was considering it was just because I was working too much).

On the other hand, almost every week-end, I was quite tired and I sometimes got headaches, especially on Sundays… Same thing during the holidays, when I often felt exhausted, even while sleeping a lot more than when working…

Last year, I kind of randomly (thanks Twitter) read an article explaining how coffee works in the brain5 and I realized tiredness and headaches during week-ends might be caused by a lack of coffee, as I was only rarely having coffee on Saturday and Sunday.


So, one summer Monday morning last year, I stopped drinking coffee. Well, I tried: at 11AM, I was already getting one ;-(

The following day, Tuesday, second try. More successful. But I felt a bit tired all day long. It was to be predicted…

Wednesday morning while going to work, standing in the moving subway, I was so tired I felt like I was going to fall. Still, the evening before, I had gone to bed early, as I was feeling tired, and I had slept a long night!

I remember some urgent / critical / important / … thing that felt on me that same Wednesday at work at the end of the afternoon: the first thought that came to my mind was “I need a coffee, rrrhhhaaaa a coffee I have to get a coffee, some coffee, I need a coffee!!!”.

In the end, I spent the whole week feeling tired6, sleeping a lot to compensate, and taking dolipranes one after the other to fight headaches that didn’t want to go away. I had to wait until Saturday before things began to get better, and Sunday afternoon to finally be OK.

That’s were this article’s title comes from: I kind of feel like I survived this week without coffee!

Still, I did that brutally, going straight from 6-8 cups of coffee per day to 0, which might explain these symptoms — at the risk of being considered as binary, I think it’s easier than going down bit by bit. That week and the following one, I was having water-breaks with colleagues on coffee-break :-D

The second week without coffee, everything was going fine.

And, of course, I re-started drinking coffee — one when waking up, a second one at 9:30AM after our stand-up meeting, and a third one at the beginning of the afternoon. I console myself thinking it was more reasonable than before!


After a few months, this year, I again had the impression I was tired during week-ends, with occasional headaches on Sundays. Less than last year, but still kind of the same thing.

So, during spring, I stopped again. I’ve had headaches for a few days, but less than last year — because it wasn’t the first time I was stopping? Or because I was having less coffee per day than before?

Now, I’m almost at five months without coffee. And, most importantly, I do not need coffee anymore, even when it comes to a big deploy at 4AM at work or a 10 hours long trip to go to holidays \o/.

Now, I have to find out if I’ll be able to just drink coffee from time to time, purely because I want to7… while not having a relapse!



  1. I did my end-of-studies internship in a consulting firm in 2006 and worked there for more than five years afterwards. 

  2. After all, it seemed to me quite important to get to known, at least a bit, colleagues with whom I would work. Fresh out of school, I thought that talking around a coffee was a good way to step in a new project without immediately entering some “here’s the code, good luck!” mode. I still believe that now, actually — probably even more than at that time! 

  3. I’ve never felt guilty for having a long coffee break before 9AM: even taking my time, I was still at my workstation before the time I was supposed to arrive at work. 

  4. The afternoon coffee break, far away from workstations, is a great way to think, often with two or three colleagues, in a more calm way than with a computer — it has often allowed us to get problems solved and stuff unlocked! 

  5. I don’t have the link anymore and cannot find it again. But it was about some chemical stuff in the coffee, that takes the place of other chemical stuff in chemical receivers linked to tiredness and/or sleep in the brain, which explains why coffee helps against tiredness and sleepiness. Of course, when one stops drinking coffee, the normal chemical stuff comes back to the receivers that were blocked by coffee, which causes an impression of tiredness. (Sorry for the chemical stuff, reading this article was a while ago; and it’s been many years since molecules were more than chemical stuff to me ^^). Thanks to @tut_tuuut for the link to the Your Brain On Coffee video, which explains the same idea in a short and easy way! 

  6. I’m saying I felt like I was tired, because I was getting long nights and was sleeping enough for my body to be OK. I was feeling tired, but in parallel I don’t think I was less efficient in my work (but I might have been a bit more grumpy?). 

  7. As long as it’s not a matter of having 6-8 cups per day, I like the taste of coffee and drinking some hot beverage (especially in the morning during winter). So, I will probably drink some one day or the other: after-all, why not? 

September 2014 on internals@php

October 7, 2014 php, internals@, english

Cet article est aussi disponible en français.

730 messages have been exchanged in September 2014 on PHP’s internals@ mailing-list — almost the same number as in August.

As a graph representing the number of mails per month for the last three years, we’d get:

At the beginning of the month, Andrea Faulds wrote an RFC called “Implicit isset() in Shorthand Ternary Operator”. Its idea was to modify the ?: operator introduced with PHP 5.3 to automatically add an isset() and, so, prevent any notice from being raised.

The first answers indicated that the idea could be interesting, but, at the same time, several voices said changing the behavior of ?: in such a way might not be quite a good idea.

In the end, most of this RFC has been rewritten, leading to RFC: Null Coalesce Operator. The idea is now to add a new ?? operator, instead of changing the behavior of ?:. This new operator can be used like this:

// Uses $_GET['user'] if it exists -- or 'nobody' if it doesn't
$username = $_GET['user'] ?? 'nobody';

// Loads some data from the model and falls back on a default value
$model = Model::get($id) ?? $default_model;

With 31 votes “yes” and 3 votes “no”, this revamped version of the RFC has passed, which means PHP 7 will have a new ?? operator.


Leigh has written the RFC: loop + or control structure, which aims to add an optional block to PHP loops (for, while, foreach). This block would be executed in cases we don’t enter inside the loop (as the condition has not been true, even at first try). It would be introduced by the or keyword.

With this RFC, we could write something like this:

foreach (generator() as $k => $v) {
    // loop body
}
or {
    // executed if we never entered the
    // body of the foreach loop
}

This feature already exists in some templating languages — for instance, it is supported by Twig for its for loops, using the else keyword.

Note: using or would mean not adding a new reserved word, and else, which is used by other languages, cannot be used for PHP as it would lead to ambiguities in the language.

A few other things have been talked about in the conversation (we’ll see if someone pushes them farther, via other RFCs?), like the idea for a loop to systematically return the number of iterations done.


Robert Stoll suggested PHP 7 might be an occasion to make transtyping operations more strict. For example, (int)"a" would not longer be 0 and it would raise an error. Andrea Faulds quickly answered that explicit casts cannot fail and changing this behavior now would cause an incredible amount of bugs and BC-breaks.

Still, it might be possible to add some new transtyping functions that would be more strict — maybe like ext/filter already does? Another approach could be to use new keywords, like int('2'), or even a syntax close to constructors, like $a = new int('2').


Nikita Popov has written the RFC: Remove alternative PHP tags, which proposes to remove, for PHP 7, the alternative tags <% ... %> and <script language="php"> ... </script>.

Several answers have been quite positive, but others noted a script to facilitate the migration to <?php ... ?> would be helpful.

Votes have been opened a few days before the end of the month and results should be there at the beginning of October. For now, things seem to be going well for this RFC.


Levi Morrison noted that what is usually called type-hints are definitely not hints, as types fixed when declaring a function or a method are checked and an error is raised if passed parameters don’t match them. As a consequence, he asked if someone had a better name idea, or if we were going to keep calling those hints.

Andrea Faulds suggested Optional Type Declarations for parameters and Return Type Declaration for the return-type. As those types are not optional once they are set, Type Declarations might be a good compromise — or maybe Type Assertions.

On the other hands, Type Hints has been used for years in the manual and by the community… In the end, I’m curious to see if this proposal will go farther and if, one day, we’ll stop talking of hints for things that are actually not.


Tjerk Meesters noticed the tests of ReflectionFunction::isDeprecated() depend, for now, on functions flagged as deprecated — but, as those might get removed for PHP 7, these tests might have to be updated.

That test might also be fixed, so it finds a deprecated function by itself. Or, instead, would it not be interesting for PHP to define a __deprecated__() function, that would forever be flagged as deprecated — even if it would only exist when PHP is compiled in debug-mode?

During the conversation, Alexander Lisachenko noted that adding a deprecated keyword, that could be used from user-space, might be an interesting idea, especially for some big frameworks. I wonder if this idea has not already been suggested in the past…


Dmitry Stogov has written the RFC: Fix list() behavior inconsistency, which suggests to remove a few inconsistencies of list() when it comes to strings. Today, using list() on a string works, or not, depending on the situation:

list($a,$b) = "aa"; // $a and $b are NULL
$a[0]="ab"; list($a,$b) = $a[0]; // $a is 'a' and $b contains 'b'

For PHP to be more consistent, this RFC proposed to forbid using list() on strings, or to make it work in all cases. As Derick Rethans indicated, the second option would add a new behavior to PHP, while the first one would come to removing something that works today (even if not documented).

Votes have been opened right before the end of September. Considering how things are going for now, it is very likely something will be done, but it’s hard to predict which one of those two approaches will win.


I was saying last month a mailing-list had been setup for members of the French UG AFUP, to discuss, in French, about proposals that were announced on internals@.

Following our discussions of this month, I (as I’m acting as its coordinator) posted a summary of AFUP’s members’ opinion on three threads:

In addition, we now have a blog. I’ll try posting, mainly in French, about the opinions we have expressed on internals@, and, if possible, a few sentences to summarize the goal of each RFC and why we’ve spoken the way we did: PHP Internals en français


Matt Wilmas worked on a patch that would bring a micro-second resolution (with a good precision) to functions such as microtime(). It might be added to a next minor version of PHP 5.6.

Andrea Faulds opened votes on RFC: Scalar Type Hinting With Casts, before pausing them to give people more time to discuss the matter… And, in the end, the RFC has been withdrawn.

Leigh proposed adding two new format codes to pack() and unpack(), related to 64 bits. RFC: 64 bit format codes for pack() and unpack() has been posted a few days later. This RFC passed, with 15 votes “yes” and 0 votes “no”.

Here’s another RFC written by Andrea Faulds: RFC: ZPP Failure on Overflow. It started off the fact that, today, when a floatting-point number too big to fit in the range of an integer is passed as a parameter to an internal function (exposed by PHP or an extension) that expects an integer, it is received by this function as… an integer… which causes loss of data. This RFC proposes that, when an integer is expected as a parameter and the received value is a float that cannot fit in an integer, the parsing of the parameters of the function fails, and a warning gets raised.

At the beginning of the month, Levi Morrison announced votes were being opened on RFC: Make defining multiple default cases in a switch a syntax error. With 28 votes “yes” and 0 votes “no”, it passed: it will not be possible anymore, with PHP 7, to write more than one default section in a single switch construct.

In the middle of September, Andrea Faulds indicated the beginning of the voting phase on RFC: Integer Semantics. With 16 votes “yes” and 8 votes “no”, it seems this RFC passed — even if votes got closed pretty much a day too early.

Kris Craig wrote the RFC: Change checkdnsrr() $type argument behavior, to change the default behavior of checkdnsrr(), to fetch more than only MX records.

And, finally, Nicolai Scheer noticed it isn’t possible to use an object as an array key, even if it defines a __toString() method: this one is not automatically called. Calling __toString() automatically in such a situation doesn’t seem right, as this method is used by some to produce a printable version of an object. Instead, a new magic method __toKey() could be added, so __toString() continues to return a printable string, while this new method would return a more technical identifier.



internals@lists.php.net is the mailing-list of the developers of PHP; it is used to discuss the next evolutions of the language and to talk about enhancement suggestions or bug reports.
This mailing-list is public and anyone can subscribe from the page Mailing Lists, or read its archives using HTTP from php.internals or through the news server news://news.php.net/php.internals.