SPIP Blog

Du logiciel libre et de la tendresse

Accueil > Gazette > Vie du blog > SPIP > Statistiques Mars 2018

Statistiques Mars 2018

samedi 24 mars 2018, par James

Un petit tour sur le site des statistiques et une envie de manger des camemberts [1] m’ont poussé à faire des graphiques en tout genre que je pose ici :

Répartition des versions SPIP 22 mars 2018
3.2 7,4%
3.0 et 3.1 51,2%
<3.0 41,4%

Ici on sépare les branches stable, maintenues et plus maintenues, d’où le regroupement des versions 3.0 (sortie en mai 2012) et 3.1. Les versions non maintenues vont de la 1.8 (sortie en avril 2005) jusqu’à la 2.1 (plus maintenue depuis octobre 2017) : Une histoire qui se déroule sur près de 12 ans, tout de même !

Le taux de la version stable parait faible. On pourrait donc penser que le rythme d’adoption de SPIP3.2 est lent.

Toutefois, rappelons que cette version n’a pas un an [2] et que le niveau d’adoption d’autres CMS peut-être lent aussi. A titre d’exemple, au même moment, la répartition des versions de Drupal [3] donne ceci :

Répartition des versions DRUPAL 11 mars 2018

Drupal 8.x est sortie en novembre 2015 [4]. Et on gardera aussi en mémoire que Drupal réalise cette statistique à l’aide d’un module qui ne recense pas de versions inférieures à Drupal 5.x et que ce module a lui aussi un niveau d’adoption à prendre en compte pour relativiser les chiffres.

Peut-on aller plus vite ?

Pour tenter de répondre à cette question, on ne pourra pas traiter d’un facteur aussi subjectif que la motivation d’un·e webmestre, ni des moyens humains à mettre en œuvre pour qu’un projet de migration d’un site SPIP réussisse. La communauté agissante de SPIP ne dispose d’aucun levier pour influencer les utilisateurs sur ces critères.

Par contre, on peut parler d’un premier critère assez objectif, un pré-requis indépassable, la version PHP minimum pour faire tourner un site SPIP. Certes, la montée de version de PHP sur les plates-formes hébergeant un ou plusieurs sites SPIP n’incombe pas forcément aux spipeurs eux-mêmes. Gageons que les webmestres ont tout de même une marge de manœuvre sur la question.

Versions PHP

Ce même site de statistiques peut, quand la version PHP n’est pas masquée (à peu près 60% des sites comptabilisés), nous donner des indications.

Un petit récapitulatif sur SPIP d’abord :

Version SPIP Première release Version PHP requise Fin de maintenance
1.8 avril 2005 3 avril 2010 ?
1.9 juillet 2006 4.0.4 mars 2012 ?
2.0 juillet 2008 ? 4.0.4 janvier 2016
2.1 avril 2010 ? 4.0.6 octobre 2017
3.0 mai 2012 5.1 -
3.1 janvier 2016 5.1 -
3.2 octobre 2017 5.4 -

Un coup d’œil à la feuille de route de PHP nous permet de voir où nous en sommes :

Versions supportées de PHP au 24 mars 2018

Pour coller au cycle de vie actuel de SPIP, on distinguera donc les versions PHP 7 et plus, PHP 5.4 et plus parce que c’est la version minimum pour faire passer un site en SPIP 3.2, PHP 5.3, et les versions PHP inférieures à 5.3

Pourquoi ce traitement de faveur pour PHP5.3 ?

Bonne question.

Il est vrai que cette version n’est plus mise à jour depuis aout 2014.

Comme il sera montré plus bas, certains sites semblent utiliser cette version sur laquelle la communauté PHP à encore un levier qui me semble avoir montré son efficacité ces dernières années : Composer. Et cet outil, pour quelques mois encore, du moins je le crois, nécessite au moins PHP5.3 pour fonctionner.

Donc, la répartition des versions PHP pour les sites SPIP donne ceci :

