Bug:

If I rename a topic, links in WebStatistics get updated, but not the .changes file as well. So, it is not uncommon to see in WebStatistics, the original come back broken.

Test case

Environment

-- JeromeBouvattier - 06 Mar 2002

Follow up

Actually it's the log*.txt file that's not updated. I'm not sure of the best way to address this, given that log files are useful for recording what happened and shouldn generally not be tampered with. Since rename is logged, it's conceivable that the statistics script could track this, but that would be fairly complicated to do... I've just re-written the script to use less memory (see StatisticsUsingLessResources), and it's now based on hash tables - which might make this relatively easy as the script would just move a stats value from one web's hash to another, and fix up some other hashes.

I'm curious to see what other people think - should the stats hide the renaming operation? It might be useful to know whether a renamed topic got more hits before or after it was renamed, for example.

I've changed this to FeatureEnhancementRequest since it's not obvious how this should be addressed.

-- RichardDonkin - 06 Mar 2002

The rename messages also appear in the log file. My intention was always to take note of these rename messages when the statistics program runs. In not sure if I'd be that interested if a rename had changed the popularity, however, it might just be useful to show last months name in brackets (dealing with multiple renames could certainly get confusing).

-- JohnTalintyre - 07 Mar 2002

Although I now understand the technical difficulty, I agree with John that tracking renames has more sense. Some examples :

• A topic is very hot. Then it enters the top five and stay there for some days. Last contributions lead to a renaming around the end of the month. In this situation, you will have a broken link sitting in the stats and there is good chance the new name won't come in the top ten before the end of the month. In this situation, newbies won't find their way to the renamed topic even if they are interested in it. Let's imagine the new name comes in the stats, then the activity information is unnecessarily diluted if the user can't see that the two topic names are actually one.
• The cumulated hits on both the original and new names could make the topic enter the top ten when taken separately none will have a chance.
• Here people still don't put the necessary care in naming new topics. Unfortunately, this can not always be tracked soon after the topic's creation, because the meaning of the topic isn't always evident.

-- JeromeBouvattier - 27 Mar 2002

Fix record

I'm planning to implement this by tracking renames in the statistics program, without changing log files. As discussed above, it will show the most recent name for a renamed topic, rather than showing before and after stats.

UPDATE: Now implemented in TWikiAlphaRelease and latest statistics script uploaded to StatisticsUsingLessResources. This turned out to be quite an easy enhancement, because the new code is based on hash tables.

I'd be interested to hear how this runs under ModPerl when using the WebStatistics page's 'force update' option. It would probably be best to make this use the non-mod_perl CGI handler, since it doesn't benefit from mod_perl and could cause problems by tying up an Apache process for a long time. It does a use strict so it should work OK.

-- RichardDonkin - 27 Mar 2002

Update: Oops, I just saw the email with your patch to fix this (the above) so I realized that it's not implemented on twiki.org yet -- I obviously jumped the gun (below). I'll wait and see what happens after the change is implemented on twiki.org -- maybe the unnamed pages will get names.

Richard,

Thanks very much for fixing StatisticsUsingLessResources and for your work on the rename part.

There is an anomaly in the WebStatistics -- notice that there are a few unnamed pages (i.e., a number but no page name). I don't know whether these are the result of renaming or some other reason:

• Feb, 2002, an unamed page with 127 hits
• Mar, 2002, an unamed page with 328 hits (I guess the number of hits could increase before you see this note)

Perhaps this will be resolved by your latest changes?

It would be nice to have a name on these pages, whether it was the old or new name. (I'm not positive, but I think I'd prefer to see the new name, possibly with a note like "renamed to <NewPageName".)

Another minor problem that I'm recording "just for the record" is that one of the pages on the list (Md5sumsAfterBurning) doesn't show up as a link. I imagine that's because I failed to strictly follow the rules to allow a page name to be automatically linked. When we build the perfect TWiki, I'd like any page name to be linked in things like statistics.

UPDATE: The last problem Md5sumsAfterBurning not showing as a link has been fixed by renaming the page to CdromMd5sumsAfterBurning -- the original page name is not a valid TWiki name because of the numeral before the second (group of) uppercase letter(s). -- RandyKramer - 17 Apr 2002

ANOTHER UPDATE: In an effort to find the page that is causing the blank page name on the Wikilearn.WebStatistics page, near the beginning of May I visited the following pages several times just to confirm that they do show up in the statistics. I will record any further testing of this on the page Wikilearn.WebStatisticsDiscussion. -- RandyKramer - 01 May 2002

-- RandyKramer - 28 Mar 2002

Thank you so much Richard !

-- JeromeBouvattier - 28 Mar 2002

Re the blank names - this looks like a bug, as renames were handled fine locally - it could be the lack of the latest patch as you mentioned, since the renames could have confused the new script in a different way to the old one (though I would have expected two different entries for the old and new name of the page).

Maybe PeterThoeny could apply this rename patch and see whether this is fixed on the next statistics run? Failing that, I need to get the TWiki.org logs so I can debug locally.

-- RichardDonkin - 28 Mar 2002

I've put a fix in CVS that addresses the case where topics are moved between webs, adjusting the web-level 'view' stats to take care of this.

-- RichardDonkin - 28 Mar 2002