Ci-joint un petit patch pour trois petits problèmes concernant la page
"statistiques des visites", section "origine des visites", et la page
"statistiques (liens entrants)". Je l'ai créé à partir de SPIP 2.0.11,
mais il s'applique aussi à SPIP 2.1.0.
Je commence par le bas. La 3ème modification consiste à rajouter un
else oublié et corrige le (mini) bug que certaines visites comptaient
"double".
La 2ème modification est surtout pertinente pour la section "origine
des visites" de la page "statistiques des visites". J'avais remarqué
que les comptes n'étaient visiblement "pas mis à jour". C'est parce que
la requête ne garde que les 100 ($limit) premières lignes, rangées par
nombre de visites décroissant. Je propose de les ranger par date
décroissante. Le tri par ordre décroissant de nombre de visite est de
toute façon refait plus bas, après agrégation par host (arsort
($nbvisites)).
Enfin la première modification n'est pas parfaite, mais elle est
toujours meilleure que l'état actuel. Le test ($n == $limit) compare le
nombre maximal de visites renvoyées à un nombre de hosts après
agrégation, donc s'évalue presque toujours à faux. Je propose de
toujours afficher le lien "+++" : c'est très souvent correct et ce n'est
pas grave quand ce ne l'est pas. En attendant une solution plus exacte
(demander $limit+1 lignes, ne garder que les $limit premières et
conserver l'info de la présence ou non d'une $limit+1ème ligne, pff)...
"Daniel Déchelotte" <maitre_yodan@fr.club-internet.invalid> wrote in message
news:20100608222906.fc431f6a.maitre_yodan@fr.club-internet.invalid...
Ci-joint un petit patch pour trois petits problèmes concernant la page
"statistiques des visites", section "origine des visites", et la page
"statistiques (liens entrants)". Je l'ai créé à partir de SPIP 2.0.11,
mais il s'applique aussi à SPIP 2.1.0.
À partir de la 2.1, elles sont en extension dans SPIP [1]. Si tu as un
compte sur la zone[2], tu peux donc appliquer toi-même cette partie de
ton patch, si tu le souhaites.
[1] Plugin statistiques :
[2] Présentation de la Zone :
La 2ème modification [...]
Enfin la première modification [...]
Suite au retour de bug de Suske sur spip-dev, je pense qu'il faudrait
tirer les choses au clair avant d'appliquer ces deux-là.
À partir de la 2.1, elles sont en extension dans SPIP [1]. Si tu as un
compte sur la zone[2], tu peux donc appliquer toi-même cette partie de
ton patch, si tu le souhaites.
Non, c'est à partir de 2.2.
En 2.1, elles sont toujours dans le Core
Sauf que _a fait sauter les referers: je n'ai plus droit qu'_ "??"
au lieu des termes recherch_s (mais le lien est l_)
Merci d'avoir testé le patch. Pour ton problème, euh, tu es sûr que
c'est à cause de mon patch ? O:-) Tu as essayé avec quelle version de
SPIP ?
Parce que d'une part, chez-moi-ça-marche ®, et d'autre part, les trois
changements ne devraient pas pouvoir avoir cette conséquence (mais je
manque peut-être d'imagination). Le premier revient à toujours afficher
le lien "+++" => pas d'impact sur la liste. Le deuxième change la liste
des referers retournés : au lieu des 100 plus importants "de tous les
temps", on renvoie les 100 derniers. Ca peut ramener des referers
"obscures", mais ça ne devrait pas gêner l'analyse des referers des
Google et autres Bing. La troisième modif corrige quelques comptes,
mais ne doit pas modifier l'analyse des URLs.
Merci d'avoir testé le patch. Pour ton problème, euh, tu es sûr que
c'est à cause de mon patch ? O:-) Tu as essayé avec quelle version de
SPIP ?
Sur ? Non... Mais j'enlève le patch, vide la cache et j'ai des stats
foireuses avec les details des referers corrects... Je le remets: j'ai "??"
qui pointe sur les liens. Faut que je désactive les plugs, un par un pour
voir peut-être ou essayer sur d'autres sites. je reviens quand j'ai plus de
détails. Pas le temps là :-/
Tu confirmes le souci chez toi ?
Donc oui, mais c'est vrai que c'est un vieux site avec probablement des
vieux fichiers qui trainent et plein de plugins, donc... Je reviens....
* Daniel Déchelotte tapuscrivait, le 08/06/2010 22:29:
Enfin la première modification n'est pas parfaite, mais elle est
toujours meilleure que l'état actuel. Le test ($n == $limit) compare le
nombre maximal de visites renvoyées à un nombre de hosts après
agrégation, donc s'évalue presque toujours à faux. Je propose de
toujours afficher le lien "+++" : c'est très souvent correct et ce n'est
pas grave quand ce ne l'est pas. En attendant une solution plus exacte
(demander $limit+1 lignes, ne garder que les $limit premières et
conserver l'info de la présence ou non d'une $limit+1ème ligne, pff)....
En plus de la page ecrire/?exec=statistiques_visites
est-ce que ecrire/?exec=statistiques_referers n'a pas le même besoin des +++ ?
Non, c'est à partir de 2.2.
En 2.1, elles sont toujours dans le Core
Bien vu. Reporté en 2.1.
Du coup, lorsqu'on demande les statistiques d'un article particulier :
ecrire/?exec=statistiques_visites&id_article=54
une erreur MySQL est affichée :
Erreur SQL 1054
Unknown column 'date' in 'order clause' SELECT referer_md5, referer, visites AS vis FROM `mutu_artisana66c3`.spip_referers_articles WHERE id_article=54 ORDER BY date DESC LIMIT 100
SELECT referer_md5, referer, visites AS vis FROM spip_referers_articles WHERE id_article=54 ORDER BY date DESC LIMIT 100
Du coup, lorsqu'on demande les statistiques d'un article particulier :
ecrire/?exec=statistiques_visites&id_article=54
une erreur MySQL est affichée :
Erreur SQL 1054
Unknown column 'date' in 'order clause' SELECT referer_md5, referer,
visites AS vis FROM `mutu_artisana66c3`.spip_referers_articles WHERE
id_article=54 ORDER BY date DESC LIMIT 100
En effet, la table spip_referers_article n'a pas de champ "date", seule
"spip_referers" en a une. En revanche, les deux ont un champ "maj" mais
il ne contient pas la même valeur que pour "date".
Je ne connais pas assez le fonctionnement des stats pour juger de la
modification la plus pertinente à apporter. Il faudrait que Daniel nous
dise si son patch peut être adapté en remplaçant "date" par "maj" (ou
quelqu'un qui connaisse le système des stats... mais tout le monde est
resté silencieux depuis la proposition du patch puis son application...
c'est inquiétant).
À défaut de réponse bientôt, il faudra annuler les commits 15795 et
15796.
21/06/10, RealET:
> Du coup, lorsqu'on demande les statistiques d'un article
> particulier [...] Unknown column 'date' in 'order clause' [...]
En effet, la table spip_referers_article n'a pas de champ "date",
seule "spip_referers" en a une. En revanche, les deux ont un champ
"maj" mais il ne contient pas la même valeur que pour "date".
Je ne connais pas assez le fonctionnement des stats pour juger de la
modification la plus pertinente à apporter. Il faudrait que Daniel
nous dise si son patch peut être adapté en remplaçant "date" par
"maj"
Je crois deviner en regardant le code (ecrire/genie/visites.php) que la
colonne "date" contient le jour de la création de la ligne (le referer)
et "maj" est un timestamp de la dernière modification de la ligne. Donc
oui, remplacer "date DESC" par "maj DESC" me parait raisonnable, c'est
même complètement dans l'esprit de "retourne moi ce qui ressemble le
plus possible aux n derniers referers".
Ceci dit, j'ai des états d'âme... Avec "maj DESC", on obtient les 100
derniers referers, triés par fréquence cumulée depuis le début des
collectes de statistiques. Un peu bizarre... Le "vis DESC" initial est
plus cohérent. Je laisse quand même dans le patch ci-joint "maj DESC",
parce ça rend la page AMHA plus intéressante car plus actuelle.
Par ailleurs, RealET a écrit :
En plus de la page ecrire/?exec=statistiques_visites
est-ce que ecrire/?exec=statistiques_referers n'a pas le même besoin
des +++ ?
Si, complètement. Ca a d'ailleurs permis de corriger 2 typos : c'est
visiblement la toute première fois que ce lien +++ est affiché
Patch ci-joint, à appliquer après mon premier patch.
Attention, dans SPIP les champs "maj" sont auto-modifiés à chaque mise à jour d'un enregistrement en base de l'objet en question (c'est une déclaration de MYSQL qui fait que les champs de type TIMESTAMP sont automatiquement renseignés, même si on n'en parle pas dans la requête de mise à jour ou d'insertion. C'est même pourquoi sous PG et SQLite, nous avons appliqués aux champs 'maj' le même équivalent).
Donc, je ne sais pas ce que vous souhaitez réellement (je n'ai pas réellement suivi la discussion) mais un champ 'maj' est mis à la date de dernière modif, dès lors qu'on modifie ou insère l'enregistrement.
> oui, remplacer "date DESC" par "maj DESC" me parait raisonnable,
Attention, dans SPIP les champs "maj" sont auto-modifiés à chaque
mise à jour d'un enregistrement en base de l'objet en question [...]
Je confirme que je suggérai de passer à "maj DESC" en connaissance de
cause (cf ma phrase « "maj" est un timestamp de la dernière
modification de la ligne. »)
PS: j'utilise la passerelle gmane pour suivre spip-dev sans charger ma
boîte mail ; il n'est donc pas nécessaire de me mettre explicitement en
copie. Si nécessaire, je suis joignable avec maitre_yodan(chez)
club-internet.fr.
Ceci dit, j'ai des états d'âme... Avec "maj DESC", on obtient les 100
derniers referers, triés par fréquence cumulée depuis le début des
collectes de statistiques. Un peu bizarre... Le "vis DESC" initial est
plus cohérent. Je laisse quand même dans le patch ci-joint "maj DESC",
parce ça rend la page AMHA plus intéressante car plus actuelle.
