Byg en besøgstæller fra bunden af...

<ole>

Du skal nok ikke i første omgang tænke så meget på, hvilke sider du skal tjekke først. Hvis du måler på alle dine sider, kan du senere trække alle mulige rapporter ud på kryds og tværs af dine data.

Hvis dine data skal blive interessante, skal du nok tælle alle sidevisninger med timestamp og IP - og evt. info om klient properties, referer, URL med søgestreng, etc - og indsætte dem i en database.

Du bør sørge for, at kikke på besøgendes 'USER_AGENT' og holde den op mod en liste af kendte botter, så du kun tæller 'ægte' besøgende. Der findes lister 'derude', men sørg for at vælge en, der stadig og hele tiden holdes opdateret.

En anden approach til at frafiltrere botter bygger på, at en bot, der overholder reglerne, som det første læser sitets 'robots.txt'.

Prøver en klient at tilgå robots.txt, sørger en .htaccess for at klienten får serveret et PHP-dokument. Dette PHP-dokument logger klientens IP og USER_AGENT - og derefter udskriver teksten, som ellers ville stå i robots.txt. Denne IP/USER_AGENT kombination skal der efterfølgende ikke logges sidevisninger for.

Under alle omstændigheder vil der være bots, som ikke står på nogen af listerne, og som heller ikke læser robots.txt. Du kan dog filtrere de fleste fra, og den slags står for utrolig meget traffik.

Logning af sidevisninger kan hurtigt komme til at fylde enormt på et populært site, så du bør overveje en eller anden form for backup/caching med passende mellemrum.

Endelig kan du jo bruge en af de mange løsninger, som allerede er tilgængelige. Det er i det hele taget meget lettere  =)

/mvh
</bole>

Statistikken kan du hente via access.log og en log analyzer.

Eller goer som de fleste og brug Google Analytics.

:-)

En taeller er jo bare at hente fra og opdatere database.

#2: Der er mange udbydere, som ikke tilbyder adgang til logfiler, men kun en mere eller mindre mangelfuld statistik. Måske er det derfor, spørger gerne 'vil selv' (og så for at lære).

Som jeg antydede i mit første indlæg, er jeg dog helt sikker på, jeg selv ville bruge GA  =)

Hej...

Tak for jeres indlæg.. Som ole nævner i #3, er det netop for at lære jeg vil selv.. men jeg er ikke en ørn til dette php endnu, håber engang at blive det. Ole jeg har læst dit indlæg i #1 og jeg syntes det for en begynder der ikke helt ved, hvor man starter for at bygge sådan en tæller, der syntes jeg det virker lidt avanceret.. men du har ganske ret.. Jeg vil jo gerne lære, og helst "Big time".. har som regel styr på det jeg får fat i.. men så er det jo lige med at vide hvor man starter for at vide, hvad man skal have fat..

Skal nok læse dit indlæg et par gange for at for stå USER_AGENT/Timestamp osv.. og IP kendes :-)

#2 nå.. jamen... så er det jo "bare" lige at få smækket denne DB sammen.

En tabel med to felter page og counter er ret nem.

Hej...

jamen.. er det noget lignende :



Men hvad gør man så?? Havde jo en ide om at man tog og startede sin side med en session_start() for derefter at smide en "Side_Sti" ind i en $_SESSION via PHP_SELF og så talte en counter op, skrev denne counter  til en fil eller som i er inde på her til en DB.

Det var lidt denne ide jeg havde om begyndelsen til en "Skrabet" tæller... den holder måske ikke vand??

hvis du goer page til PK saa behover du ikke engang id

Det kan laves paa flere maader.

Men hvis din side xxxx.php har en:

include 'counter.php';

med en counter funktion og du vise counter ned:

echo counter($_SERVER['PHP_SELF']);

saa skal du have lavet den counter saa den bruger den tabel.

Hej..

#7: Du mener page til PRIMARY KEY ??



#8: Det lyder godt og forståeligt :-)
Jamen, det må vel så være at sætte page = argumentet i kaldet af funktionen.. og tæller counter op + sætte den ind under counter tabellen??

ja

UPDATE views SET counter = counter + 1 WHERE page = ?
SELECT counter FROM views WHERE page = ?

og jeg vil nok ikke bekymre mig saa meget omkring concurrency

Hej..

