Voir qui visite votre site

Soyez le premier à donner votre avis sur cette source.

Vue 9 219 fois - Téléchargée 1 437 fois

Description

Bonjour je viens de faire un script php permettant de stocker les visiteurs de votre site, et les affichant, tous ceci sans base de données car tout est stocké dans un fichier xml.

Mettre en place.

1. Téléchargez le zip du script et placez le dossier "visite" sur votre site.

2. Dans le fichier ou vous voulez insérer un visiteur ou, afficher les visiteurs, il faut inclure le fichier visite/LesVisiteurs.php:
PHP.

3. Après il faut déclarer l'objet:
--------
LesVisiteurs($chemin_racine_Visites);

- "$chemin_racine_Visites" étant le chemin vers la racine du dossier "visite".
--------

4. Si vous voulez insérer une visite il faut utiliser la fonction:
--------
insertVisite();
--------

5. Si vous voulez afficher les visiteurs il faut utiliser la fonction:
--------
$v->getVisites($nombre_de_jour);

- "$nombre_de_jour" étant le nombre de jours de visites à afficher. Les visites au delà de ce nombre sont supprimées, et vous ne pouvez pas aller au delà de 59 jours.
--------

Source / Exemple :


<?php
/**

  • ce code ce trouve dans un fichier du même dossier que le dossier "visite".
  • /
//on inclut le fichier contenant l'objet LesVisiteurs. include 'visite/LesVisiteurs.php'; //on déclare l'objet LesVisiteurs avec comme paramètre //le chemin vers la racine du dossier visite $v=new LesVisiteurs("visite/"); //on insère la visite $v->insertVisite(); //on affiche le module html contenant les visites //avec comme paramètres le nombres de jours à afficher, //au delà de ce nombre de jours les visites sont supprimées. echo "<div style=\"width:80%;margin:auto;\">".$v->getVisites(3)."</div>"; ?>

Conclusion :


Tout est stocké dans un fichier Xml, il est important de supprimer les visites fréquemment, car si vous avez 100 pages de visites, ça peut devenir assez lourd.

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

lynxtyle
Messages postés
79
Date d'inscription
samedi 25 septembre 2004
Statut
Membre
Dernière intervention
31 octobre 2011
2 -
Je n'ai fait qu'un survol rapide et je ne ferai que des remarques sur l'intérêt global de ton projet.
Je commencerai pas dire que celui-ci n'est pas assé évolué pour l'utiliser à la place d'un analystic par exemple (que ce soit au niveau de l'information récupéré que des ressources utilisées), mais je ne remet pas en question l'intérêt pédagogique de ton projet (je place cette remarque seulement pour ce qui cherchait une solution toute faite pour leur site).
Je ne veux pas trop rentrer dans les détails mais j'aurais une autre approche que je vais te donner, libre à toi de le prendre comme remarque constructive : pour ma part je traiterai les log du serveur au lieu de collecté les données sur chaque page... car le serveur log déjà toute les informations que toi tu stock dans ton xml... l'intérêt est que tu ne surchage pas ton serveur (certe ma méthode n'est valable que si tu as accès aux log serveur mais c'est le cas dans 99% des cas et les 1% restant autant partir sur analystic plutot que de surcharger son serveur).
Si tu souhaite utiliser ma méthode tu n'as pas beaucoup de choses à refaire sur ta page "d'administration" (juste linker le log et te renseigner sur la structure des log apache).

Sinon je te conseillerai de récupérer plus d'information sur le client pour "rendre utile" ton projet (définition d'écran, type de connexion, localisation des ip, page référente, pourquoi pas un callback en ajax pour savoir le temps réel passé sur une page etc...) qui sont autant d'information non présente dans les log apache.

Enfin je finirai que malgré que je n'ai fait qu'un survol il me semble que ça soit bien codé.

J'espère que tu prendras tout ça de façon constructive et n'hésite pas à demander si t'as des question sur comment traiter les log d'apache depuis un script php (je d'amblé apache car ils sont très rares les serveur php non apache)
dariumis
Messages postés
572
Date d'inscription
mardi 16 mars 2010
Statut
Membre
Dernière intervention
18 avril 2018
1 -
hey hey, salut merci d'avoir pris le temps d'écrire ce commentaire. J'avoue ne pas du tout connaitre les logs du serveur... je découvre en te lisant, et je vais me renseigner... mais c'est vrai que tous ça, je le fais plus pour le plaisir de coder ;).

Je trouve ton idée d'ajouter des variables intéressante, je n'avais pas penser au temps de connexion, je vois à peu près comment faire..., pour le définition d'écran et le reste je sais pas encore comment les récupérer mais je vais voir, mais pas ce soir, ce soir c'est call of duty ;)

Merci pour ta proposition de répondre à mes questions. bonne soirée.
lynxtyle
Messages postés
79
Date d'inscription
samedi 25 septembre 2004
Statut
Membre
Dernière intervention
31 octobre 2011
2 -
Pour les logs je vais te poser une petite question pour pouvoir te renseigner le plus précisément possible : où héberge tu tes sites en général ? (par exemple si tu as ton serveur privé les le chemin des log se trouve dans la config d'apache, si t'es en mutualisé ovh ou ikoula les log peuvent etre appelé par le script php dans le répertoire "/logs/" etc...)
J'en profite pour rappeler une petite chose au passage : un script php peut accèder à "tout" le disque et non juste au répertoire web, il peut donc lire et écrire n'importe où... (par exemple chez ovh le "disque" reste cloisonné à une racine "/", la racine du site est "/www", et les log apache sont dans "/logs" voir "/logs/nomdusite" si tu en a plusieurs sur le même hébergement. Les données dans /logs/ ne sont pas accessible par internet mais ton script php y a libre accès... de même tu aurais pu protéger ton xml dans un répertoire "/MesXML" pour éviter qu'un pirate récupère les ips de tout tes clients etc...)

Ensuite le fichier log apache est un peu comme ton fichier xml... (il note tout les ip, heure et requête effectué sur ton site... et les logs sont automatiquement archivé donc pas la peine de gérer la suppression des données anciennes)

Enfin bon comme je disai cette approche à le mérite de n'utiliser aucune ressource ce qui est avantageux (et si on souhaite quelque chose de beaucoup plus poussé autant partir sur analystic qui est gratuit et surtout qui évite de consommer les ressources serveurs... car quand on commence à compter c'est qu'on a du monde et donc faut de la pluissance...)
Un autre avantage de réduire le travail serveur et la vitesse de chargement de ta page : chaque microseconde gagné rapporte beaucoup de place dans le classement des moteurs de recherche!

alors pour la définition d'écran je te donne toute de suite l'astuce : c'est pas du php, certe, mais du javascript... par contre pour identifier la source de connexion je vais te rediriger vers un très bon site qui propose une source interessante sur le whois-ip à modifier pour tes besoins (http://www.frameip.com/whois/ <- tu peux flaner sur le site il y a plein d'info interessante sur les réseaux)... pour la vitesse de connexion tu as 2 solutions mais la plus interessante pour toi est de le coder en même temps que ton callback ajax : tu sauve le timestamp au moment où tu envois la page au client et tu retire cette valeur du timestamp du premier callback que tu reçois et tu compare ce temps avec le poid total de ta page. (avec cette méthode la valeur ne sera pas super précise mais tu obtiendra l'indication la plus importante : le client met combien de temps pour charger la page... l'estimation du débit étant presque secondaire... derrière tu peux presque rajouter une alarme qui prévient l'admin en cas de page trop longue à charger... enfin bon c'est ce jors de petit rajout qui peuvent rendre ce projet très interessant)

voilà j'espère t'être utile ;) et n'hésite pas à demander (pour ma part mon manque de temps n'est pas du à call of duty mais à des enterrements de proches, des déménagements, et autres joyeuseté du jors... donc désolé de pas avoir décortiqué à fond ton code mais bon j'essai de distiller quand même un peu d'informations que j'espère utiles... en tout cas ça m'aérer les neuronnes)
dariumis
Messages postés
572
Date d'inscription
mardi 16 mars 2010
Statut
Membre
Dernière intervention
18 avril 2018
1 -
Ne soit pas désolé de ne pas avoir décortiqué le script, et puis je l'ai pas vraiment commenté.... je suis désolé que tu sois dans les enterrements, bon courage. Merci pour toute ces infos, là j'ai pas trop le temps de retoucher le code... mais des que j'ai le temps... je m'y colle. Proteger le fichier xml.... j'y avait pensé, mais de placer le fichier dans les repertoires que tu cite plus haut, me semble une bonne idée, mais j'ai peur que ça nuise à la compatibilité du script... je me demande, si ce ne serait pas mieux de générer le fichier xml en php avec le header, puis faire une redirection toujours avec un header... je sais pas si c'est possible, il faudra que je teste... en tous cas merci beaucoup.
lynxtyle
Messages postés
79
Date d'inscription
samedi 25 septembre 2004
Statut
Membre
Dernière intervention
31 octobre 2011
2 -
Tout d'abord je te remercie pour ta compassion.
Pour ce qui est de protéger ton script tu es partis sur un truc trop alambiqué... car si tu génère ton script avec le php tu vas donc fournir un code généré sur internet, ce qui n'est jamais bon pour la sécurité... Ensuite certe tu peux planquer ton xml comme commentaire dans un fichier php mais bon c'est risqué (suffirait de faire une injection de script php en simulant un faut navigateur)... Après 2 as 2 grands classique : planquer l'info dans un dossier avec un .htaccess ou modifier les droits du fichier (mais tu peux toujours contourner une sécurité et surtout tu as parfois des comportement inatendu comme par exemple j'ai déjà eu le coup d'un fichier en droit limité devenu public parce que je l'avais récupéré avec mon client ftp lors d'une mise à jour)... Le top étant de mettre l'info dans un répertoire séparé de ton site au moins t'es tranquil !
Pour ce qui est de la compatibilité de toute façon dès que tu rentre dans quelque chose d'un peu complexe (la sécurité) tu te retrouve toujours borné par le matériel... Donc la solution d'un répertoire séparé est tout de même valable dans 95% des cas (je pense par exemple que free ne te fourni qu'un répertoire web... dans ce cas faut se rabattre sur autre chose... mais les hébergeur pro sont bien plus pro et te permettent la chose !)

Enfin voici un autre axe pour faire évoluer ton script : pour ma part ayant plusieurs site je ne développerai pas ce script pour fonctionner en local... Je ferai un peu à la sauce analystic (j'arrete pas d'en parler... si tu connais pas essai le... c'est pas pour faire de la pub mais c'est gratuit et très puissant...) c'est à dire que ton script serait accessible depuis plusieur site... par exemple fournis le code ajax callback à tout tes sites... le callback se fesant sur une page php dédier à compter les vite de tout tes sites (pour déterminer les stats de chaque site il faut alors avoir bien noté le site référent à l'appel du script... et/ou fournir un le code callback avec une id client).

Enfin bon les possibilités sont quasi illimité... Et c'est vrai que ton petit projet est sympa et plutot bien codé mais dans l'état actuel c'est un peu un réchauffé... il manque la petite touche qui le transformerai en script très utile (car si tu utilise le log serveur ça veut dire que tu n'utilise pas du tout de ressources ce qui peut même avoir un avantage sur analystic ! ou alors si tu en fait une solution multisite efficasse tu pourras toujours la distribuer et donc rencontrer de nouvelles demande et la faire évoluer)

Voilou... en tout cas bon coding et même si tu n'as pas le temps de faire les changements, les remarques sont surtout là pour faire évoluer tes connaissances. En particulier sur tes projets futures, car maintenant que tu as ses connaissances soit tu les testeras sur ce projet ou peut-être bien sur un autre ;)

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.