Under color I can use "Primary", "Secondary" or "Custom". When I use custom I am not able to see my changes reflected on any of my charts or even the testing one for that matter. I have tried passing the color variable in the chart array and that did not work either.

Comments

Andrzej7’s picture

Andrzej7 commented

I have the same problem

Subscribing

brandon.dixon’s picture

brandon.dixon commented

I was able to change the colors by going into the URL creation and adding them in myself

Edit the google_charts.inc file and look for this return line:

// If its all ok, build the HTML img tag
return '<img src="http://chart.apis.google.com/chart?chco=00CD00,FF0000&amp;'. implode('&amp;', $chart) .'" />';

So you can see that I added an argument onto the api call:
chco=00CD00,FF0000&

This is by no means a fix, but if you needed the color to change then it will work for the time being.

ezra-g’s picture

ezra-g commented
Title: Can't change default colors » Custom Colors overwritten, not sent to Views

I noticed that setting the color palette to "Custom" on the views_ui_edit_display_form display form, validation fails, telling me that the color palette field is required, even though I selected "Custom".

After some further digging, it seems like charts only saves one color configuration at a time, meaning that if you change the site-wide color settings at admin/settings/charts and change the custom scheme and save it, the value is preserved, but if you then chose either the Primary or Secondary pallete, the custom settings are overwritten :(.

Looking further, _charts_settings_color_palette(), which populates the values in the palette select that's used when configuring the Views display, doesn't even look for custom values in the database -- it is hardcoded to set the custom value to '', which of course won't pass validation for a required field:

function _charts_settings_color_palette() {
  return array(
    '#ffffff,#000000,#ff0000,#00cc00,#0066b3,#ff8000,#ffcc00,#330099,#990099,#ccff00' => t('Primary'),
    '#ffffff,#000000,#ff6600,#009999,#1919b3,#ffb200,#ffff00,#660099,#e60066,#33ff00' => t('Secondary'),
    '' => t('Custom'),
  );
}

It seems like a comprehensive fix would allow a custom palette to be preserved even if the site-wide setting is changed -- this would support use cases where multiple color schemes are in use at one time on different charts -- and also prevent wiping out admin-entered data, which seems like a usability problem. Doing so would require changing the way the charts module stores and retrieves the currently configured color scheme in one or more places.

A quick fix for my original use case -- using the custom color scheme in a views display -- would be to just use the single site-wide setting, whichever one it is, and remove this option from the views display form, but this seems like a quick fix that's not really right.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Closed (won't fix)

Please reopen if this problem exists in the D7 version of the module. The 6.x-1.x version of the module is no longer being updated.