Odd behavior with hit counter
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
Most (if not all) of my individual pages have a hit count below 150.
If I accidentally or intentionally point it to a pid that does not exist, the count is _always_ 35367. No matter what pid I use, even if I go to a different one and come back to the same one, 35367 (as long as it is a nonexistent pid.
Of course, this is not particularly important, but it is puzzling. I can think of at least three ways this could happen:
- clicking on the link of a deleted person in the recent changes block. (How would you like to be told that the most popular page on the site is "private"?)
- mistyping a URI
- doing it on purpose, as I did to check something else.
Wes, this quesstion, your comment on the topic "Code question" and your related bug report "[ 2579268 ] Nonexistent != Private != blank" have me totally mystified.
You refer to "non-existant" IDs, then suggest they appear in Recent Changes lists, and you want to search for them. How can you search for something that doesn't exist?
My only guess is that you somehow have a problem either in your GEDCOM file, or the DB tables whereby an ID exists in one but not the other - presumably due to something going wrong during a delete process (either as a bug in PGV or human error). I concluded this becasue if I delete a person in the 'normal' way, their ID disapperas from view. Its not in recent changes, name lists, most popular surnames, the GEDCOM file, or the DB tables (any of them). Is that not the case for you? They only faint residue is that the 'next id' table has a space where this number used to exist.
No, it happens even if that PID has never been created. I verified that by intentionally trying individual.php?pid=P6000 in my DB that goes up to P1785
How you can search for one is by intentionally or accidentally typing the never-used (or deleted) pid in the search box.
I didn't say I _want_ to search for them. I just don't want PGV telling lies :-) if I or someone else does search for them--or clicks on a link to a record that _used_to_exist_
Maybe it's a bug that has been fixed already, but about a month ago, I deleted a couple of duplicate records, and they appeared in the recent changes as (unknown)(unknown). I think they _should_ appear as recent changes--but it should just say "deleted" instead of pretending it's a real record with no data.
The weird hit count is merely a side-issue that intrigued me.
Interesting. Kiwi, I think what Wes is saying is that if he navigates (through whatever means, for whatever reason) to a recently deleted ID#, one that hasn't yet been skipped over, it brings up a phony INDI page, where the hit count is the same as the hit count for the entire gedcom. In other words, the same page that refreshes when you "delete this individual". Wes, if I've misstated, please correct me.
BTW, I don't know how this would show up as Recent Changes, because there is no table of changes, just the Gedcom records themselves. Clearing the cache would eliminate these ghosts.
Edit: yes, verified. If I insert I14000 in my individual.php section of the URL, it takes me to unknown/unknown, with a hit count equal to the gedcom's counter. Doing the same thing with family.php and a nonexistent FID# results in a clean, blank page without any unknown/unknown, but it's equally unhelpful to an unaware user.
Weird, I agree. One would expect to get a page that says, "This individual (or family)" [insert the ID#] "does not exist" with a button to "Go Back" where you were previously. Sort of like intercepting a 404 error.
The hit-counts are stored in a file in the index directory.
I didn't get time for 4.2, but for the next release, this will be moved to a database table.
I'm not sure it's the hit count for the entire GEDCOM. Does that mean the sum of all the hits on all pages?
I think but can't be sure that the number of actual hits on all pages is less than the number I saw.
Also, if I do it again, several times, the number does not increment.
Anyway, the hit counter is just a curiosity.
The other parts are more of a concern, but I was working on them elsewhere.
For what it's worth: Deleted individuals no longer show up in the recent changes block.
Although, I'd prefer that they do, because that IS a change. Only the name should be "deleted"
Not showing is better than showing (unknown)(unknown) and linking to a page saying "private"
I know its not important, but nevertheless, intriguing. I found, doing the same thing, that mine displays 742803 - which when I look at the file /index/MYGEDCOM.gedpgv_counters.txt is the first row, and the only one not prefixed with '@', which is why its displayed on a "non-existent" INDI.
I checked the sum of all the other page counts, and its certainly not that (352320 in my case).
Looking at the code (hitcounter.php) I 'think' its the 'website counter' as opposed to the 'individual counter' - so presumably the total hits on the site, rather than visits to specific INDI records.
After y'all posted that I had to go back and check, and I can confirm that in my case the counter for the unknown individual *is* the specific gedcom counter. It's the same number I see on the hit counter on each gedcom's welcome page. Now, whether that's truly the sum of the individual counters, I don't know.
Hmmm, it still might be a bit off:
I went to my site. welcome page count was 35570.
1. Searched P7000. Of course (silly me) that said not found, and had no count.
2. I changed to indiv?pid=P6800. "Private" with no count.
3. clicked login, and logged in to Admin account.
4. Displays INDI with no facts and count of 35580
5. Go back to welcome page and it also says 35580.
So the two match, BUT, in _four_ page changes, it incremented by _ten_ :-)
Wes
and the site is closed to all others? or a bot, casual visitor or other user didn't hit those pages while you were checking?
"bot, casual visitor or other user didn't hit those pages while you were checking"
Hmmm, I'll take a look what access there was around that time.
If PGV is detecting bot/spider access, as it must in order to log "new spider", then it would be worthwhile to not add those to hit counters.