Stats package - Revision history

Deraadt at 08:09, 10 June 2011

2011-06-10T08:09:26Z

← Older revision		Revision as of 08:09, 10 June 2011
Line 12:		Line 12:

	There is the ability going forward for modules to add their own stats processing if they want to, there are hooks in lib/statslib.php for modules - just registering a function is enough.		There is the ability going forward for modules to add their own stats processing if they want to, there are hooks in lib/statslib.php for modules - just registering a function is enough.

	~~[[Category:Stats package]]~~

Tsala: cat edit

2007-06-18T10:02:54Z

cat edit

← Older revision		Revision as of 10:02, 18 June 2007
Line 12:		Line 12:

	There is the ability going forward for modules to add their own stats processing if they want to, there are hooks in lib/statslib.php for modules - just registering a function is enough.		There is the ability going forward for modules to add their own stats processing if they want to, there are hooks in lib/statslib.php for modules - just registering a function is enough.

			[[Category:Stats package]]

Tsala: Stats package moved to Development:Stats package

2006-10-26T10:00:42Z

Stats package moved to Development:Stats package

← Older revision		Revision as of 10:00, 26 October 2006
(No difference)

Helen: developer wiki transfer

2006-01-07T18:12:27Z

developer wiki transfer

New page

The Stats package does cronjob-based processing of the log table, and stores a lot of aggregate information on a per-course and per-user-course basis.

Each module registers two functions which return an array of actions - one for 'view' actions and one for 'post' actions. Basically reads/writes.

There are 6 new stats tables: daily, weekly, monthly, one for course and one for user.

The cronjob can be quite intensive to run, so there are a number of config options to control it - what time of day it should run, how long it should run for, and how long back to process the logs for the *first* run. Going forward, running it nightly should be fine, but the first run can take a long time, so most sites could set something like, start at 10pm and run for 8 hours. This would happen every night until it 'caught up' to the current logs.

Weekly and monthly stats are an aggregate of dailies, and as such, older dailies get deleted after 2 months and older weeklies get deleted after 8 months.

From a UI point of view, there are pretty graphs for teachers for their courses, and a pretty graph in the activity section of the user view. For the non-gd enabled, there is a not-so-pretty table.

There is the ability going forward for modules to add their own stats processing if they want to, there are hooks in lib/statslib.php for modules - just registering a function is enough.