Ja... Kan se du bruger mySqli i #11.. endnu et punkt jeg endnu ikke er kommet helt igang med.

concurrency tog jeg lige en hurtig google på... Er det ikke noget med modifikation fra ejeren af Db'en??

Nå.. nu kan der vist ikke trækkes flere veksler på de 27 point, vil du smide et svar, Arne..
Og så skal du have tusind tak for hjælpen :-)

Jeg brugte generel SQL med prepared statement. mysqli er en maade at lave det paa med PHP og MySQL.

Concurrency problemet er dette:

bruger A ser siden og counter er N
bruger B og C ser siden samtidigt
bruger D ser side og counter er N+3

Hvad ser B og C.

De boer se N+1 og N+2.

Men med 2 SQL saetninger riskierer du at de begge ser N+1 eller begge ser N+2 medmindre du goer noget for at forhindre det.

Min pointe er at det ikke er umagen vaerd at bruge tid paa at forhindre det.

svar

Hej..

#15: åh.. Det er vel altid relevant at lave så "Bulletproof" kode som muligt og at sørge for det man præsenterer er korrekt.. eller??

Handler det så lidt om at brugerne A,B,C,D på en eller anden måde skal repræsentres vha. IP-adresse. Eller er der noget der er misforstået.

'Concurrency' i den betydning, Arne omtaler, handler om 'samtidighed mellem begivenheder'.

Hvis ingen har set siden endnu, og vi to begge går ind på siden præcis samtidigt, så er der umiddelbart et (akademisk) problem med resultatet, vi får vist.

Vi burde begge få vist 'To personer har nu set siden' - men systemet har ikke haft tid til at registrere mit besøg, og du får derfor beskeden: 'En person har set siden'. Jeg får af samme årsag samme besked.

I denne sammenhæng er det et meget lille og ubetydeligt problem. I andre betyder det rigtig meget  =)

Langt vigtigere er det at beslutte, hvad det egentlig er, du vil tælle. Vil du bare tælle sidevisninger (herunder reloads), eller vil du vise unikke visninger (én visning pr. side pr. dag pr. bruger)? Ønsker du at vise sidevisninger til brugere - eller også til søgerobotter (der kan være voldsom forskel på de to tal)?

Ligenu tæller du kritikløst alt sammen til ét tal - og du har ikke data til at sortere/diskriminere ved visningen

Hej..

#18: jamen, hvad så hvis vi går ind samtidigt og hver især får vist "En person har set siden" , men en tredie bruger hopper på 10. sek senere.. får han så at vide at han er den tredie besøgende, selvom den ikke har talt vores samtidige besøg som 2..??.

Jamen.. Det jeg egentligt vil.. er at lave det så perfekt som muligt med så mange data som muligt, men da jeg stadig betragter mig selv som ny- lærende i faget, må jeg jo starte med at "kravle før jeg kan gå" .
Men jow.. Det ville da være rart at ende ud med :
  - antal daglige besøg
  - antal visninger af de  forskellige sider.
  - samlet årlige besøg.
  - Samlet antal besøg(siden oprettelsen).

Men det skal også siges at tager man min webadresse.. Er det som bruger jo egentligt (index.php/html) man kommer til, der havde jeg så lidt tænkt mig, at er jeg nu f.eks kommet til (index.php/html) skulle det gerne tælle som et besøg, men skifter jeg så frem og tilbage mellem siderne, f.eks til gæstebog.php skal mit besøg selvfølgelig tælles op på gæstebogs siden, men skifter jeg så tilbage til forsiden(index.php) altså den egentlige webadresse skal jeg jo så selvfølgelig ikke tælles igen før jeg har forladt webadressen og så vender tilbage..

Og jow jeg vil også gerne med tiden tage hensyn til botterne, så det kan godt være det ikke er det sidste i ser til mig mht. til spørgsmål om denne tæller, men er som sagt lige startet igen med webinteressen efter en kort pause, og også i det hele taget.

Efter min bedste overbevisning er en counter paa en web side ikke saa vigtig som saldi paa en bank konto.

Men hvis du vil sikre dig mod concurrency problemer vaelger du en af:

A) brug InnoDB tabeller, brug transactions og brug transaction isolation level repeatable read

B) brug InnoDB tabeller, brug SELECT ... FOR UPDATE