Répartition des versions PHP 22 mars 2018
>=7 4,8%
>=5.4 46,7%
= 5.3 19,1%
<5.3 29,4%

Un zoom de la branche stable :

Répartition PHP dans SPIP 3.2 22 mars 2018

Un zoom pour les branches maintenues :

Répartition PHP dans SPIP 3.1 22 mars 2018
Répartition des versions PHP dans SPIP 3.0 22 mars 2018

Premier constat, même si la version minimum de PHP était la 5.1, la base installée laisse suggérer que PHP n’est pas nécessairement un gros obstacle pour passer à la version stable.

Pour les versions non maintenues ...

Répartition PHP dans SPIP <3.0 22 mars 2018
à noter qu’ici, seules les versions affichant plus de 1000 sites ont été conservées, à savoir 1.9.2, 2.0 et 2.1

... c’est évidement plus délicat.

Mais pourquoi aller plus vite ?

Bonne question, encore.

L’émergence de Composer dans l’écosystème PHP a, selon moi, produit 3 effets intéressants :

  • La mise à disposition d’un nombre importants de librairies aux fonctionnalités plus ou moins larges,
  • L’accélération de la montée de version de PHP sur les plates-formes d’hébergement, même si cela a pris du temps.
  • Une très grande simplification de l’installation et de la mise à jour de librairies, de frameworks et/ou d’applications entières.

Et je crois que SPIP gagnerait à profiter d’effets semblables. Et le plus tôt serait le mieux.

Peut-être peut-on espérer que ces effets pourraient donner une certaine motivation aux webmestres avec moins de moyens nécessaire pour adopter SPIP 3.2 et ses versions futures ?

Je n’ai pas trouvé de données fiables sur la répartition des versions de PHP dans le monde. Mais les statistiques de packagist.org donne un aperçu du second point :

Répartition PHP via Composer novembre 2017

La montée de version de PHP garantit une meilleure prise en charge de la sécurité et des améliorations de performances d’une plate-forme d’hébergement.

Par contre, pour bénéficier des fonctionnalités de librairies externes, ou composants, il faut suivre plus régulièrement les releases de PHP :

Répartition PHP requis pour les composants

Pour le coup, SPIP 3.2 est bien placé pour bénéficier des effets que Composer a provoqué. Il ne resterait qu’à pouvoir utiliser composer le plus simplement possible pour SPIP.

Installations et mises à jour

Comme évoqué plus haut, un autre critère sur lequel il serait possible de faire levier, la méthode d’installation et de mise à jour d’un site.

On ne peut pas savoir comment les sites relevés par le site de statistiques ont été installés, ni quand, ni combien de montées de versions ils ont vécu.

Il existe plusieurs méthodes d’installation et de mise à jour de SPIP

  1. spip_loader.php (récupération de zip via le web)
  2. ftp (récupération de zip ou utilisation de subversion sur l’ordinateur du webmestre, puis synchronisation délicate avec la plate-forme d’hébergement)
  3. ssh et subversion (accès direct à la plate-forme d’hébergement et manipulation de divers outils en ligne de commande, mais surtout subversion)

