A l'origine, l'historique permettait de voir les affichages des pages category.php et picture.php (qui ne s'appellaient pas ainsi, mais qu'importe). Pour une galerie à usage familial, cela convenait parfaitement. Mais PhpWebGallery est parfois utilisé sur des sites communautaires avec de nombreux utilisateurs impliquant de nombreuses visites. Dans ce cas, l'historique était devenu trop verbeux, inutilisable. C'est ainsi que la branche 1.4 a fait disparaître les détails des visites au profit d'un résumé graphique accompagné d'un tableau.

De nombreux utilisateurs regrettent cette regression fonctionnelle. C'est ainsi qu'un MOD a vu le jour pour la branche 1.4 (ainsi que pour la branche 1.5) pour réafficher l'historique détaillé. Ce MOD est possible car, bien que l'affichage détaillé a disparu, les informations détaillées continuent à être stockées.

Revenir au niveau de fonctionnalité de la branche 1.3 est intéressant, mais on peut faire beaucoup mieux. La présentation de l'historique doit permettre de répondre à des question plus précises que “Quelle est la liste des pages visitées dans les 3 derniers jours”. L'historique présenté dans PhpWebGallery doit avoir une valeur ajoutée certaine par rapport à l'analyse des fichier de log du serveur web.

La table “history” stocke une liste complète des visites des pages category.php et picture.php. L'information est intéressante, mais elle prendrait tout son sens en introduisant la notion de visite. Une visite est associée à une utilisateur donnée (une IP dans le cas de l'utilisateur invité), a une date de début et on cherche la date de fin en fonction d'un “timeout”.

Par exemple, si le “timeout” est fixé à 10 minutes, si l'utilisateur attend plus de 10 minutes pour afficher une page dans la galerie depuis sa dernière page affichée alors il s'agit d'une nouvelle visite. Cette information ne doit pas être calculée lors de l'insertion des lignes dans la table “history” (car temps de calcul inutile pour le visiteur).

En introduisant la notion de visite, on envisage de lister les visites des utilisateurs dans ce qu'on nommera ensuite la “liste condensée”. A chaque visite, on associe donc un utilisateur, une date de début, une date de fin, le nombre d'images visitées, le nombre de catégories visitées.

• pour une date/période données
  • liste complète
  • condensée
• pour une image donnée
  • liste des utilisateur l'ayant visitée, combien de fois (de telle date à telle date)
  • liste complète sur une date/période
• pour un utilisateur donné (pouvoir choisir une IP particulière, une liste d'IP, ou n'importe quelle IP)
  • liste complète sur une date/période
  • liste condensée des visites
• pour une catégorie donnée
  • liste complète

Période : il doit être possible de fournir une date de début, une date de fin. Chaque date pouvant aller de l'imprécis (l'année) au très précis (la seconde).

Evidemment, toute la puissance de l'interface viendra de la possibilité de combiner les critères : sur la page de l'hitorique d'une image, la ligne de l'utilisateur user1234 sera liée à l'historique détaillé de l'image pour user1234 disant à quelle dates user1234 a visité l'image. Autre exemple, sur une liste condensée, une ligne (une visite) pointera vers la liste complète des pages affichée lors de la visite (Big Brother is watching you).

Dans sa version actuelle (branche 1.5), la table “history” a une tendance certaine à l'obésité. Obligeant les administrateurs à la purger régulièrement (perdant du même coup les informations…). Parce qu'obèse, non indexée, et lignes de taille variable, les requêtes sur cette tables sont longues. La table “history” contient essentiellement des redondances d'informations :

• au lieu de stocker l'identifiant de l'utilisateur, on stocke son nom d'utilisateur (varchar 15)
• au lieu de stocker l'identifiant de l'image, on stocke son nom de fichier (varchar 150)
• au lieu de stocker l'identifiant de la catégorie, on stocke son nom (varchar 150)

Ces redondances permettent d'assurer la pérennité de l'historique : en effet, si l'utilisateur 1234 est supprimé, que faire de son historique ? Le supprimer ? (non, car on ne change pas l'histoire). En conservant son nom d'utilisateur, on peut garder un historique lisible même en rapport avec des données de fonctionnement (images, catégories, utilisateurs) ayant disparu.

Afin de limiter la surcharge pondérale de la table “history”, il est pourtant nécessaire d'utiliser les identifiants des données de fonctionnement (user_id, image_id, category_id). Il s'agit de données numérique simples, courtes (mediumint 8 au maximum). L'identifiant de catégorie ne permet de stocker que les catégories normales, pas les catégories spéciales (most_seen, best_rated, search, favorites, etc.). Or, cette information présente de l'intérêt. Il est inutile de prévoir un champ de type char qui occuperait inutilement de la place, un champ de type enum conviendra parfaitement tout en occupant un minimum de place. Pour améliorer les performances, il est préfèrable que chaque ligne occupe un volume fixe (et minimal). Le seul champ qui reste est l'adresse IP, stockable en char 15.

CREATE TABLE phpwebgallery_history (
  date datetime NOT NULL,
  user_id smallint(5) UNSIGNED NOT NULL,
  IP char(15),
  category_type enum('numeric','most_visited','best_rated','favorite','recent_pics') NOT NULL DEFAULT 'numeric',
  category_id smallint(5) UNSIGNED,
  image_id mediumint(8) UNSIGNED
);

Ce qui donne par ligne, en octets : 8 (date) + 15 (IP) + 2*2 (user_id, category_id) + 1 (category_type) + 3 (image_id) = 31 octets fixes. Ce qui est très peu en comparaison des 423 maximum pour la version actuelle.

Le champ category_id n'est obligatoire que lorsque category_type vaut “numeric”.

REMARQUE (05/05/2008): Depuis la montée de version de MySQL sur les serveurs FREE.FR, cette fonctionnalité est INTERDITE par FREE. Surement à cause du problème de taille signalée. En tout cas, tout site qui utilise cette option chez FREE.FR risque de voir son compte bloqué. Pas trés sympa chez FREE.FR, aprés vous avoir bloqué le compte la première fois et ou il faut s'engager à ne plus utiliser l'historique sous peine de se voir bloqué en permanence, ils détruisent carrément le fichier dans votre base SQL, ce qui génére ensuite des messages d'erreur dans l'interface !…

Les colonnes de cette table méritent presque toutes d'être indexées . Enfin, les colonnes user_id et image_id semblent être les meilleures candidates.

La notion de visite, pour être exploitée efficacement, pourrait être stockée dans une colonne supplémentaire de la table “history”. Cette colonne serait remplie par calcul dans l'interface administration lors de l'affichage de l'historique, uniquement pour les lignes n'ayant pas encore été calculée. Cette partie reste délibéremment vague, à discuter.

Cette fonctionnalité est initialement prévue pour la branche 1.6.

• refonte de l'historique, éthique et anonymat
• Refonte des historiques... : assurer la pérennité des données de l'historique.