@anonymous-piwik-user opened this Issue on February 1st 2010

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.

@mattab commented on March 4th 2010 Owner

Attachment: Sparklines fail
sparkline fail.PNG

@mattab commented on March 5th 2010 Owner

Attachment:
index.php.png

@anonymous-piwik-user commented on March 22nd 2010
@anonymous-piwik-user commented on March 22nd 2010
@anonymous-piwik-user commented on March 23rd 2010

Attachment: minimalistic debugging of feature point offset
patch-simple.txt

@anonymous-piwik-user commented on March 23rd 2010

Attachment: debug of feature point offset and antialiasing
patch-antialias.txt

@robocoder commented on February 2nd 2010 Contributor

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.

@anonymous-piwik-user commented on February 2nd 2010

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?

@robocoder commented on February 2nd 2010 Contributor

Yes, I'm sure. The scaling is applied when the conversion rate is calculated and stored in the database.

@robocoder commented on February 2nd 2010 Contributor

(In [1822]) fixes #1137 - empty sparkline with floats

@mattab commented on March 4th 2010 Owner

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.

@pebosi commented on March 4th 2010 Contributor
@robocoder commented on March 4th 2010 Contributor

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:

  • Client: to offload processing from the server and loosen the installation requirements (gd).
  • Server: for email/pdf reports.
@robocoder commented on March 4th 2010 Contributor

(In [1884]) fixes #1137 - off-by-one in x-axis range

@mattab commented on March 5th 2010 Owner

thanks Anthon. There is still a small offset in the green point but I think this has always been the case (see attached sparkline)

@robocoder commented on March 5th 2010 Contributor

Near as I can tell, it's a scaling artifact. Sometimes noticeable, sometimes not.

@anonymous-piwik-user commented on March 22nd 2010

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);**

@anonymous-piwik-user commented on March 23rd 2010

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);
}

@robocoder commented on March 23rd 2010 Contributor

(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

@anonymous-piwik-user commented on March 23rd 2010

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...

@robocoder commented on March 24th 2010 Contributor

(In [1983]) refs #1137 - fixing various off-by-one errors in drawing feature points; credit: lmeyer

This Issue was closed on March 24th 2010
Powered by GitHub Issue Mirror