- Publié le 01 Mai 2007 à 23:31
Voici un court complément à mon billet du 23 janvier concernant l'installation d'AWStats en mode CGI sous Ubuntu . Avec la méthode que j'exposais tout fonctionne très bien, la seule chose ennuyeuse concerne les mots clés tapés dans les moteurs de recherche. En effet, de plus en plus de moteurs utilise UTF-8 ce qui fait que l'URL référente envoyée par le navigateur est elle aussi en UTF-8. Or par défaut AWStats semble traiter les URL en ISO-8859-1 ainsi dans les statistiques au chapitre Phrases clés on voit apparaître "fond d écran" au lieu de "fond d'écran" ou bien "parc de la tête d or" au lieu de "parc de la tête d or". Avec un peu d'entraînement on arrive rapidement à lire l'UTF-8 mais ce n'est pas très pratique et puis j'aime bien sélectionner certaines phrases clés et les rechercher dans Google avec juste un clic droit dans Firefox et là forcément cela fonctionne moins bien.
Il existe une méthode pour contourner ce problème, pour cela, il suffit d'activer le plugin decodeutfkeys dans le fichier de configuration d'AWStats en décommentant (enlever le # en début de ligne) la ligne suivante dans le fichier /etc/awstats.votresite.fr.conf
LoadPlugin="decodeutfkeys"
Comme l'indique le commentaire dans le fichier de configuration, il faut aussi installer les modules Perl Encode et URI::Escape pour cela, il suffit de taper :
sudo apt-get install liburi-perl
Il n'est pas nécessaire de regénérer les statistiques, les mots clés présentés par AWStats devraient maintenant être affichés correctement.
- Publié le 01 Mai 2007 à 14:39
J'ai remarqué que sur plusieurs sites que la table ezsession chargée de stocker les données de session dans eZ Publish n'est jamais nettoyée, les données de session expirée s'accumulent. Selon la fréquentation du site, on obtient à plus ou moins long terme une table avec des millions d'enregistrements ce qui provoque au choix des ralentissements, des vérifications (mysqlcheck ) interminables, des problèmes pour faire les backups (mysqldump de plusieurs gigas) voire carrément une corruption de la base de données. J'ai d'ailleurs rapporté ce bug il y a quelques temps en proposant un script de 8 lignes (dont 4 inutiles...:-) à lancer via le système de cronjobs d'eZ Publish . Je ne suis visiblement pas le seul à avoir rencontré ce problème. Dans un fil du forum sur le même sujet , Xavier Dutoit propose d'utiliser le script update/common/scripts/cleanup.php pour supprimer les sessions expirées. Markus Bader a créé l'extension Session Cleanup pour régler ce problème.
Mais quel est la vraie origine de ce problème ? Richard Bayet apporte la lumière sur ce problème en citant un commentaire de la documentation PHP officiel sur une spécificité de Debian . Pour résumer, eZ Publish intègre son propre gestionnaire de session pour stocker les données en base plutôt que dans des fichiers. Or, sous Debian et dérivés, le nettoyage (Garbage collector) des anciennes sessions est assurées par un script shell lancé régulièrement par cron plutôt que par la fonction gc définit avec session_set_save_handler pour plus de sécurité dans l'utilisation du gestionnaire par défaut qui travaille avec des fichiers. Évidemment ce script est incapable de supprimer les sessions en base... Le lancement d'un script spécifique de manière asynchrone est donc nécessaire pour Debian et dérivés. Tout s'explique donc.
- Publié le 30 Avril 2007 à 00:09
À chaque fois que je développe avec eZ Publish , j'ai toujours besoin des mêmes ressources et malgré une utilisation intensive des favoris del.icio.us c'est toujours un peu fastidieux pour retrouver facilement la vingtaine de liens " les trucs pour le développement avec eZ Publish que j'oublie toujours". Je me suis donc fait une page Liens développements eZ Publish avec les liens que j'utilise presque quotidiennement vers les forums , eZpedia , la documenation eZ Publish , ... C'est très orienté " pense-bête pour ma petite tête" mais si d'autres ont la même petite tête trouée que moi :-)
