Mise en oeuvre du logiciel de Statistiques Web PIWIK

Université Nancy 2
MIAGE – Nancy
[RAPPORT DE STAGE]
Mise en œuvre du logiciel de
Statistiques Web PIWIK
Et création d’un greffon PDF
INSTITUT DE L’INFORMATION
SCIENTIFIQUE ET TECHNIQUE (INIST)
Réalisé par LAVAUX Jérémy
Année universitaire : 2009/ 2010
2
[RAPPORT DE STAGE]
LAVAUX Jérémy
Mise en œuvre du logiciel de
Statistiques Web PIWIK
Et création d’un greffon PDF
INIST -CNRS
2, allée du parc de Brabois
54519 VANDOEUVRE-LES-NANCY
•
Stage réalisé du 17 mai 2010 au 7 août 2010
•
Sous la tutelle de : M. LECHAUDEL Dominique et M. GULLY Stéphane:
Ingénieurs du département informatique et de M. NABONNAND
Philippe: Professeur à l’université
Année universitaire : 2009 / 2010
Université Nancy 2
MIAGE - Nancy
3
[TABLE DES MATIERES]
1 [REMERCIEMENTS].................................................................................................. 5
2 [INTRODUCTION].................................................................................................... 6
3 [L’ETABLISSEMENT].................................................................................................. 7
3.1 Présentation...........................................................................................................7
3.1.1 Localité............................................................................................................7
3.1.2 Les missions de l’INIST....................................................................................8
3.2 Le Département Informatique...........................................................................9
3.2.1 Introduction....................................................................................................9
3.2.2 Les missions du département......................................................................9
3.2.3 Les services...................................................................................................10
4 [REALISATION DU PROJET].................................................................................... 11
4.1 Le cahier des charges.......................................................................................11
4.1.1 PhpMyVisites.................................................................................................12
4.1.2 Les documents PDF.....................................................................................14
4.1.3 Le cahier des charges évolutif..................................................................15
4.2 Mise en place.....................................................................................................15
4.2.1 Etude de l’application................................................................................15
4.2.2 Technique de mesure d’audience..........................................................16
4.2.2.1 La notion de 'Tracker'.........................................................................16
4.2.2.2 La méthode du tracking...................................................................17
4.2.3 Mise en oeuvre.............................................................................................18
4.2.3.1 Pourquoi Piwik ?..................................................................................18
4.2.3.2 Installation à l’INIST.............................................................................18
4.2.3.3 Le site web de test..............................................................................20
4.2.4 Développement du greffon PDF..............................................................21
4.2.4.1 Contexte et démarche initiale.........................................................21
4.2.4.2 L’outil d’envoi par mail......................................................................22
4.2.4.3 Le greffon PDF.....................................................................................24
4.2.4.3.1 Créer un rapport.........................................................................24
4.2.4.3.2 Gérer la liste des rapports..........................................................26
4.2.4.3.3 Le rapport généré.......................................................................28
4.2.5 Script d’automatisation..............................................................................29
4.2.5.1 Introduction.........................................................................................29
4.2.5.2 Mise en place du script.....................................................................31
5 [CONCLUSION].................................................................................................... 33
6 [GLOSSAIRE]......................................................................................................... 34
7 [BIBLIOGRAPHIE].................................................................................................. 35
8 [ANNEXES]............................................................................................................ 36
4
1 [REMERCIEMENTS]
Je tiens tout d’abord à remercier la MIAGE et ses enseignants pour m’avoir permis
d’intégrer une réelle formation en informatique. J’ai pu notamment mettre à profit
mes acquis dans le monde du travail avec ce stage.
Je remercie M. NABONNAND Philippe, mon parrain, pour m’avoir apporté les
conseils et l’aide nécessaire au bon déroulement du stage en lui-même.
Au sein de l’entreprise, je remercie M. LECHAUDEL ainsi que M. GULLY, mes tuteurs,
pour m’avoir d’une part accepté au sein de l’établissement INIST-CNRS et d’autre
part pour le suivi du travail que j’ai réalisé.
En ce qui concerne le déroulement du stage, je voudrais aussi saluer les collègues du
‘Service étude et service en ligne’: M. LANDI Bruno et M. WACH Arnaud qui m’ont
donné des précisions sur le cahier des charges, le fonctionnement interne de l’entreprise, et qui m’ont également suivi tout au long de mon travail.
Je tiens également à remercier les membres des autres services du département informatique qui m’ont accompagné dans ce projet : M. COUCHET Pierre et M. TINTANET Cédric. Ils ont répondu à mes appels lors des phases de test de l’application. Je
tenais aussi à les remercier pour leur bonne humeur quotidienne.
Enfin, je remercierai ma famille qui m’a permis de réaliser ces études et ce stage.
Merci pour le soutien apporté.
5
2 [INTRODUCTION]
La licence MIAGE réalisée à l’UFR Mathématiques et Informatique de Nancy se déroule sur une période de trois ans et permet d’acquérir de solides bases, aussi bien
en informatique qu’en compétences générales. La validation s’effectue à la fin de
l’année scolaire par un stage de douze semaines en entreprise.
J’ai donc choisi de réaliser ce stage dans la fonction publique au sein de l’INIST-CNRS situé à Brabois. J’étais sous la tutelle de M. LECHAUDEL Dominique et M.
GULLY Stéphane, ingénieurs de recherche du département informatique.
Le travail au sein d’un institut public était pour moi une réelle découverte. En effet,
ayant déjà eu l’occasion de travailler durant la saison estivale dans des entreprises
privées, je souhaitais enrichir mes connaissances à travers un organisme tout à fait
différent. L’envie de découvrir un autre environnement, un climat social et d’autres
objectifs ont également su orienter mon choix. Enfin, le sujet était en adéquation
avec mes attentes puisque je souhaitais travailler sur un projet liant étude et développement.
Mon rapport de stage présentera donc mes douze semaines de stage au sein de
l’organisme. Je commencerai par une présentation de l’établissement ainsi que les
conditions de travail. Puis, je développerai le projet qui m’a été confié et les moyens
utilisés pour parvenir à mes fins. Enfin, je dresserai un bilan de l’ensemble des
connaissances apportées par ce stage autant sur le plan personnel que professionnel.
6
3 [L’ETABLISSEMENT]
3.1 Présentation
3.1.1 Localité
L’INIST-CNRS se trouve au numéro 2 de l’avenue du Parc de Brabois. Située à
quelques kilomètres de Nancy, sa situation offre de nombreux avantages. En effet, la
proximité de l’établissement avec le tram ou encore l’autoroute facilite l’accès des
employés à leur lieu de travail. Les nombreux restaurants ainsi que la cantine interne
permettent également aux salariés de se restaurer.
Figure 1 : Plan d’accès à l’institut de l’information
scientifique et technique (INIST).
7
3.1.2 Les missions de l’INIST
L’INIST est une unité de production et de service du CNRS. Avant de présenter
l’institut il convient donc de faire une brève présentation du CNRS.
Le Centre national de la recherche scientifique (CNRS) est un organisme public de
recherche. Cet établissement public à caractère scientifique et technologique est
placé sous la tutelle du Ministère de l'Enseignement supérieur et de la Recherche.
Avec plus de 32 000 personnes (dont 26 000 statutaires - 11 600 chercheurs et 14 400
ingénieurs, techniciens et administratifs), un budget 2010 de plus de 3 milliards d'euros, une implantation sur l'ensemble du territoire national, le CNRS exerce son activité
dans tous les champs de la connaissance, en s'appuyant sur plus de 1200 unités de
recherche et de service.
L'INIST est en charge de la collecte, du traitement et de la diffusion de l’Information
Scientifique et Technique auprès des chercheurs publics et privés, français et étrangers. Pour cela, l'INIST s’appuie sur l’une des plus importantes collections de publications scientifiques d’Europe.
L'INIST a pour but de faciliter l'accès aux résultats issus des différents champs de la recherche mondiale. Pour cela, l’établissement propose tout une gamme de services
de recherche d'information:
•
La fourniture de documents (environ 6000 clients)
•
Un outil de vente par correspondance (VPC) ‘Refdoc’  250 000 visites par
mois. (annexe 1)
•
Des bases de données bibliographiques (18 millions de références)
•
Des portails d'information permettant l'accès mutualisé à des ressources numériques.
8
3.2 Le Département Informatique
3.2.1 Introduction
Le
département
informatique
est
appelé
DSI
(département
des
systèmes
d’informations). Il représente un des sept départements qui composent l’INIST. Le
responsable du département est M. Laurent SAUDER.
Figure 2 : Les départements de l’INIST
3.2.2 Les missions du département
Le DSI est le garant de la cohésion du système d’information de l’unité. Ses missions
sont multiples:

Assurer la mise en place de solutions permettant de supporter la
production des différents départements utilisateurs

Maintenir les chaines informatiques de production

Faire évoluer le système afin de s’adapter aux besoins

Prendre en charge la veille technologique pour adapter la stratégie
informatique en conséquence
9
3.2.3 Les services
Afin de mener à bien ses missions, le département informatique est divisé en services.
Figure 3 : Les services du DSI
Les services du département exercent dans leurs domaines de compétences:
+ Exploitation  maintient la production (logiciels)
+ Serveurs et Réseaux  anticipe les évolutions techniques
+ Bureautique  gère les installations matérielles, le service messagerie
+ Chaine documentaire  gère les besoins applicatifs internes
+ Service en ligne  Développement et support d’application Web
L’ensemble du stage a été réalisé au sein du Service en ligne, composé de neuf
personnes, sous la tutelle de M. LECHAUDEL Dominique et de M. GULLY Stéphane,
tous deux exerçants en tant qu’ingénieurs de développement.
10
4 [REALISATION DU PROJET]
4.1 Le cahier des charges
Pour débuter le stage et bien comprendre son environnement, une visite des locaux
fut organisée par M. LECHAUDEL. Celle-ci incluait bien évidemment la présentation
du poste de travail où le stage serait effectué. Ce poste disposait d'un PC sous Windows XP et se situait dans la même pièce que celui de M. LECHAUDEL, M. LANDI et
M. WACH qui se proposèrent pour fournir quelques indications relatives au fonctionnement de la machine ainsi que du département informatique.
Suite à cela, un cahier des charges plutôt général fut établi. Afin de les étudier, les
logiciels libres de statistiques web PhpMyVisites et Piwik ont été présentés par M.
LECHAUDEL et M. GULLY puis quelques objectifs principaux ont été fixés. Le projet
pouvait en réalité se décomposer en deux grosses parties. Dans un premier temps, la
mission fut de mettre en œuvre le logiciel Piwik. Celui-ci devait permettre de
remplacer à terme le logiciel existant PhpMyVisites arrivant en fin de vie.
Dans un deuxième temps, il a fallu étudier et réaliser un prototype de greffon PDF.
Ce greffon devait permettre, à l’image de ce qui existe dans PhpMyVisites,
d’exporter des données statistiques au format PDF.
Enfin, l’objectif final était d’intégrer le greffon PDF dans le code source officiel du
logiciel Piwik.
11
4.1.1 PhpMyVisites
Grâce aux informations présentées sur le logiciel PhpMyVisites, l’étude de l’existant a
pu débuter. A l’heure actuelle, deux cent sites sont hébergés au sein de l’Inist. Afin
de mesurer l’audience de ces sites, plusieurs logiciels statistiques sont utilisés. On
recense une cinquantaine de sites suivis par PhpMyVisites, moins d’une vingtaine sur
Google Analytics et une dizaine sur l’outil AWStats.
Figure 4 : Exemple de statistiques sous PhpMyVisites
12
Pour étudier la mise en œuvre de Piwik, il fallait avant tout, comprendre son
fonctionnement et ses apports par rapport à PhpMyVisites. Suite à une faille de
sécurité du logiciel PhpMyVisites, l’équipe de développeur du logiciel libre a décidé
de cesser le développement et a souhaité repartir sur des bases plus solides. C’est le
point de départ du développement du nouveau logiciel Piwik qui reprend la même
équipe de développement que PhpMyVisites. Le leader du développement
Matthieu AUBRY est français.
Figure 4 : Exemple de statistiques sous Piwik
Nous verrons plus en détails la mise en œuvre de Piwik au sein de l’INIST dans la
partie 4.2.
13
La deuxième partie concernait la réalisation d’un greffon PDF permettant de
reproduire les fonctionnalités d’export des données en PDF présentes sur
PhpMyVisites dans Piwik. A l’heure actuelle Piwik est en phase de développement ce
qui explique que certaines fonctionnalités soient manquantes. La version utilisée lors
du développement était la 0.6
4.1.2 Les documents PDF
De manière périodique, à l’aide d’un script sur un serveur, les documents PDF sont
générés à partir de requêtes http sur PhpMyVisites. Ces documents PDF sont
sauvegardés sur le serveur et les utilisateurs intéressés peuvent venir les consulter par
le biais de l’intranet de l’INIST.
Figure 5 : Intranet de l’Inist où les PDF sont consultables
14
4.1.3 Le cahier des charges évolutif
M. LECHAUDEL et M. GULLY ont également précisé que le cahier des charges serait
amené à se compléter afin de répondre parfaitement aux besoins. C’est en effet ce
qu’il s’est passé puisqu’au fil du temps, des précisions et des contraintes sont venues
s’ajouter. L’ensemble des modifications effectuées seront signalées au chapitre suivant. De nouvelles fonctionnalités sont concernées par ces changements.
4.2 Mise en place
Après avoir pris connaissance des objectifs du stage, la mise en œuvre de l’application sur PC a débuté.
L’application a été développée à l’aide de l’environnement serveur ‘LampServer’
offrant de fait la possibilité d’utiliser les dernières versions de PHP, MySQL et Phpmyadmin.
Piwik utilise le langage PHP ainsi que le framework Zend, le langage PHP s’est donc
imposé dans le développement du greffon. Ceci était d’autant plus intéressant qu’il
permettait d’approfondir les connaissances vues à la MIAGE.
4.2.1 Etude de l’application
Comme avant chaque développement, il a fallu procéder à une étude préalable.
Après avoir réfléchi sur les différents objectifs fixés, une analyse du logiciel Piwik a
commencé.
15
Piwik est un logiciel libre permettant de mesurer l’audience des sites web. Cela permet notamment d’évaluer le succès d’un site web, réussir à cibler l’intérêt des utilisateurs ou encore suivre la fréquence d’utilisation d’un site web.
4.2.2 Technique de mesure d’audience
4.2.2.1 La notion de 'Tracker'
Il existe au sein de l’INIST deux méthodes pour mesurer l’audience. D’une part la
technique dite des « fichiers de logs » (annexe 2) qui ne sera pas abordée dans ce
rapport mais qui est employée par le logiciel AWStats et d’autre part la méthode du
tracker utilisée par PhpMyVisites, Piwik et Google Analytics.
Cette dernière consiste en l’insertion d’un morceau de code JavaScript appelé
‘tracker’ dans toutes les pages du site web à étudier. Pour des raisons pratiques (optimisation du chargement des pages), ce tracker est généralement inclus dans le
pied-de-page du site.
Figure 6 : Exemple de tracker Javascript
Pour chaque site à analyser, un nouveau tracker est généré par Piwik. C’est ce code
qui va permettre de générer les données dans la base de données par la méthode
dite du tracking.
16
4.2.2.2 La méthode du tracking
Voici ci-dessous un schéma explicatif permettant de résumer le processus.
Figure 7 : méthode du tracking
Un utilisateur se connecte au site web à auditer, son navigateur récupère le tracker
JavaScript inclus dans le pied-de-page du site. Une fois obtenu, le code JavaScript
s’exécute et enregistre un certain nombre d’informations liées à l’utilisateur dans la
base de données. Comme le tracker est présent sur toutes les pages du site, l’ensemble des informations relatives à la navigation sur le site par l’utilisateur est enregistré.
Ce sont ces informations qui permettront de générer des statistiques et qui seront affichées dans les différents modules de l’interface de Piwik. Voici quelques exemples
d’informations stockées dans la base: mots clés, moteurs de recherche…
Figure 8 : Exemples de statistiques
17
4.2.3 Mise en oeuvre
4.2.3.1 Pourquoi Piwik ?
Piwik est le successeur direct de PhpMyVisites. Il reprend la même équipe de développement et s’appuie sur une nouvelle interface totalement personnalisable qui utilise le principe de widgets semblable à celui présent dans Igoogle ou encore Netvibe. En effet en quelques clics la disposition des éléments sur la page peut être en tièrement modifiée. Piwik est également une alternative open source à Google Analytics et offre la possibilité d’héberger les données sur votre propre serveur. Enfin,
c’est un logiciel libre qui bénéficie d’une communauté active de développeurs.
Piwik connaît cependant quelques limites. Comme les données sont hébergées sur
votre propre serveur, lorsque le site connaît un fort trafic, cela nécessite des moyens
matériels importants. L’archivage des données peut également prendre un temps
conséquent. Actuellement la version en place est la 0.6. La sortie d’une version incluant toutes les fonctionnalités est prévue dans une version ultérieure 1.0. Du fait de
sa croissance, le logiciel a vu s’imposer l’anglais comme langue par défaut dans
tout le processus lié au développement ou à la documentation au détriment du
français présent sur PhpMyVisites. Cependant le logiciel propose une interface disponible dans plus de 30 langues incluant le français.
4.2.3.2 Installation à l’INIST
Suite à cette étude sur le logiciel, il a fallu procéder à son installation au sein de l’établissement. Pour se faire, une installation d’une machine virtuelle Debian (annexe 3)
a été réalisée sur le poste. Cette machine virtuelle est utilisée par les développeurs à
l'INIST et permet de disposer en local d'un environnement de développement semblable à l’environnement définitif que l'on retrouve sur les machines de production .
L’objectif était d’éviter tout désagrément lié à l’environnement lors de la mise en
production réelle du logiciel.
18
Sur cette machine virtuelle, un environnement applicatif a été créé à l’aide d’un outil libre dénommé PKGI.
Figure 9 : Environnement applicatif (PKGI + LAMP)
PKGI permet de déployer rapidement sur un même serveur des applications indépendantes utilisant chacune un ou plusieurs modules proposés par PKGI. Pour les besoins du développement, les modules php, apache, mysql, phpmyadmin, crontab
ont été utilisés.
Une fois l’environnement créé, un site web de test a été réalisé afin d’appréhender
la méthode du tracking et d’étudier quelques statistiques fournies par Piwik. Suite à la
création du site, des tracker JavaScript ont été insérés et une demande de consultation du site a été effectuée par courriel au personnel de la DSI. Ceci avait pour but
de vérifier en condition réelle le bon fonctionnement des trackers.
19
4.2.3.3 Le site web de test
Un site web avec trois pages a donc été réalisé. Sur ce site on trouve quelques
images et des descriptions de l’INIST, PhpMyVisites et Piwik. Quelques liens permettent par la même occasion aux utilisateurs de se documenter sur Piwik et même
d’essayer la ‘démo’ ou de télécharger le logiciel.
Figure 10 : Aperçu du site web de test
Suite au bon fonctionnement du ‘suivi’ du site web de test et dans une optique de
mise en production, le logiciel Piwik a été déployé sur un serveur de pré-production
du nom de ‘IDA’. Dans le même temps, un tracker a été mis en place sur le WIKI de
l’INIST afin de l’auditer. La partie relative au développement du greffon PDF a
ensuite pu débuter.
20
4.2.4 Développement du greffon PDF
4.2.4.1 Contexte et démarche initiale
Au sein de l’INIST, il existe un module d’export PDF sur PhpMyVisites permettant
d’exploiter les données générées par le logiciel. Comme Piwik est encore en phase
de développement, cette fonctionnalité n’apparaissait pas comme une priorité
pour les développeurs du logiciel mais était nécessaire pour l’INIST. L'objectif était
donc de réaliser un prototype de greffon et de l’intégrer si possible dans le code
source officiel de Piwik afin de faciliter les futures maintenances logicielles
Pour ce faire, il a fallu suivre une certaine démarche. La première étape fut de
prendre contact avec le leader du développement de Piwik
M. AUBRY Matthieu,
ancien étudiant de l’Institut National des Sciences Appliquées (INSA) de LYON. Suite
à cela, une première approche avec le code a débuté. Piwik est basé sur le Zend
Framework lui permettant ainsi de disposer d'un cadre et de briques logiciels éprouvés et reconnus par la communauté de développeurs PHP. Piwik par son architecture permet le développement de greffons qui sont des bouts de code indépendants qui permettent d'étendre les fonctionnalités du logiciel. Le greffon PDF a été
développé en suivant cette philosophie.
Dans le même temps, une inscription à la zone des développeurs à été réalisée ainsi
qu’au WIKI de PIWIK afin de suivre l’avancement d’une manière générale du logiciel. Le développement de ce greffon était un objectif prévu par Piwik après la sortie
de la version 1.0 et dans la zone des développeurs un ticket concernant ce greffon
avait été réalisé. Sur ce ticket, une première version en développement avait déjà
été proposée. Cette version a donc été récupérée pour appréhender l’état actuel
des choses. L’occasion s’est également présentée de prendre contact avec le
contributeur du fichier. Le contact s’est fait en anglais puisque la personne ayant développé ce greffon fait partie d’une entreprise de développement de logiciels informatiques Conlabz Gbmh située en Allemagne.
21
Suite à la prise de contact avec M. Nuzil, développeur au sein de cette entreprise allemande, des tests sur la première version du greffon ont été effectués. Il se trouve
que le greffon n’était pas fonctionnel et ne possédait pas d’interface, seule une
structure générale du document PDF avait été réalisée.
4.2.4.2 L’outil d’envoi par mail
Avant d’attaquer la réalisation en tant que tel du greffon PDF, M. AUBRY a proposé
de créer un outil permettant d’envoyer les rapports PDF générés par mail. Ses arguments étaient que l’outil serait dans un premier temps plus simple à réaliser, la découverte des principes de codage de Piwik serait plus aisée et enfin que cet outil serait générique et réutilisé ultérieurement par d’autres fonctions proposées dans Piwik.
En parallèle, M. Schneider chef de l’entreprise allemande a ouvert des droits d’accès sur le dépôt subversion hébergeant le greffon PDF afin de pouvoir travailler en
collaboration sur le code source. Ceci a permis de prendre en main le logiciel libre
TortoiseSVN qui est une interface graphique permettant de travailler simplement
avec les dépôts subversion.
Suite à cela, le développement de l’outil d’envoi par mail a pu débuter. De manière
native, cet envoi devait se faire en utilisant la fonction mail de php mais devait pouvoir également être configurable pour une utilisation avancée. Dans cette configuration avancée, M. AUBRY a proposé de prendre en charge un système complet
d’envoi par protocole SMTP.
Au départ, la configuration mail était enregistrée dans une table de la base de données. Après discussion avec M. AUBRY celui-ci a proposé d’enregistrer ces informations dans un fichier de configuration, cela permettant à la fois de supprimer une
table de la base mais également de pouvoir réutiliser ces informations avec les principes de codage standard de Piwik.
22
Figure 10 : Interface des paramètres E-mail
Dans la dernière version de Piwik incluant cet outil, ces paramètres sont accessibles
et modifiables dans les paramètres généraux de Piwik au lieu d’un onglet spécifique
‘paramètres E-mail’ mis en place au début du développement.
Figure 11 : Structure des paramètres dans le fichier de configuration
23
4.2.4.3 Le greffon PDF
L’ensemble du développement du greffon PDF a été réalisé en collaboration avec
M. Nuzil (annexe 4) à l’aide du SVN de son entreprise mis à notre disposition. Tout au
long des échanges de mails, le dialogue s’est fait intégralement en anglais. Le processus de développement a été réalisé comme suit :
Une version bêta a été réalisée et soumise à Matthieu AUBRY afin qu’il puisse passer
en revue le code. Suite à cela une liste de modifications a été demandée sur le greffon. Il s’est ensuite mis en place un système d’échange : une fois la version contenant les modifications, cette dernière était à nouveau soumise au leader de Piwik qui
nous renvoyait une liste de choses à modifier ou à ajouter au code. Ce système a
permis à la fois d’obtenir un code robuste puisque relu par l’équipe de développement de Piwik et également en accord avec les principes de fonctionnement et de
codage du logiciel. Un exemple de révision de code par Matthieu AUBRY est fourni
en annexe 5.
L’objectif de se greffon était donc de fournir à l’utilisateur du logiciel, une interface à
la fois complète et simple d’utilisation lui permettant de créer un rapport PDF personnalisable. Le greffon a subi différentes améliorations au cours du développement et
seul le résultat final sera présenté dans ce rapport.
4.2.4.3.1 Créer un rapport
Comme son nom l’indique, un premier module devait permettre à l’utilisateur dans
un premier temps de pouvoir créer son propre rapport. Afin de rendre personnalisable le document PDF généré, différentes options ont été ajoutées à l’interface.
24
Il a fallu bien entendu permettre à l’utilisateur dans un premier temps de choisir les informations à inclure dans le rapport. Ceci est géré par un système de cases à cocher. Un champ texte permet également à l’utilisateur d’entrer une courte description qui sera affichée sur la première page du rapport PDF généré. Enfin l’interface
propose également à l’utilisateur de saisir une liste d’adresses mail auxquelles sera
envoyé le rapport. Vers la fin du développement du greffon, M. AUBRY a également
apporté une contribution en paramétrant l’envoi périodique (journalier, hebdomadaire, mensuel) d’email. Cet outil se retrouve également dans l’interface
d’ajout/création d’un rapport.
Figure 12 : Interface de création des rapports PDF
25
L’ensemble des informations liées à l’ajout sont directement enregistrées dans une
table ‘piwik_pdf’ de la base Piwik.
Figure 13 : Table piwik_pdf
4.2.4.3.2 Gérer la liste des rapports
Une fois créés, les rapports sont présentés, à l’image de ce qui se fait dans le greffon
‘Objectif’ de Piwik, sous forme de liste.
Figure 14 : Interface de gestion des rapports PDF
Dans cette liste, différentes options sont disponibles.
- Télécharger le PDF : cela va faire appel à la fonction ‘generatePDF’ de l’API
du greffon PDF et le navigateur va ouvrir une fenêtre offrant la possibilité d’ouvrir le
PDF ou de l’enregistrer sur le disque.
26
Il est important de préciser que le rapport est généré pour un site donné, pour la
date et la période du calendrier Piwik. Au début du développement la date et la
période ne tenaient pas compte de ce calendrier et pour être cohérent avec Piwik,
Matthieu AUBRY a demandé de prendre en considération ce calendrier.
Figure 15 : Calendrier Piwik
- Editer le PDF : lorsque l’utilisateur choisit cette option, le navigateur ré-affiche
le menu d’ajout/création d’un rapport complété avec les informations stockées
dans la base relatives au rapport à modifier. Toute modification du formulaire donnera lieu à une mise à jour de l’enregistrement concerné.
- Supprimer le PDF : l’utilisateur peut également supprimer un rapport. Une fenêtre de confirmation lui permet alors de valider son choix ou de l’annuler dans le
cas contraire. La valeur du champ ‘deleted’ passe alors à 1 dans la base.
Un point important précisé par le leader Piwik était de réutiliser le code existant au
maximum et surtout de coller avec le design déjà présent sur les autres greffons Piwik
(couleurs, mise en forme).
Au départ toutes les requêtes d’édition et suppression passaient par le protocole
http. Pour des questions d’optimisation du temps de chargement et de cohérence
avec les autres greffons, l’utilisation d’Ajax (Asynchronous JavaScript and XML) s’est
imposée.
27
Ajax, outil de développement de pages web dynamiques, a également permis de
réutiliser le système de gestion d’erreurs propre à Piwik au lieu d’afficher celles-ci
dans une page blanche.
Figure 16 : Exemple d’erreur générée par Piwik
4.2.4.3.3 Le rapport généré
Un exemple complet du rapport PDF généré sera fourni en document complémentaire (un exemple partiel est fourni en annexe 6). Toute la mise en forme du docu ment était gérée au départ par la librairie FPDF. L’avantage de cette dernière était
sa petite taille. Cependant, des problèmes liés à l’encodage UTF-8 des caractères
ont orienté nos choix par la suite vers une autre librairie pdf du nom de TCPDF. Cette
dernière était plus complète mais aussi plus volumineuse (environ 25Mo). La version
de Piwik à télécharger devait être d’une taille optimale et il a donc fallu ne conserver que les fichiers nécessaires de la librairie pdf.
Le logo PIWIK est affiché sur la première page du rapport généré. Un outil permettant de personnaliser ce logo a été réalisé mais n’a pas été retenu pour le moment
sur la version finale du PDF faute de savoir si le logo devait être global au logiciel Pi wik ou par site.
28
Figure 17 : outil de personnalisation du logo
Le rapport offre également une certaine flexibilité puisque M. AUBRY a demandé de
réaliser un rapport dont certaines caractéristiques telles que la police, les couleurs
pouvaient être personnalisables.
Dans la version définitive du greffon, le rapport généré n’inclut pas de graphiques.
Ceci s’explique par plusieurs raisons, la première étant que l’objectif de ce stage
était de réaliser un premier prototype de greffon reprenant principalement la mise
en forme de tableaux, la deuxième étant également le fait que la priorité de Piwik
était avant tout de pouvoir intégrer un greffon stable au code source officiel avant
la sortie de la version 1.0 de Piwik. Selon M. AUBRY il fallait préférer « créer un document PDF exempt de bugs avant d’y inclure la partie graphique ». Ceci fait donc
partie d’une des modifications futures à apporter au document.
A la fin du développement, une partie du temps à été consacrée à la traduction
complète du greffon en français.
4.2.5 Script d’automatisation
4.2.5.1 Introduction
Une fois le développement du greffon PDF bien avancé, un nouvel objectif est venu
s’ajouter au cahier des charges. M. GULLY et M. LECHAUDEL ont proposé de réaliser,
à l’image de ce qui existait déjà sur PhpMyVisites, un script d’automatisation pour la
génération des rapports PDF.
29
L’objectif du script existant étant chaque mois d’obtenir des rapports afin de pouvoir
les exploiter. Un script shell est donc mis en place afin d’effectuer cette tâche réglée
par le biais d’une crontab, mécanisme permettant de déclencher le script de manière périodique.
L’objectif a donc été dans un premier temps de récupérer le script et d’analyser son
fonctionnement. Celui-ci construit une requête en fonction des paramètres que l’utilisateur lui passe en options et en arguments. Cette requête http est ensuite envoyée
au serveur où est stockée la base de PhpMyVisites par la commande WGET. L’éxecution de cette requête permet de générer le rapport PDF et de le stocker dans un
répertoire prévu à cet effet. Ce répertoire sert ensuite à alimenter l’intranet de l’INIST,
endroit à partir duquel les utilisateurs pourront consulter les rapports périodiques.
Figure 18 : Intranet où les rapports sont consultables
30
4.2.5.2 Mise en place du script
Afin de reproduire les fonctionnalités du script de PhpMyVisites, il a fallu adapter le
code afin que celui-ci soit compatible avec Piwik. Dans un premier temps, le même
protocole a été testé et le script utilisait le même système d’accès pour générer le
rapport PDF. La force de Piwik est qu’il offre une API extrêmement bien structurée. M.
GULLY a proposé de réaliser un appel à cet API directement afin d’éviter de passer
par le serveur et par conséquent permettre de supprimer des couches réseaux inutiles. Le script final qui automatise la génération permet donc de passer directement par l’API Piwik et n’utilise plus la commande WGET.
Figure 19 : Schéma explicatif du fonctionnement
31
Le schéma précèdent permet de comprendre un peu mieux le fonctionnement général du script. Celui-ci peut être déclenché de deux façons. De manière automatique par le biais de la crontab : tous les mois le script va générer dans un répertoire
précis le rapport, ou alors de manière manuelle par un utilisateur souhaitant faire une
demande d’un rapport particulier. Dans les deux cas, le script effectue une requête
à l’API Piwik. Piwik déclenche l’appel à la fonction getReport qui avec les paramètres reçus va générer le PDF. Le script va ensuite créer les sous-répertoires
/nom_du_site/période/ correspondants au fichier dans le www/pdf/ et finir par copier le fichier PDF.
Lors d’une utilisation manuelle, M. GULLY a proposé de personnaliser ce script en proposant différents arguments et options tels que la période, la date, les sites pour lesquels on souhaite générer les rapports et également l’endroit où ceux-ci doivent être
enregistrés.
Le script peut donc être exécuté avec un ensemble de paramètres. Si celui-ci est
lancé sans arguments, cela équivaut à la génération automatique et mensuelle effectuée par la crontab.
Afin d’orienter l’utilisateur dans l’utilisation du script (options, arguments), un
« helper », menu d’aide dans la console, a été réalisé à l’aide de la librairie
Console_CommandLine (composant de la librairie PEAR).
Figure 20 : « Helper » du script d’automatisation
32
5 [CONCLUSION]
Ce stage m’a permis de découvrir le monde du travail au sein d’un institut
scientifique public. J’ai ainsi pu mettre en pratique bon nombre de connaissances
de la MIAGE afin de mener à bien mon projet.
Le travail comportait une première étude de mise en place du logiciel et une
seconde partie relative au développement lors duquel j'ai utilisé différents langages
de programmation (PHP, CSS, JavaScript, HTML). J'ai également été amené à mettre
en pratique les acquis de la MIAGE notamment en SQL et en UNIX afin de gérer les
interactions avec la base de données de Piwik et d’écrire le script d’automatisation.
Du point de vue du travail réalisé, je suis très satisfait car l’ensemble des objectifs
décrits ont été réalisés. L’outil a été testé, validé par l’INIST et, suite à cela va être mis
en production. Du coté de Piwik, la satisfaction est totale puisque le greffon a été
intégré au code source officiel depuis sa version 0.7 le 29 juillet 2010. C'est d'autant
plus gratifiant que mon travail est aujourd'hui téléchargé à hauteur de 200 fois par
jours par l'ensemble des utilisateurs de Piwik .
Du coté relationnel, tout s’est déroulé pour le mieux. En effet l’équipe m’a
rapidement intégré au sein du service. L’ensemble des échanges s’est réalisé dans
de très bonnes conditions, les personnes étant réellement prêtes à me renseigner et
m’aider à tout instant.
Au cours de ces douze semaines, j’ai également eu l’occasion de participer à une
journée PLUME à Lyon au cours de laquelle j’ai pu en apprendre davantage sur les
logiciels libres. Suite à cela, j’ai également apporté ma contribution en étant le
rédacteur principal d’une fiche PLUME relative au logiciel libre PIWIK.
Ce stage aura donc été très enrichissant autant sur le plan personnel que
professionnel. J’aimerais cependant poursuivre mes études en m’orientant vers un
Master 2 au sein de la MIAGE qui m’ouvrirait les portes du métier de chef de projet
informatique.
33
6 [GLOSSAIRE]
•
PHP: « Hypertext Preprocessor ». C’est un langage interprété qui s’exécute
coté serveur. Il est utilisé pour réaliser des pages web dynamiques sur un serveur HTTP.
•
CSS: « Cascading Style Sheets ». Ce sont des fichiers qui permettent d’assurer
la mise en page des éléments HTML.
•
SQL: « Structured Query Language ». C’est un langage informatique qui permet de manipuler des données contenues dans des bases.
•
AJAX: « Asynchronous JavaScript and XML ». Solution informatique libre pour le
développement de pages dynamiques et d'applications Web.
•
JavaScript: C’est un langage de programmation de scripts principalement utilisé dans les pages web interactives
•
Crontab: C'est le nom du programme sous Unix qui permet d'éditer des tables
de configuration du programme cron. Par extension, on appelle souvent cron
toute application lancée à horaire fixe.
•
Framework: kit de composants logiciels structurels, qui définissent les fondations ainsi que les grandes lignes de l'organisation
•
SMTP: « Simple Mail Transfer Protocol ». C’est un protocole de communication
utilisé pour transférer le courrier électronique vers les serveurs de messagerie
électronique.
•
SVN: « subversion ». Les développeurs utilisent Subversion pour maintenir les
versions actuelles et historiques de fichiers tels que le code source, la documentation.
34
7 [BIBLIOGRAPHIE]
http://www.manuelphp.com/
http://fr2.php.net/
 Informations sur toutes les
