Hi,

The stats system in Composr is something we think should stay very basic. This is because there are so many better stats systems out there, and as far as I'm aware not a great argument for creating another one within Composr (it's back-end functionality visitors don't need to see well integrated, and it doesn't really need to tie in particularly with anything that isn't already available on the Apache level in the access-log). Given Composr is already a huge system, adding extra features to be learnt/maintained is something we would seek to avoid unless there's a compelling reason to do so.

If you don't want to use a Javascript stats solution, I'd suggest something like awstats. Most hosting has that preinstalled anyway.

Out of curiosity, why have the stats module at all then? The current functionality really doesn't tell you anything. So I figured, why not make it useful if you are going to have it? It seems you are already tracking which pages are being hit (for example, each forum thread and at least most of the stand-alone non-wiki pages). How much harder would it be to just pass full wiki pages into the existing system?

Am honestly curious what the logic is here. Thanks

If you're putting Composr on a server without anything else installed, or perhaps on a hosting account for a client where they just need very basic stats but you don't want to give them their own hosting control panel access, it makes some sense. You can see how many hits your site gets, some basic visitor break-downs, what hits the main pages get (e.g. about page, front page, that kind of thing). For the great majority, that's all they need. Only a minority of sites actually both have content repositories and the need to do analytics on them, and the vast majority of those will want the full range of analytics tools someone like Google can provide (there's no way we can compete without investing millions).

If we just add something in for wiki pages, it would make it inconsistent, and we'd therefore need to create a plugin system for handling any kind of content to make it consistent (a lot of work, and a lot of code to be maintained/distributed/documented/supported). Or, if we left it inconsistent we'd have a lot of people getting confused then asking where do you check for other content types. Catalogue categories are held as a very special case, because some sites will use those for affiliate advertising and thus need to know some view counts on each category.