@anonymous-matomo-user opened this Issue on January 25th 2010

The current view of the plugins used are meaningless.
You can see in the graph how many people support this plugin but you have to look to another widget to see the count of people traced.

If i see it right in ticket #852 there are no detection for IE.


  • put percentage of visitors handling the plugin instead of number of visitors. This percentage would be based on all visits, excluding IE visits.
  • Add a note below the datatable explaining that Plugins detection doesn't work in IE and therefore the report is extrapolated based on non IE browsers.
    Keywords: browser, plugin, chart
@mattab commented on July 13th 2010 Member

Attachment: after changes

@mattab commented on July 14th 2010 Member
@robocoder commented on January 25th 2010 Contributor

Requires changes to Visualization and ViewDataTable classes to support this chart type and
data stream (Similar to #397.)

@mattab commented on February 11th 2010 Member

Renaming and increasing priority.

It would be easy to change the current graph and display percentage of users that have the plugin enabled. This would fix the main issue of this report.

@sgiehl commented on July 10th 2010 Member

(In [2469]) refs #1125 now shows table instead of bar chart, displaying percentage of visits (excluding ie visits)

@sgiehl commented on July 10th 2010 Member

would anyone please add the mentioned note to the view script/translation and close this ticket.
I have problems with finding a suitable phrase for that in english (only got some in german...)

@mattab commented on July 12th 2010 Member

Message proposal: Note: Plugins detection doesn't work in Internet Explorer. This report is based only on non IE browsers.

patch looks good!

@mattab commented on July 12th 2010 Member

(In [2474]) Refs #1125

  • fixing integration tests
  • fixing bug when no visit (called function on non object)
    Refs #818: all_tests.php is now green on my box
@mattab commented on July 13th 2010 Member

(In [2493]) Fixes #1125

  • column translation was empty
  • displaying message in footer + adding general feature to display footer messages
  • fixing sorting was not working on the % Visits column because filter was queued and the Sort filter was executed before the new column was added. Instead, just applied the filter directly in API.
@mattab commented on July 14th 2010 Member

Bug, see screenshot: cookie detection works on IE therefore should not remove IE users (or % visits is higher than 100%)

@sgiehl commented on July 14th 2010 Member

I guess the best solution to get representive values for all is to calculate the cookie value including IE users and the rest without those. Or shall we include ie to all values?

@mattab commented on July 14th 2010 Member

sounds good - I think we can leave the messaging as it is.

@sgiehl commented on July 16th 2010 Member

(In [2519]) fixes #1125 include ie users for cookie value calculation, now works for multiple periods like last10

@sgiehl commented on July 16th 2010 Member

Wasn't as easy as I thought. The last change for the API-function didn't work for multiple periods like last10. So I had to change a bit more than only the cookie value calculation. Maybe anyone sees an easier way of doing this...

@mattab commented on July 17th 2010 Member

code is too complicated I agree. Maybe this would be easy by writing a DataTable Filter? The Filter will access a standard datatable and therefore can contain the simple code contained currently in your API function.

The datatable array will simply apply the filter to all datatable inside it. It would in this case update all stats, except cookies.

Do you see what I mean?

@mattab commented on July 20th 2010 Member

(In [2595]) Refs #1125

  • Example of a simple filter to apply to the datatable in the API method. Filters will automatically work on all dataTable are are easy to write /maintain
  • Fixing tests
@sgiehl commented on July 22nd 2010 Member

java detection seems to work in IE, too. see #1496

@mattab commented on July 22nd 2010 Member

we can do this a bit later as code works as is. Let's focus on the secret project ;-)

@robocoder commented on August 30th 2010 Contributor

(In [3031]) refs #1125 - partially revert r2595 ... the "%" (unit) is inconsistent with revenue (no unit); refs #1562

@robocoder commented on September 27th 2010 Contributor

What's the remaining "todo" on this ticket?

@sgiehl commented on September 27th 2010 Member

Code works as it is, but code complexity is still a bit too hight. see https://github.com/piwik/piwik/blob/master/plugins/UserSettings/API.php#L93

Maybe that could be solved a better way by using an tablefilter. Problem is that some plugins are treated a special way, as their detection does work in IE aswell.

@mattab commented on November 16th 2010 Member

I'll take a look at the code and see if we can write a shorter version (maybe reusable). See also #1816

@mattab commented on January 12th 2011 Member

it seems sometimes the % visit might be wrong: http://wishuload.de/images/19232-42-2011-01-12142443.png

@mattab commented on March 4th 2011 Member

See #2133 for code improvement now affecting another code

Closing this ticket as request was implemented, SteveG your next patch will be closed a lot faster I promise :)

This Issue was closed on March 4th 2011
Powered by GitHub Issue Mirror