The values of the Goal Plugin are floats (e.g. 1.53% conversions).
The sparkline of conversion rate and eventually overall revenue do not show up.
Correction: I got all sparklines showing up after this hack that converts all values to integers:
/core/Visualization/Sparkline.php method Piwik_Visualization_Sparkline->main() line 67, I add this after the foreach statement:
*$value = (int)($value100);**
The factor 100 does no harm to all other sparklines, because they are resized. I would be good to have this included in the next release.
Attachment: Sparklines fail
sparkline fail.PNG
Attachment:
index.php.png
Attachment: sparklines before hack
Capture-Piwik Web Analytics Reports - Mozilla Firefox.png
Attachment: sparklines after hack
Capture-Piwik Web Analytics Reports - Mozilla Firefox-1.png
Attachment: minimalistic debugging of feature point offset
patch-simple.txt
Attachment: debug of feature point offset and antialiasing
patch-antialias.txt
No, we already scale conversion ratios by 100. This is a bug in the sparkline-php library.
I'll sync up and see if a fix is still needed.
I var_dumped $this->data, and it was not scaled by 100. Are you sure this applies to Goal tracking too?
Do you convert (float) to (int) to work around the bug in sparkline-php?
Yes, I'm sure. The scaling is applied when the conversion rate is calculated and stored in the database.
(In [1822]) fixes #1137 - empty sparkline with floats
I svn up, and generated sparklines, but sparklines don't look good. I think that is how they used to look like before I manually patched the library, but the changes in [1822] probably reverted this.
See the attached screenshot. The points are many pixels off on the left which looks confusing.
Hi, why not using http://omnipotent.net/jquery.sparkline/ ?
pebosi: yes, I've already looked at that. At this time, I'm not going to change that.
Looking down the road, we might want to support both client and server-side chart generation:
(In [1884]) fixes #1137 - off-by-one in x-axis range
thanks Anthon. There is still a small offset in the green point but I think this has always been the case (see attached sparkline)
Near as I can tell, it's a scaling artifact. Sometimes noticeable, sometimes not.
The problem I initially reported is still not corrected in piwik 0.5.5, as the two uploaded screenshots prove.
The first shows piwik 0.5.5 as is,
the second shows the same statistics after I reapplied the patch described above:
/core/Visualization/Sparkline.php method Piwik_Visualization_Sparkline->main() line 67, I add this after the foreach statement:
*$value = (int)($value100);**
The bug is in the sparkline library itself. The sparkline library is converting all input first into a string, and then test if it is numeric.
According to http://ch.php.net/manual/fr/language.types.float.php#language.types.float.casting, php is using the decimale separator defined in the current locale when converting to string, but only recognizes '.' as decimal separator while testing is_numeric.
My backend is configured in the locale fr_FR, which means that (string)1.5 converts to '1,5'.
The solution is to comment out the first two lines in libs/sparkline/lib/Sparkline_Line.php of the method SetData:
$x = trim($x);
$y = trim($y);
or to change them to (which will be a more general solution):
if(!is_numeric($x)){
$x = trim($x);
}
if(!is_numeric($y)){
$y = trim($y);
}
(In [1982]) fixes #1137 - thanks Lorenz (lmeyer) to debugging this locale issue; reported upstream in https://sourceforge.net/tracker/?func=detail&aid=2975415&group_id=122936&atid=694962
I created two patches that correct the offset issue.
The first patch (patch-simple.txt) only corrects the bug in the sparkline lib (and your workaround in Sparkline.php)
The second patch (patch-antialias.txt) pretty much rewrites $Sparkline->RenderResampled and also antialiases the feature points.
I like real circles better than the losanges of piwik sparklines, but it is up to you to decide...
(In [1983]) refs #1137 - fixing various off-by-one errors in drawing feature points; credit: lmeyer