SPIP Blog
Statistiques Mars 2018Un 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 :
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 :
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’une 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 :
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 :
>=5.4 46,7%
= 5.3 19,1%
<5.3 29,4%
Un zoom de la branche stable :
Un zoom pour les branches maintenues :
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 ...
... 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 :
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 :
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
-
spip_loader.php(récupération de zip via le web) -
ftp(récupération de zip ou utilisation desubversionsur l’ordinateur du webmestre, puis synchronisation délicate avec la plate-forme d’hébergement) -
sshetsubversion(accès direct à la plate-forme d’hébergement et manipulation de divers outils en ligne de commande, mais surtoutsubversion)
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 ...
Messages
24 mars 2018, 19:08, par sister of mercy
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
24 mars 2018, 19:17, par James
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 ;-)
24 mars 2018, 19:45, par nicod_
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
25 mars 2018, 12:51, par James
Il existe une quatrième méthode pour installer et mettre à jour : le paquet debian
25 mars 2018, 15:29, par James
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 ?
26 mars 2018, 12:16, par touti
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 :)
26 mars 2018, 12:58, par James
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 :-)
1er mai 2018, 19:27, par Norbert73
Bonjour,
Merci James pour cette analyse détaillée. Webmaster d’une bonne poignée de site ce qui bloque le passage en 3.2 est l’incompatibilité du plugin Agenda.
Pour l’utilisation de PHP7 il faut qu’il soit disponible chez l’hébergeur ;-)
Au sujet de « Composer », je dois creuser la question car inconnu à l’instant...
25 mai 2018, 10:43, par François Daniel Giezendanner
Bonjour,
Depuis juin 2010 j’ai relevé ponctuellement les statistiques du site stats.spip.net. Cet outil indexe les sites SPIP en continu dans les moteurs de recherche, les news et les flux de microbloging. Voilà le résultat :
27356 sites vérifiés le 25 mai 2018
29803 sites vérifiés le 17 avril 2017
29815 sites vérifiés le 16 avril 2017
29830 sites vérifiés le 15 avril 2017
29845 sites vérifiés le 13 avril 2017
29835 sites vérifiés le 13 avril 2017
29858 sites vérifiés le 11 avril 2017
29869 sites vérifiés le 10 avril 2017
29887 sites vérifiés le 8 avril 2017
29907 sites vérifiés le 7 avril 2017
29894 sites vérifiés le 4 avril 2017
29896 sites vérifiés le 3 avril 2017
29901 sites vérifiés le 2 avril 2017
29912 sites vérifiés le 1 avril 2017
29908 sites vérifiés le 30 mars 2017
29921 sites vérifiés le 27 mars 2017
29934 sites vérifiés le 25 mars 2017}
29996 sites vérifiés le 20 mars 2017
30004 sites vérifiés le 18 mars 2017
30307 sites vérifiés le 1 janvier 2017
30650 sites vérifiés le 15 septembre 2016
34641 sites vérifiés le 3 décembre 2013
34513 sites vérifiés le 20 juin 2013
34429 sites vérifiés le 7 juin 2013
27’447 sites vérifiés le 15 juin 2010
Ainsi en mai 2018 avec 27356 sites SPIP on est revenu au stade de juin 2010 en passant par un maximum de 34641 sites SPIP vérifiés le 3 décembre 2013.
Les commentaires sont les bienvenus pour expliquer cette évolution (montée en puissance des sites sociaux,...).
Meilleurs messages
FDG
28 mai 2018, 00:49, par François Daniel Giezendanner
Le site https://stats.spip.net est impressionnant concernant sa démarche, la nature et la richesse de l’information qu’il fournit ainsi que les formes sous lesquelles elles sont présentées. Depuis longtemps je me pose plusieurs questions le concernant :
– Qui est son auteur ?
– Dans quel langage est-il écrit ?
– Cet outil est-il original, spécifique à SPIP ou au contraire est-il inspiré/dérivé/adapté d’un type ou d’une famille d’outils existants ?
– S’il est original, spécifique à SPIP, il me semble que son adaptation à d’autres CMS, à d’autres outils serait utile, est-ce envisagé ?
– Comment fonctionne-t-il au plan de l’exploration du web et de la collecte des données ? est-il possible d’en faire une description « accessible » à des non-spécialistes ?
Cordialement
FDG
28 mai 2018, 13:10, par b_b
Salut,
La communauté SPIP, sur une idée originale de Cédric :)
PHP
C’est un outil développé par nos soins, le code est dispo sur la zone :
https://zone.spip.org/trac/spip-zone/browser/_dev_/univers_spip/
Libre aux personnes qui le souhaitent d’utiliser le code de l’outil, il est diffusé sous licence GPL :)
Je crois que le sujet a déjà été abordé sur les listes, il faudrait rechercher de ce côté.
1er juin 2018, 18:37, par James
D’autres recettes pour Docker :
11 juillet 2018, 12:57, par tetue
Chouette article, qui donne un peu de hauteur de vue en prenant du recul, merci Monsieur James !