One of the features missing in the statistics module is aggregate/totals reporting.

We already do good reporting on recent hits, referrers, ...etc., but we do not provide reporting by time period, kind of a big picture view of visits.

This is a patch intends to be a first setp in addressing this, and is against the CVS HEAD version of statistics.module.

It provides two new menu items under the /admin/logs/ menu, one called 'month totals' and the other called 'day totals'.

/admin/logs/totals/month provides Month totals displays each month (as YYYY-MM) in one column, and the total number of hits (actually page views is a more accurate term) for each month. Since the maximum statistics kept is 16 weeks, there can be at most statistics for 5 months.

/admin/logs/totals/day provides Day totals displays each day (as YYYY-MM-DD) in one column, and the total number of hits for each day. 16 weeks means that a maximum of 112 rows returned by this screen.

I know it is kind of crude, and it could be improved (e.g. make it use pager_query(), make it select a month or a day range, ...etc.), make it multi-lingual, ...etc.), however, something is better than nothing, and perhaps someone else can take the base idea and refine it making it better.

(Now if someone can add aggregation by user agent, and separate crawlers from real browsers, that would be awesome!)

CommentFileSizeAuthor
statistics.module_1.patch2.53 KBkbahey
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bèr Kessels’s picture

also see http://drupal.org/node/15312 its related

kbahey’s picture

Yes, it is somewhat related, and would be nice if it is incorporated in what you are doing under a unified interface.

My patch provides historical data for comparison, how many hits per day for the last n days. How many hits per month for the last 4 months, ...etc.

There are other enhancements that would be really nice to have. I will enter them in the issue you pointed to.

Dries’s picture

This patch does not adhere to Drupal's coding standards, the SQL query looks both insecure and non-ANSI complaint and the strings can't be translated. Furthermore, the tables can't be paged which is a major problem. Won't commit as is.

kbahey’s picture

You are right in most of what you said.

This is a quick hack for me to get the info more than anything else.

Functionality wise, the need for aggregated statistics by day and month in some form is there for sure, and would be useful.

My hack was a stop gap measure for me, as well as a brain stimulus for someone who can make a better/cleaner one.

So, ignore my patch, but the requirement stays. I am setting the status as active because of that.

Boris Mann’s picture

kbahey -- why don't you make the changes to make this valid Drupal code? If you did that, then there is a good chance of getting it accepted into core.

kbahey’s picture

I would, but there are issues.

For example, I don't have Postgres running with Drupal, so I cannot test portability across MySQL and Postgres.

The use of UNIX_TIME and date formats also makes this patch unsuitable for internationalization.

I am not familiar with the how pager_query() works either. I tried briefly and it did not work for me.

If someone is willing to suggest ideas (e.g. making the SQL do the same functions but in a more portable, ANSI-compliant way), I may change the patch to be more Drupal compliant.

For the time being, I have resorted to writing an external shell script that generates the .sql files and runs them against the Drupal database to give me the per day and per month stats.

bomarmonk’s picture

I would also like to see this functionality in the core statistics module. It makes sense. I'll monitor this thread and see if any new developments occur. Thanks!

dan_aka_jack’s picture

Yes, I agree - a "total hits by month and day" would be a fantastic feature.

Are there any plans to add this functionality?

tenrapid’s picture

You could try my initial version of the statistics details module.

stefano@tipic.com’s picture

Two more requests:
1) prevent some paths for being recorded in the accesslog (for example /admin, /captcha, /user, etc...), like the block paths;
2) add a permission "bypass statistics", so that a group of users (admins, content editors, etc...) can browse content without increments for the node counters.

Vacilando’s picture

Version: x.y.z » 5.2

What happened to this project thread? There have been no updates for a year and a half. This functionality is sorely missing in Drupal.

Also the 16 week limit is a great impediment - why allowing older stats to expire? A historical overview can often be so useful!

StevenPatz’s picture

Version: 5.2 » 7.x-dev
Summit’s picture

Subscribing, greetings, Martijn

Bèr Kessels’s picture

Status: Active » Needs work

.. a lot of work, actualy:
1) it contains a SQL injection securit hole. Never! Ever! Include unchecked, raw variables in a query.
2) It simply does not work. If someone flushes access sooner then once a month (3 days is Default) it won't give you correct details.
3) Drupal (and xstats) follows strict rules of spacing and identing this patch violates these rules.

Bèr

asugene’s picture

Simple solution. I wanted a block of nodes filtered by "Recent Hits" of the past week. WITHOUT CODING!

Here is my answer:

Using the Views module and core tracker module. Add a "Sort" field by recent hits.
- Change your tracker configurations to 1 week (or how ever long you want it with default set settings that were find with me.)
- Add sort by "Recent Hits" and set it to descending.
- Follow Tracker instructions and Run Con... Why? Here is what I found:

-----
Configuring the statistics module at Administer >> Logs >> Access log settings

* Enable access log allows you to turn the access log on and off. This log is used to store data about every page accessed, such as the remote host's IP address, where they came from (referrer), what node they've viewed, and their user name. Enabling the log adds one database call per page displayed by Drupal.
* Discard access logs older than allows you to configure how long an access log entry is saved, after which time it is deleted from the database table. To use this you need to run cron.php
----

WALA! A list how I wanted.

stiatapygia’s picture

..er
can someone tell me how to use this?
i really need this function to justify having a site (and job) to the boss

thanks

alexandreracine’s picture

Dave Reid’s picture

Status: Needs work » Closed (duplicate)

Arg, #142668: Retain historical node_counter information should have been marked a duplicate of this issue, but I'm going to mark this as the duplicate, sorry.