Hop,
Hello Bruno,
Oops. Du coup il faudrait que je l'ajoute manuellement dans les autres fichiers ?
Concernant la mise à disposition sur la branche stable, je l'ai fait car la fonction étant par défaut à on, ça ne changera rien pour l'utilisateur. Après si vous souhaitez l'exclure des branches stables, je peux revert mon commit sur ces branches 
Salut,
Hello Bruno,
Oops. Du coup il faudrait que je l'ajoute manuellement dans les autres fichiers ?
Hmm, je ne pense pas, amha il ne faut pas introduire la nouveauté en question dans la branche 3.0, un revert s'impose.
Concernant la mise à disposition sur la branche stable, je l'ai fait car la fonction étant par défaut à on, ça ne changera rien pour l'utilisateur. Après si vous souhaitez l'exclure des branches stables, je peux revert mon commit sur ces branches
Tu peux laisser le commit sur la branche 3.2 (trunk) et 3.1, en espérant que nos ami⋅e⋅s les trads auront le temps d'avancer sur la nouvelle chaîne d'ici la prochaine release 3.1.x.
Merci d'avance 
Salut,
Hello Bruno,
Oops. Du coup il faudrait que je l'ajoute manuellement dans les autres
fichiers ?Hmm, je ne pense pas, amha il ne faut pas introduire la nouveauté en
question dans la branche 3.0, un revert s'impose.
Je suis du même avis :
la branche 3.0 est une branche de maintenance.
Tant qu'on ne fonctionne pas avec un outil plus souple de type git, toute
nouvelle fonctionnalité doit être mise en place sur la version de
développement (3.2)
Concernant la mise à disposition sur la branche stable, je l'ai fait car
la fonction étant par défaut à on, ça ne changera rien pour l'utilisateur.
Après si vous souhaitez l'exclure des branches stables, je peux revert mon
commit sur ces branchesTu peux laisser le commit sur la branche 3.2 (trunk) et 3.1, en espérant
que nos ami⋅e⋅s les trads auront le temps d'avancer sur la nouvelle chaîne
d'ici la prochaine release 3.1.x.Si la chaine de langue n'est pas traduite, c'est la version francophone
qui apparaitra.
Tu peux changer le référentiel via la constante _LANGUE_PAR_DEFAUT.
Merci à l'équipe de dev pour avoir répondu, à ce sujet, à ma demande
Hello,
Il y a un autre souci dans ce commit.
D’où vient la meta $GLOBALS[‘meta’][“activer_referers”] ?
Hello,
J’ai reverté la branche de maintenance.
Par contre, Eric, pour la notice, je passe exactement comme par les autres : par le pipeline configurer_liste_metas.
Donc si je ne me trompe, la seule possibilité d’avoir cette notice, c’est quand on est pas passé par la page Gestion des plugins après un upgrade, non ? En tout cas, pour les autres metas du plugin, il n’y a pas de gestion avec des isset vu que ça passe par ce pipeline.
Je sais pas trop mais j’ai du aller dans la config et enregistrer la config pour que la notice disparaisse.
Mais bon un isset ne serait pas inutile la question que je me pose est si la meta n’existe pas est ce que la fonction est activée ou désactivée ?
Bruno Bergot a écrit le 24/05/2016 à 10:50 :
Hop,
Ajout d’une fonction aux statistiques pour désactiver les referers.
Des fois, on en a pas besoin, et ça prend de la place (beaucoup !)
dans les tables SQL.Details: Connexion · GitLab
Gros BUG avec ce patch sur une installation existante :
J'ai voulu aller dans les stats des referers de la veille juste après l'installation.
Et SPIP m'a répondu que je n'avait pas accès à la page !
Il m'a fallu passer par : Pyrat.net – Création de sites Internet
Et faire juste valider pour que la valeur par défaut de la case à cocher sur les referer soit *enregistrée*.
Bref, pas tout à fait au point ce commit !
Merci de corriger la prise en compte de la valeur par défaut quand elle n'est pas enregistrée dans spip_meta.
RealET a écrit le 30/05/2016 à 00:27 :
Merci de corriger la prise en compte de la valeur par défaut quand elle
n'est pas enregistrée dans spip_meta.
En pratique tu utilises une écriture plutôt dépréciée :
$GLOBALS['meta']["activer_referers"]
alors qu'il faudrait faire :
lire_config('activer_referers', 'oui');
Un plugin statistiques_objet a été commité récemment par Tcharls
http://zone.spip.org/trac/spip-zone/browser/plugins/statistiques_objets/trunk
et il me souvient que son auteur le considére pleinement opérationnel.
Ne faudrait il pas intégrer (|ce qu'offre) ce nouveau plugin, plus polyvalent,
et qui rapproche l'interface privé du full objet-id_objet ?
JLuc
Je rebondis sur le sujet (boing).
L'objet du plugin statistiques_objets, c'était effectivement de tester dans un plugin séparé la prise en charge des statistiques sur tout type d'objet, avant pourquoi pas de reporter ça "proprement" dans le plugin de la dist si ça convient à tout le monde.
Il est opérationnel, sauf les fonctions d'archivage qui n'ont pas été portées.
De mon côté, il est en production sur un site avec ~1500 visites jours, les statistiques étant activées sur les articles + un objet maison, et ça marche correctement.
Évidemment, sur un site à fort traffic, ça risque d'accentuer le problème des tables de statistiques qui prennent une taille démesurée avec le temps.
Il faudrait des retours sur plusieurs sites pour voir ce que ça donne.
Il y a un point sur lequel je ne suis pas sûr : le plugin enregistre les données dans 2 nouvelles tables statistiques_objets et referers_objets SAUF pour les articles, pour qui j'ai conservé les fonctionnement actuel avec les tables statistiques_articles et referers_articles.
Mais ça complique un peu le code et ça éparpille les données, dans ce cas je ne sais pas ce qui est préférable : tout basculer dans les nouvelles tables, ou garder cette dichotomie (pour rétrocompatibilité ?).
Plop.
Hello,
tcharlss a écrit :
Mais ça complique un peu le code et ça éparpille les données, dans ce
cas je ne sais pas ce qui est préférable : tout basculer dans les
nouvelles tables, ou garder cette dichotomie (pour rétrocompatibilité ?).
ne pas casser le fonctionnement du core, et surtout éviter de perdre les stats si l'on doit désactiver le plugin ultérieurement parcequ'il génère des problèmes de perf ou autre est un gros plus.
De ce point de vue c'est bien de garder en l'état. Mais ça veut dire aussi qu'on ne bench pas le problème de perf principale, puisque la table la plus grosse et la plus historique ne passe pas en objet/id_objet, ce qui est le soucis de perf potentielle.
Peut-être il faudrait que le plugin fasse un double enregistrement : dans la nouvelle table et dans la table historique. Ça te permet d'avoir le code simplifié partout, sauf au niveau de l'enregistrement, et de tester les tables objets avec des données réelles (en faisant du coup un import depuis les tables historiques lors de l'installation)
Pour le problème de taille des données, c'est en général les tables des visites_articles et referers_articles qui explosent avec le temps, et c'est une combinaison de :
- le temps (chaque jour un nouvel enregistement)
- le nombre d'article en base (chaque article a potentiellement un enregistrement) (et donc par extrapolation le nombre et le type d'objet dont tu vas suivre les stats)
- les visites effectives (chaque article qui a au moins une visite provoque un enregistrement)
- les liens entrant/le referencement du site (chaque referer cliqué vers un article provoque un enregistrement)
Il est sur que si on veut tester un peu sérieusement il faudra le mettre en place sur un site comme contrib, a condition d'avoir une reprise de l'historique pour ne pas devoir attendre 10 ans, et que ce soit reversible.
(mais a court terme je n'ai pas du tout le temps de regarder ça)
Ce n'est un problème que si il y a des infos inutiles, sinon, il "faut ce qu'il faut" !
Car les objets sont des "articles" avec un petit truc en plus ou en moins, et réciproquement ;
et quand on fait un "objet", c'est seulement qu'on préfère ne pas détourner les "articles",
mais qu'il y ait objet ou pas, si on veut les stats, il est normal qu'il y ait des données de stat enregistrées.
Autrement dit : ne pas disposer des stats sur les objets est une fausse solution pour alléger les tables.
C'est un peu comme dire "on ne va enregistrer les stats que pour les articles dont l'identifiant est impair".
Je n'ai donc pas l'impression que la question du volume des tables
change avec l'introduction des stats sur les objets.
Ce qui compte, ça semble être de pouvoir n'enregistrer que ce qu'on veut,
et donc pouvoir paramétrer quels objets sont suivis ou pas suivis.
JLuc
Et de pouvoir archiver et nettoyer finement les choses passées, y compris automatiquement :
- pouvoir télécharger les stats d'une période données pour un objet donné (et pour tous les objets à la fois aussi)
- pouvoir supprimer manuellement les stats d'une période donnée pour un objet (et pour tous les objets à la fois)
- pouvoir programmer la suppression automatique (et pourquoi pas l'archivage avant dans un fichier) des stats plus vieilles que XX mois ou années pour un objet ou pour tous les objets
Ce qui permet alors d'alléger régulièrement les tables SANS devoir requêter dans SQL.
(Ya le même problème pour les stats de vues et de clics du plugin Campagnes, il faudra que je m'y attelle un jour. Ça devient énorme et ça fait ramer au bout de plusieurs années en place.)