Remplacer la fonction PHP htmlentities ? (Créer un compte)

Ce que je veux dire c’est que les particuliers qui comme moi ont installé un site non professionnel préfèrent passer du temps à bidouiller comme je le fais qu’à payer pour un site qui ne rapporte presque rien.

Pour les entreprises, évidemment, le problème n’est pas le même, elles ont tout intérêt à installer des plugins fiables, mais là, il faut mettre le prix.
Les plugins en téléchargement sont pour la plupart écrit par des amateurs (à part celui que je tente d’améliorer, le concepteur du plugin est un professionnel de l’informatique Italien). Il s’en sert de vitrine…

Je passe mon temps libre à apprendre d’abord le SQL, puis le PHP et à me documenter sur WordPress, j’apprends beaucoup de choses, il y a des problèmes intéressants à résoudre, c’est assez amusant de bidouiller…

Et heureusement qu’il y a des professionnels bien payé car c’est vraiment prise de tête les problèmes informatiques…

$debDate = ‘2011-07-01’;
$finDdate = ‘2011-07-20’;
$dates = array($debDate);
while ($debDate != $finDate) 
{
    $debDate = date(‘Y-m-d’, strtotime($debDate . ‘ +1 day’));
    $dates[$debDate] = 0;
} 

$qry = $wpdb->get_results
(« SELECT count($select) AS total, date
   FROM $table_name 
   WHERE  $where AND date BETWEEN $limitdate AND $currentdate
   GROUP BY date );

foreach ( (array) $qry as $row )
	$dates[$row[‘date’]] = $row[‘total’];

C’est déjà bien, mais je dois l’adapter au cas particulier du plugin. Le graphique affiche 4 tris en même temps au moyen de rectangles colorés (visiteurs uniques, pages vues, feeds et spider).
C’est pourquoi je me demande s’il ne vaudrait pas mieux faire un objet des différents critères de tri avec comme élément le tableau du nombre de visites quotidiennes.
Comme $dates->visitors[$debDate] = 0;
$dates->pagevues[$debDate]=0; etc

Ou alors un tableau de tableau ?

Qu’est-ce qui est préférable ?

Oui, c’est tout a fait cela, je n’ai rien changé à la version originale du plugin dans cette partie.

Ben, je ne sais pas si c’est possible ou pas et je connaît pas toutes les subtilités de MySQL, a priori je ne vois pas comment car une requête trie sur la condition WHERE qui elle doit être précise. Et comme ce WHERE est justement une condition sur les dates, cela reviendrait en PHP à faire un tri dans l’ordre chronologique inverse avec des points de stockage des informations aux frontières des intervalles de temps.

Je ne sais pas si cela est possible, peut être en utilisant les CASE, je vais continuer mes lectures des cours de SQL pour voir si c’est possible. Si c’est possible, c’est une très bonne idée.
déjà, dès que l’on passe de aujourd’hui à hier, il faut lors de ce passage, stocker le nombre d’aujourd’hui et ne pas refaire le même test à la deuxième lecture d’une entrée d’hier. Donc, il faut un test qui assure que la condition ne se remplie qu’une seule fois, au passage de aujourd’hui à hier et non pas une condition sur la date d’hier qui sera remplie à chaque lecture d’un enregistrement de la date d’hier.
C’est déjà plus difficile de trouver une condition qui n’est valable qu’au changement de date.

Bon, sinon, dans le case, je peux stocker à chaque lecture d’un enregistrement de la date d’aujourd’hui le total de celle-ci et des antérieures.
Lors du changement de date à hier, j’ajoute pour chaque lecture le total au nombre total d’hier.
etc
C’est peut-être possible, je vais devoir me taper les sites anglais, le CASE n’est pas bien référencé en français…

Mais ca va être galère quand aujourd’hui est le premier jour du mois et hier le dernier jour du mois précédent.
Dans ce cas, le total du mois en cours et du mois précédent est plus difficile à calculer.
Si hier et aujourd’hui sont dans le même mois, cela doit être faisable. S’il sont de mois différents, cela complique encore…Il va falloir donc faire les totaux du mois en cours et précédents en PHP, plus souple.

C’est celui-ci :
http://wordpress.org/extend/plugins/statpress-visitors/

Oui, c’est mieux, ces problèmes de tris sont vraiment prises de tête à faire en MySQL…