Composer offre un autre avantage : s’abstraire du mode de récupération des composants, et permet d’utiliser d’autres outils de gestion de version, par exemple GIT. Pour cela, Composer interroge un dépôt central (https://packagist.org/) mais peut interroger d’autres dépôts publics ou privés.

Pour parler de Drupal à nouveau, il est possible d’utiliser Composer, dans certaines conditions, et par l’intermédiaire de drush, un autre outil en ligne de commande dédié offrant un large éventail de fonctionnalités d’exploitation.

Dans le système wordpress, c’est aussi par l’intégration de Composer à wp-cli qu’il est possible de fonctionner avec le reste de l’écosystème PHP.

La quasi obligation de passer par un outil intermédiaire pour les installations et les mises à jour ne me séduit pas, parce que c’est autant d’étapes techniques à franchir, entre autres arguments [5].

Un autre CMS, Typo3, utilise le mécanisme standard de Composer pour intégrer des extensions avec un dépôt bien à lui. Tout comme les frameworks Symfony et Laravel, sans dépôt spécialisé cette fois, pour ne citer qu’eux.

Mais comment faire, alors ?

Certes, l’outil de base est exclusivement réservé à un usage en ligne de commande. Mais si le plugin SVP (ou spip_loader.php) savait exploiter l’API d’un dépôt Composer, ma foi ...


On sait que le site de statistiques SPIP « indexe les sites SPIP en continu dans les moteurs de recherche, les news et les flux de microbloging ». Il ne peut en aucun être considéré que tous les sites SPIP existants sont comptabilisés. Par contre, il y a un volume qui est sans doute suffisant pour considérer que c’est un échantillon représentatif de la « vraie » base installée.


[1mes origines normandes qui parlent...

[26 mois, en fait

[4Drupal 7.x est annoncée en janvier 2011.

[5Mais j’y reviendrai peut-être un jour, c’est un autre sujet.

Messages

  • C’est érudit mais plaisant à lire. Merci Monsieur James pour ces éclaircissements. Personnellement j’aime bien ce laxisme de PHP qui permet de vieux écosystèmes perdurer notamment pour des petits structures qui n’ont pas les moyens de s’offrir une maintenance informatique forcené. C’est écologique :p

  • L’écologie serait plutôt d’utiliser des versions de PHP plus performantes, d’où la mise en exergue de la version 7 de PHP : moins de temps CPU pour un résultat équivalent à l’exécution d’un script, meilleure consommation mémoire, utilisation de mécanismes réduisant les accès en lecture/écriture aux disques durs... équivaut à moins d’électricité consommée ;-)

  • Maintenance informatique forcenée ?
    PHP évolue, SPIP aussi, les vieilles versions ne sont plus maintenues.
    Si on est un minimum sérieux et pas trop laxiste, on fait des mises à jour de son site, les hébergeurs veillent à ne pas être trop à la ramasse non plus et montent les versions.
    Qui saurait, aujourd’hui, héberger un vieux SPIP 1 en PHP 3 ?
    Être à jour, sur un site, un serveur, sur son poste de travail, c’est aussi de l’’écologie, pour ne pas se faire trouer, diffuser des cochonneries, servir de relai à spam et j’en passe...
    Et sinon, sur le côté « course à l’armement », Composer nécessite PHP 5.3.2, quand SPIP 3.2 nécessite php 5.4 :p

  • Il existe une quatrième méthode pour installer et mettre à jour : le paquet debian

  • Et d’autres méthodes d’installation/mise à jour :

    Je n’ai rien trouvé à propos de fedora/CentOS/Red Hat, pas de RPM a priori ?

  • merci @james très intéressant, difficile d’aller plus vite que les utilisateurs. Je rêve d’un monde sans mise à jour (et sans obsolescence) et pourtant les avancées sont nets question lisibilité et propreté du code.

    Sinon je salue la bonne idée de SPIP lorsque l’install de SPIP3.2 est automatiquement interdite via spip_loader ce qui permet d’échapper à une mauvaise mise à jour si le serveur est toujours < PHP5.4 :)

  • Salut @touti,

    Tu soulignes un quatrième effet intéressant : lisibilité/propreté du code. C’est vrai que Composer a favorisé l’adoption des PSRs et PHP n’est pas en reste sur l’amélioration et l’enrichissement de la syntaxe, notamment avec les classes et les objets.

    Pour l’obsolescence, sujet qui m’intéresse aussi, autant que l’éco-conception logicielle, il me semble qu’on peut aborder le problème autrement. Mais ce serait trop long à expliquer et je ne voudrais pas introduire ici une digression. À poursuivre ailleurs cependant :-)

Un message, un commentaire ?

Qui êtes-vous ?
Se connecter
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.