Introduce option to separately configure storage and display ranges

[stklcode]

This PR instroduces a new option days_show to separately define the range of data collection and display in the dashboard widget.

Defaults to the same value on installation, but allows to keep long-term data in the database (e.g. to display in some custom evaluation) while keeping the dashboard widget clean and only show recent values.

[patrickrobrecht]

Good work already!

For me it's a little confusing that the setting "Entries in top lists only for today" overrides "Period of data display in Dashboard" for the top lists if it's active. I suggest two separate settings "Period for chart" and "Period for top lists" (and removing "Entries in top lists only for today").

[stklcode]

At the stage the "today" switch enables today only, otherwise chart period = top list period.
We should relabel the "for data display in Dashboard" to something like "for Dashboard chart" to clarify.

Possible alternative would be 3 periods without the today-checkbox. Might be over-configurability though.

Another question related to that:
Should we add a more sophisticated update method to restore previous behavior?

[patrickrobrecht]

I don't think that a more sophisticated update method is necessary.

[websupporter]

Why would someone want to separate those two values? Because

1. He wants to store more data and
2. doesn't want the dashboard to be flooded with data points

Why does he want to store more data than he shows? Because another tool is in use, which gives more insight. e.g. the extended plugin. This is, why I would opt for a filter instead of a UI to separate these values. If you only run the statify plugin, there is no benefit in separating those values. So to me, separating these two concerns is third party, like a CSV exporter plugin or the extended statify plugin or whatever.

To have the UI without a use case will most likely produce a lot of questions like "How can i see this data?" So in my eyes statify should have just one field, which defines the range in the dashboard and the save range, but the save range could be overwritten by third party via filter.

[stklcode]

See the point. Argument against might be collecting data and occasionally having a look into it without a separate plugin. Maybe not the average Joe's behavior though and you could still add a filter by hand.

So something like this (with some sanitization), which allows modification of all 3 parameters, might do the job without adding new attributes, 95% of the users probably never missed... Could prepare another PR for that.

// Initialize default dashboard configuration.
$cfg = array(
	'days'  => (int) self::$_options['days'],
	'limit' => (int) self::$_options['limit'],
	'today' => ( 0 !== (int) self::$_options['today'] ),
);

// Apply filter to allow modification of dashboard config.
$cfg = apply_filters( 'statify__dashboard_config', $cfg );

(basically 1 additional line so far, just merged the 3 existing variables into an array)

[Zodiac1978]

This is, why I would opt for a filter instead of a UI to separate these values. If you only run the statify plugin, there is no benefit in separating those values.

There is a use case. People could want to check today, yesterday, last week, last month, last year values (or similar), like in some of the other widgets seen in #119

[patrickrobrecht]

In my tests, the option "period of data display in the dashboard" (days_show) is not saved - it is 14 days - even after the bugfix for the wrong file path.