Closed (fixed)
Project:
Charts
Version:
7.x-2.0-beta2
Component:
Views integration
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 Jul 2013 at 00:38 UTC
Updated:
11 Aug 2013 at 13:11 UTC
Jump to comment: Most recent file
Comments
Comment #1
quicksketchIn the View configuration, do you have the field selected with a checkbox in the "Data" column? If you could post a screenshot of the configuration of your display format with the chart configuration open, that would help me reproduce this problem. As is, it looks like you might just have the view misconfigured.
Comment #2
quicksketchAnother way of saying this: what's displayed in the table is not necessarily what's used by the chart. In the chart configuration, you must select which fields will be used as chart data explicitly.
Comment #3
skyredwangI can confirm this bug. Below is my exported Views
Comment #4
bennos commentedattched my config.
Comment #5
bennos commentedMy first idead was "the SQL is wrong", but this is ok.
So I looked in the module a little bit.
Sorry here, I am not good in views coding.
charts_plugin_style_chart.inc filling the data array begins at line 152
you get the data by the $field_handler array.
this contains the unique ID.
But what I not see is
$field->contentarray or$field->rawto get the data from the field or something similiar from $row
greets bennos
Comment #6
quicksketchThanks @skyredwang for the confirmation. I suspect the problem here is that Drupal saves a value of "0" for unchecked checkboxes:
The format that is expected by the Views handler is shorter:
So I think all we need to do is run array_filter() on the options and the unexpected ones will be trimmed out. Could you guys try this patch and see if it helps?
Comment #7
quicksketchI've committed this patch as it seems to solve the problem. Please reopen if you're still experiencing the problem where the wrong field is being used to provide data.
Comment #8
quicksketchComment #9
quicksketchAfter reproducing #2051807: Notice: Undefined index: #type in charts_pre_render_element(), it looks like this issue is not solved. Incidentally, *that* problem may have been solved by my patch in #6, but the current problem still remains: User IDs are being used instead of the actual data.
Now it looks like this problem originates from using entity-based values. Charts module is reading the raw value from SQL queries when it builds its values. In the case of queries where data is not actually retrieved from a SQL query, but instead from fully-loaded entities, the data structure is different.
Comment #10
bennos commentedFor me the patch does not work.
patch applied and cleared all caches.
My data points still have the wrong value.
It is not the field value in the chart. The chart still uses the ID for the data point.
Comment #11
quicksketchOkay I think this patch should fix the problem. As I said in #9, "entity-based values" (or "entity-based field values" more accurately) are formatted in a way that requires additional effort. After looking at the Table display style some, it looks like in order to work with field values we need to render everything in the view all at once, then then loop through the rendered results. Previously we were just using the raw values or rendering a field one at a time.
Comment #12
quicksketchI think this patch has fixed the problem. I'll make a new beta for testing.
Comment #13
quicksketch2.0-beta3 is now available which should make Charts' integration with field-based values work well in Views.
Comment #14
bennos commentedworks
great! thx quicksketch.