je sais qu’on a je ne sais plus où une superbe page de stats qui montre la répartition des version de SPIP et des plugins utilisés, mais pas de leur évolution.
Comme modèle, je me réfère aux statistiques de Drupal (ceux de Wordpress sont à peut prêt équivalent)
La page de statistique est ici : http://stats.spip.org/
elle mentionne ceci : “Ce comptage est automatique. Il suffit que votre site soit en ligne et référencé pour être pris en compte.”
C’est presque aussi flou que le fonctionnement de Google ;).
Comment c’est calculé ? Peut-on ne pas être pris en compte ?
Plus que les chiffres, c’est aussi les tendances qui comptent : on peut les avoir ?
Je suis convaincu qu’on devrait virer ces stats (ou les réserver aux développeurs) et ne fournir publiquement que des statistiques fournies “volontairement” par les utilisateurs (chez Drupal c’est l’utilisation du service de mise à jour qui suppose l’acceptation de l’envoi public de tels statistiques).
Peut-on refaire le point sur les statistiques que nous avons actuellement sur SPIP et ses plugins ?
Ainsi que leur mode de calcul ?
Je parlerais juste des plugins.
Outre le site des stats dont tu parles et qui est alimenté automatiquement, les statistiques d’utilisation des plugins sont disponibles sur plugins.spip.net.
Ces informations sont fournies par le plugin SVP Statistiques qui utilise l’interface json du site de stats de SPIP.
Aujourd’hui ce plugin est très embryonnaire car il ne donne qu’une valeur instantanée d’utilisation sur l’ensemble des versions. Mais son but est de fournir à terme des statistiques plus pertinentes comme l’utilisation par branche majeure de SPIP et l’historique. Mais cela reste à coder.
je ne suis pas convaincu que ce soit ce mode de calcul : stats.spip.net indique qu’il a parcouru 34164 sites, et que 33599 ont le plugin cfg.
Sur plugins.spip.net on retrouve le chiffre de 33587, ce qui est presque pareil…
En conséquence, je vois bien ces statistiques de plugins continuer à être présentées sur plugins.spip.net.
Oui c’est une très bonne chose.
Mais l’évolution est aussi une donnée intéressante : elle montre aussi la maturité d’un plugin, sa compatibilité selon les versions, et sa popularité.
Le type de question qui m’est souvent posée c’est « est-ce que ce squelette/plugin est maintenu ? » ou « est-ce qu’il est vraiment utilisé ? »
je ne suis pas convaincu que ce soit ce mode de calcul : stats.spip.net indique qu’il a parcouru 34164 sites, et que 33599 ont le plugin cfg.
Sur plugins.spip.net on retrouve le chiffre de 33587, ce qui est presque pareil…
Ben si je te le dis c’est que je sais comment SVP Stats est fait.
La différence s’explique par le fait que la mise à jours de stats sur plugins.spip.net est périodique (7 jours) et n’est pas forcément synchro avec celle de stats.spip.org
En conséquence, je vois bien ces statistiques de plugins continuer à être présentées sur plugins.spip.net.
Oui c’est une très bonne chose.
Mais l’évolution est aussi une donnée intéressante : elle montre aussi la maturité d’un plugin, sa compatibilité selon les versions, et sa popularité.
Oui c’est ce que je t’ai dit : SVP Stats est prévu pour accepter des historique de stats mais il faut le coder. A partir de ce moment on sera capable de l’afficher sur plugins.spip.net.
un plugin qui generalise top10 pour construire une base statistique des sites sous spip Les sites sont recherches dans : - le RSS des sites sous spip - le RSS twitter sur la recheche « spip » - le RSS google news sur la mot cle « spip » - le RSS delicious des sites sous sarka - le RSS identica sur le mot cle « spip » - les recherches d’url spip.php?page=xxx caracteristiques d’un site SPIP, par l’API BOSS ou autre chaine caracteristique d’un site sous spip - les referers du site
Ce mode de recrutement permet de trouver tous les sites visibles et vivants, avec un biais de recrutement car spip.php n’existe que depuis SPIP>=1.9, d’ou le peu de sites sous SPIP <1.9 dans les stats Il n’y a pas de mecanisme manuel de declaration de site, la petition de spip.net suffisant pour cela Les sites recrutes sont enregistres en statut propose
Un genie scanne chaque site, pour verifier qu’il s’agit bien d’un site sous SPIP, et recuperer des infos statistiques : - IP - version de SPIP, avec plusieurs solutions de detection quand le header n’est pas present - version de PHP - plugins installes
L’IP est utilisee pour determiner le pays d’hebergement via l’api GeoIP maxmind le plugin embarque la version gratuite et GPL de la base IP de maxmind : Geolite http://www.maxmind.com/app/geolitecountry
Par contre, la page de stats indique que 4003 sites ont refusés de répondre à la requete. Comment est-ce que ce chiffre est calculé ?
Il y a donc un moyen (simple si possible) pour cela ?
je ne suis pas convaincu que ce soit ce mode de calcul : stats.spip.net indique qu’il a parcouru 34164 sites, et que 33599 ont le plugin cfg.
Sur plugins.spip.net on retrouve le chiffre de 33587, ce qui est presque pareil…
Ben si je te le dis c’est que je sais comment SVP Stats est fait.
La différence s’explique par le fait que la mise à jours de stats sur plugins.spip.net est périodique (7 jours) et n’est pas forcément synchro avec celle de stats.spip.org
ok
En conséquence, je vois bien ces statistiques de plugins continuer à être présentées sur plugins.spip.net.
Oui c’est une très bonne chose.
Mais l’évolution est aussi une donnée intéressante : elle montre aussi la maturité d’un plugin, sa compatibilité selon les versions, et sa popularité.
Oui c’est ce que je t’ai dit : SVP Stats est prévu pour accepter des historique de stats mais il faut le coder. A partir de ce moment on sera capable de l’afficher sur plugins.spip.net.
ok, je vais voir ce qui peut être fait côté stats.
Une idée pourrait être d’utiliser un grapheur externe de type munin ou autre, et de lui fournir les stats dans une forme qu’il puisse lire.
Ce qui me semble assez simple vu les possibilités de création de plugins pour munin
« 4004 Refusés » signifie « 4004 sites candidats ont été refusés après examen car il n’a pas été possible de prouver qu’il s’agissait bien d’un site sous SPIP »
Munin est un outils de graph, pas de logs :
il ne fait que générer des graphes sur différentes périodes à l’aide de rrd - et du coup les courbes qu’il génère prennent peu de place mémoire.
Ayant juste besoin de tendances et d’ordre de grandeur, ce type d’affichage me convient parfaitement.
Et un plugin munin est très simple à écrire…
Inconvénient majeur de mon approche, les données ne sont pas stockées sous forme réutilisable (enfin, pas à ma connaissance)
Oui j’ai pigé, c’était pas ma question.
Pourquoi ne pas utiliser jqFlot qui fait partie de SPIP via le plugin-dist Statistiques ?
jqFlot est une librairie javascript pour afficher des courbes. elle peut aller très bien mais il faut lui donner tous les points à afficher et autres paramètres pour le faire. Avec munin pas besoin : tu lui fournis juste un page sur laquelle s’affichent des valeurs, ainsi qu’un fichier pour qu’il puisse mieux les afficher. Ensuite il se débrouille tout seul. L’approche est complètement différente que SVP stats où on peut personnaliser l’affichage etc.
En ce sens ça n’apporte rien à SVP stats
chose étrange : à ma connaissance le squelette/plugin geek_maieul n'est utilisé que par un site (http://geekographie.maieul.net), mais il est affiché comme utilisé 2 fois sur http://stats.spip.org . Des pb d'URL canoniques ? Valable aussi d'ailleurs pour blog_maieul