fonctions relatives à PHP
http://www.cfmfrance.com/
http://www.commentcamarche.net/  Forums d’aide PHP+ SQL
http://www.developpez.net/forums/
http://piwik.org/
http://dev.piwik.org/trac
http://dev.piwik.org/svn/
 Toutes les informations
sur Piwik
http://dev.mysql.com/
 Informations relatives
à MySQL
http://tortoisesvn.net
 Outil permettant d’utiliser
les commandes SVN
http://www.z-f.fr
http://www.smarty.net/
Tout sur le Zend framework
et le moteur de template
Smarty
http://www.projet-plume.org/
 Elaboration de la fiche
PLUME
http://www.pkgi.net/
Création rapide
d'environnements
applicatifs sous Debian
35
8 [ANNEXES]
Annexe 1: Le projet Refdoc en images
36
Annexe 2: La méthode des fichiers de log
37
Annexe 3: machine virtuelle Debian installée en local
38
Annexe 4: Répartition des tâches suite à une révision de code de M. AUBRY
(Ceci est un extrait d'une révision)
– En bleu le travail réalisé par M. Nuzil, en rouge celui réalisé par mes soins
* in PDF logo should be aligned on the left, instead of centered
* logo upload, when there is a problem, just fails with a message on white page... it should
instead be displayed with the standard error message on the screen (catch the exception in
controller and set error message)
* add PNG to list of supported files (and of course, refactor list of allowed filetypes to not
have different list in help message and in the code...)
* if I upload test.jpg, it is renamed as logo.png... of course same file extension should be
kept http://thedailywtf.com/Articles/Pipe-Up.aspx ;)
* Smtp: can you preselect "no" by default (after removing useSmtp=no)
* Generate should open PDF in a new window
* After creating a new template, window redirects to open the PDF. Instead page should
redirect to the list of templates, and user can decide to view it, or send by emails, etc.
* Form add new template: please reuse same style as Add a new goal (style used already for
listing templates). For example, items are in a table, the Add a new PDF Report link hides
when clicked and displays the form, etc.
* Can you add a simple "PDF" menu in the top bar instead of main menu? This can now be
done with hooks (see other plugins top menu)
* you introduce a new Form checking mechanism.... why?? please please reuse what is
already available: other forms are submitted as ajax, then the API checks the parameters, and
if one is empty (eg. the name) it throws an exception with the message being displayed in red
at the top. Please look at Goal plugin for an example. The form should work this way and
reuse the code (which will make your life easier, and very important will be consistent across
Piwik)
* Clicking on the label report name doesn't check the checkbox
* in report list, don't display group names when groups are empty
* instead of using this mechanism &action=callPdfApiAction&call=getReport, instead
just call the correct method directly from the UI. These proxy mechanisms are generally not a
good idea when they can be easily avoided. in this case, as said above, because your code will
call api directly, youll have to remove it anyway.
* the Send PDF to field is empty for super user, you can read email from config file
* Send PDF by email: also here the request should be submitted by Ajax, the Loading...
displayed, so that all errors and feedback messages are automatically displayed on screen. For
example in my case the mail server doesn't work, when I click Send I get a white page error
with only back button. By using ajax request and the piwikHelper js functions, this problem is
solved. Note that the UI can call directly an APi method (rather than calling the controller),
for example, API->sendReportByEmail($idSite, $reportId, for example.).
39
Annexe 5: Révision du code par M. AUBRY
(Ce document sur 2 pages est une des révisions effectuée par M. AUBRY suite à
notre envoi d'une deuxième version bêta du greffon)
In the submitted version, I wasn't able to generate a PDF with reports (list of reports didn't
display). I'll still do a code review:
• remove postLoad() from code
• change Piwik_Menu::add to Piwik_AddMenu and move to addMenu() method
• in trunk, Piwik::prefixTable doesn't exist anymore, it was deprecated for
Piwik_Common::prefixTable (I updated code to pass the install)
• logo.png in root is still the old logo, but logo was displaying fine in the PDF first page
(only page that was generated)
• PDFRenderer.php, file_exists('./plugins/Pdfex should use PIWIK_INCLUDE_PATH
instead of relative path. Also, filename should be in a variable and not copied twice.
Same for pdf->Output('./plugins/Pdfexpor in API.php and all other places
• in /libs/, are all files necessary to build the PDF (other files can be removed, like
date.js?)? Other css js files used can be moved to templates/
• Also, I assume that external libs files are unmodified? we can move then to piwik/libs/
when we integrate.
• API.php. Comments are not always useful ("Get Full PDF report", @access public is
not necessary as the functions are public, etc.)
• in the API.php files, you should not use Piwik_Common::getRequestVar. Instead, all
parameters are in the function methods and are automatically passed to the function by
the Piwik front controller. Check other API.php files for examples.
• getReport function is the same as getFullWebsiteReport, so getFullWebsiteReport
should be renamed in getReport
• idem for createTemplate and savetemplate, deteteTemplate and deleteReportTemplate
(btw delete is spelled wrong)
• some code indendation is different in API.php
• I don't really understand the $useForApi parameter
• because the methods are a bit long, I would recommend putting all SQL requests in
small methods. Also uppercase all SQL keywords (AND, WHERE, SELECT etc.)
• days should not be hardcoded in english. Instead you can use translations from the
translation files. Use Piwik_Date->getLocalized('%longDay%')
• do not do Date operations when it is possible to use Piwik_ helpers. To get the day-7,
you can use Piwik_Date::subDay(7)
• in savetemplate(), the function does a HTTP referer. The API are functions that can be
called from HTTP, json, etc. They can 'do stuff' and return data, but they can't set
cookies or other http headers. Instead the calling function should do the redirect.
• The code starting line 399 to 430 should be refactored in Piwik_Mail class, in the
constructor or when send() is called. You can create these methods in Piwik_Mail and
submit a patch to the file in the same .zip as the plugin.
• there are 'echo', var_dump etc. in various files that should be removed (throw
exception instead when it makes sense) For example when I tried to generate the pdf
the message Please contact your administrator to configurate the SMTP server and port
in 'PDF export Settings' was echoed to the screen.
• your API class extends the controller class...? but it should not extend anything. so you
couldn't use $this
40
• Controller.php
• you write period=yesterday but yesterday is a 'date' value.
• date=today. but is it this used? I think date and period should always be set so need for
default maybe?
• if/else and other code should be consistent with piwik code (if else on different lines as
the brackets). Check out coding standards
• as said in other review, you can't write "Piwik_Query("SET NAMES 'utf8'"); ". Other
plugins like SiteManager record UTF data as site name, so this can work without the
set names (piwik might support other DB soon, on top of mysql)
• in various methods, code is not refactored and copied pasted. same code should never
appear twice, eg.
$data[$k]['filename']
= "./plugins/Pdfexport/reports/".
$template['date_from']."-".$template['date_period']."_".
$template['site_id'].".pdf";
if
(file_exists('./plugins/Pdfexport/reports/'.
$template['date_from'].'-'.$template['date_period'].'_'.
$template['site_id'].".pdf"))
• the configurate() method is very long. You can split it in smaller methods (one for
email configure, other for reports)
• is it expected that you write TRUNCATE TABLE in the controller?
• why do you manually write stuff in the config files? the mail configuration will be in
config/global.ini.php so you can submit a patch to this file, and directly reuse
Piwik_Config methods to update the config file..
• you can use the SitesManager/API.php file to see a good example of an API class
• UI
• for ajax requests, showing errors and showing success messages, you can reuse
existing code. See example on how to do ajax request in the Goal plugin, when you
create edit/delete goals. see plugins/Goals/templates/add_edit_goal.tpl
• for non ajax requests ( If the form is submitted and refreshes the page) you can see an
example in the CoreAdminHome controller (simple clean example). See also the
templates.
• for the table, can you reuse styles of the Goal table? see
plugins/Goals/templates/list_goal_edit.tpl
• all CSS should be set as css classes and you can create a css file for all UI screens
• in the UI, either you talk in Ajax to the API directly. Or you must submit the form to
the controller actions that will then, in the controller code, call the API. You can't
however submit a form to the API directly.
• remove page.tpl
• HTML in PdfConfig.tpl has caps letter but we write HTML without caps
• idem the css should be refactored
• you create one html TABLE per line of settings... instead do simply like the General
Settings screen: plugins/CoreAdminHome/templates/generalSettings.tpl it will be
shorter code and be consistent with other screens
• none of this template code was displaying in my browser though: I just see the SMTP
settings form
41
Annexe 6: Exemple de Pdf généré
A noter, chaque tableau est généré sur une nouvelle page du PDF. Pour un
gain de place, dans ce rapport, ils ont été regroupés sur la même page.
42
43