CrazyStat

Version 1.71 RC1

Advanced presets

Intended audience

This file describes advanced usage of presets for CrazyStat. It describes how to manually write your own preset. This file is intended for the advanced user who knows PHP. You should have successfully created a preset with CrazyStat's "Manage presets" feature (GUI) before manually creating presets. The tricky part of the GUI-usage is explained in relative_time-spans.html which you should have read before reading this.

How presets are defined

Presets are stored as php-files in usr/presets. Every preset has its own file. Presets generated via GUI are called presetX.php with X being a number. The file-name of the preset and the internal ID (see below) must be identical. The presets are ordered by file-name / ID in GUI (not by preset name!).

Presets are arrays that look like this:

$config_preset['PRESET_ID']['name']=LANG_CONSTANT;
$config_preset['PRESET_ID']['presets']=array('PRESET_ID1','PRESET_ID2',...);
$config_preset['PRESET_ID']['cache']=BOOLEAN;
$config_preset['PRESET_ID']['cacheable']=BOOLEAN;
$config_preset['PRESET_ID']['modules']['MODULE']['VAR']=VALUE;

PRESET_ID
Internal name of the preset, must be identical with the file name! Presets are ordered by this ID.
name
The name of the preset shown in the front-end. This should ideally be the constant of the language file (LANG_CONSTANT). You can also use one string here for all languages. If no name is defined, this preset will not be visible in front-end (only as a base for other presets or for caching - see examples).
presets
Make the preset based on other ones. Here you can combine several other presets (array of preset-ids to be loaded). You could e.g. base your preset on the default-preset:
$config_preset['PRESET_ID']['presets']=array('01_default');
cache
Define whether to cache this preset or not. Can be false or true.
Attention: A Preset is only cacheable if at least these settings are defined: ip, time_span
DO NOT set cache=true if you did not define those!!! You can load other presets (like ip1) to easily add default ip or time settings to make your preset cachable. Two presets which have the same ip, time_span, time_start and time_end settings for all modules are equal concerning caching so only one of them needs to be cached even if other settings are different (CrazyStat will in fact realize that they are identical and only cache one of them, even if both are set cache=true). This value can be changed via GUI.
cacheable
Only presets that define IP and time-settings for all modules are cacheable. Presets saved via GUI always do this and therefore are always cacheble. Manually written presets or some of the presets that come with CrazyStat might not be cacheable (e.g. the tree- or scroll-presets). If you write presets that are not cacheable, you need to set this to false so CrazyStat knows that this preset can not be cached. Setting "cache" false is not enough, because "cache" can be changed via GUI if cacheable is not set or true. Default is true and can be omitted.
modules
define a setting for one or a couple of modules
MODULE
Module the setting should affect. Either:
one specifix module
(hit),day,month,weekday,hour,browser,file,resolution,colordepth,system, referer,keyword
a group of modules with the same capabilities
LIMIT
All modules with limit/all capability (browser,file,resolution,colordepth,system,referer,keyword)
ALL
All modules (see above) NOTE: as 'hit' is unchangeable, better use CALENDAR instead!
CHARTS
All modules with pie chart capability (browser,resolution,system)
GLOBAL
Global setting (not module-specific - see VAR)
CALENDAR
All modules that support calendar-settings (all except hit) BETTER USE THIS INSTEAD OF "ALL" (unless you know what you're doing)
VAR
the variable-name of the setting, one of:
all
show limited number of items (false) or all (true)
ip
block by ip (true) or not (false)
piechart
use piechart (true) or not/barchart (false)
time_rel
use relative timespan? Using false is quite useless, so this should be always true for good presets (boolean)
time_rel_start
time analyzing should start (string) a "GNU time"-string with special chars replaced. Something like: "Today", "%d.%m.%Y", "03/10/2010", "Today 12:00:00 +1 day", "2009-W20-1" (which means first day (Monday) of week 20 in 2009). See relative_time-spans.html for more information on this.
time_rel_end
time analyzing should end (just like rel_start) (string)
time_rel_name
name of the time-span with replaced chars (string). See relative_time-spans.html for more details.
time_rel_startid
Number of the entry to start with. Special chars replaced. See relative_time-spans.html for more details. (string)
time_span
analyze complete log (false) or not (true) must be true if you use time_rel_start and time_rel_end, false otherwise!
time_start
if using absolute time-spans, here the start timestamp is given this is too inflexible for presets, so normally do not use it! (int)
time_end
if using absolute time-spans, here the end timestamp is given this is too inflexible for presets, so normally do not use it! (int)
scroll [global]
use scrollbars (true) or not (false) NOT MODULE-SPECIFIC!
tree [global]
which tree to use (mk/ajax/auto) (currently only used by module referer, but global setting!)
VALUE
The new value for the setting. See VAR for valid values.

Notation

Of course you can use any php-notation to define this array - this file tries to keep it simple, but e.g. feel free to use the following if you like:

$config_preset['PRESET_ID']=array(
   'name'=>LANG_CONSTANT,
   'presets'=>array('PRESET_ID1','PRESET_ID2',...),
   'modules'=>array(
        'MODULE'=>array('VAR'=>VALUE)
        )
   );

Caching problems with bad presets

Caution: Do never set ip- or time-settings twice! This might make things A LOT SLOWER because then caching won't be possible!

Bad examples:

$config_preset['bad_preset1']['modules']['CALENDAR']['ip']=false;
$config_preset['bad_preset1']['modules']['day']['ip']=true;

Here setting "ip" for "day" is first set false (by CALENDAR) and then true. Instead you have to set the settings for all modules individually or use special values in which the module is not included:

// we can use LIMIT because "day" is not in there:
$config_preset['good_preset1']['modules']['LIMIT']['ip']=false;
// now we set all the other modules except of day:
$config_preset['good_preset1']['modules']['weekday']['ip']=false;
$config_preset['good_preset1']['modules']['month']['ip']=false;
$config_preset['good_preset1']['modules']['hour']['ip']=false;
// and finally the setting for "day":
$config_preset['good_preset1']['modules']['day']['ip']=true;

Another bad example:

$config_preset['ip0']['modules']['CALENDAR']['ip']=false;
$config_preset['bad_preset2']['presets']=array('ip0');
$config_preset['bad_preset2']['modules']['browser']['ip']=true;

Here setting "ip" for "browser" is first set false (by preset "ip0") and then true. You would have to change preset "ip0" or name all the modules manually to fix this.

Good examples

See usr/presets for other (good) examples!

Submit your preset

If you think you made a good preset, feel free to e-mail it to: webmaster AT christosoft DOT de (I might include it in the next version or publish it on my website for other users)