When new colors choices are added to a theme, they do not appear on the theme settings form. This causes an error notice and user confusion.

The problem happens when using a custom color palette on the theme settings form (/admin/appearance/settings/THEME). As newer versions of a theme add support for more color-izable items, there is currently no way to get the new color fields added into this form. The form is built from the previously saved color_THEME_palette variable. Because that variable array does not contain the new colors, those fields are not added to the form. When the user attempts to save the form they get this error:

Notice: Undefined index: NEW-COLOR-NAME in _color_rewrite_stylesheet() (line 432 of /path/to/drupal7/modules/color/color.module).

This error continues to appear each time the user saves the form. The only way for the new colors to get added into the color_THEME_palette variable is for the user to switch to one of the pre-set palettes. If the user changes to a pre-set palette or the Default palette, that full set of colors is saved. At that point the error will not happen again, and the user will now get a field for each of the colors including the new ones. However, by switching to one of the pre-set palettes, the user will have lost all of their custom color choices and will need to paste in all of their color values again.

Over time as Bartik or other themes make more items color-izable, users will experience this error. Certainly contributed themes experience this problem. Here are a few issues where this is likely the underlying problem: http://drupal.org/node/1045348#comment-4168404, https://drupal.org/node/1235264, http://drupal.org/node/1038236, http://drupal.org/node/781594. Some of those are also confounded by problems with $base, but some of those are certainly a result of this issue.

There are a few possible solutions to this problem which I'll describe in a comment.

CommentFileSizeAuthor
#37 undefined-index-in-_color_rewrite_stylesheet-1236098-37.patch557 byteschmez
#21 color-newFieldsMissing-jim0.patch493 bytesjlporter
FAILED: [[SimpleTest]]: [MySQL] 57,917 pass(es), 24 fail(s), and 15 exception(s). View
#20 color pallete 8-x.png93.55 KBjlporter
#6 include-newly-added-colorable-elements-1236098.patch513 bytesDevin Carlson
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch include-newly-added-colorable-elements-1236098.patch. Unable to apply patch. See the log in the details link for more information. View
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

bowersox’s picture

Solutions

The best solution is a one-line change to color.module:

  function color_get_palette($theme, $default = FALSE) {
    // Fetch and expand default palette.
    $info = color_get_info($theme);
    $palette = $info['schemes']['default']['colors'];    

    // Load variable.
-   return $default ? $palette : variable_get('color_' . $theme . '_palette', $palette);
+   return $default ? $palette : variable_get('color_' . $theme . '_palette', $palette) + $palette;
  }

This solution will take effect when the theme settings form is built and displayed. Even if the saved custom palette does not include all the colors, the default values will be added to the array.

Another possible solution would be to add in the new colors when the form is saved instead. This solution is not as good because it would not show users the new colors. They would only see new colors the _second_ time they used the form (after the form is saved once). That said, here is the possible change to color.module function color_scheme_form_submit():

  // Resolve palette.
  $palette = $form_state['values']['palette'];
- if ($form_state['values']['scheme'] != '') {
    foreach ($palette as $key => $color) {
      if (isset($info['schemes'][$form_state['values']['scheme']]['colors'][$key])) {
        $palette[$key] = $info['schemes'][$form_state['values']['scheme']]['colors'][$key];
      }
    }
    $palette += $info['schemes']['default']['colors'];
- }

I don't understand why that If statement was ever there. It causes the code to not run for 'Custom' color palettes. I don't know why that would ever be the desired behavior.

bowersox’s picture

Code work-around

Until this problem is fixed in core, below is sample code for a work-around that could be added to a theme in theme-settings.php:

function THEME_form_system_theme_settings_alter(&$form, &$form_state) {
  THEME_theme_settings_add_new_colors();
  return $form;
}
function THEME_theme_settings_add_new_colors() {
  // Add in any new colors that are defined in default scheme
  // but are not defined in the saved palette values.
  // Supplements logic in color.module color_scheme_form().
  $theme = 'THEME';
  $info = color_get_info($theme);
  $names = $info['fields'];
  $palette = color_get_palette($theme); //calls variable_get
  $default = color_get_palette($theme, TRUE);
  $new = array();
  foreach ($default as $name => $value) {
    if (!isset($palette[$name]) && isset($names[$name])) {
      $palette[$name] = $default[$name];
      $new[] = $names[$name];
    }
  }
  if (count($new)) {
    drupal_set_message(t('One or more new colors are now available: @colors',
      array('@colors' => implode(', ', $new))));
    variable_set('color_' . $theme . '_palette', $palette);
  }
}

Replace THEME with the machine name of your theme.

tim.plunkett’s picture

Title: Theme settings form should include new colors » Theme settings form should include newly added colorable elements
Version: 7.x-dev » 8.x-dev
Issue tags: +needs backport to D7

Tagging.

mgifford’s picture

Just adding link back to duplicate issue that was closed deferring to this one #789554: Notice: Undefined index: base in _color_rewrite_stylesheet() in line 437

Devin Carlson’s picture

Status: Active » Needs review
FileSize
513 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch include-newly-added-colorable-elements-1236098.patch. Unable to apply patch. See the log in the details link for more information. View

I've run into this issue a few times before but was never sure of exactly what the cause of it was.

If this passes, I'll test this out and report back.

adriancotter’s picture

Version: 8.x-dev » 7.7

I'm having trouble getting color.module working in a zen based theme (with the color code ported over from Bartik, but I did add an extra color setting).

These two fixes were suggested as solutions to my problems, but neither seems to have any effect. When I change the color, the color appears in the previews of the appearance settings, but the stylesheet is apparently not being changed -- the site is still in the original color.

These are the notices and warnings I am getting:

Notice: Undefined index: type in drupal_get_css() (line 2934 of C:\wwwroot\drupal\includes\common.inc).
Warning: ksort() expects parameter 1 to be array, null given in drupal_group_css() (line 3047 of C:\wwwroot\drupal\includes\common.inc).
Notice: Undefined index: type in drupal_group_css() (line 3059 of C:\wwwroot\drupal\includes\common.inc).
Notice: Undefined variable: group_keys in drupal_group_css() (line 3079 of C:\wwwroot\drupal\includes\common.inc).
Notice: Undefined index: type in drupal_aggregate_css() (line 3119 of C:\wwwroot\drupal\includes\common.inc).
Notice: Undefined index: type in drupal_pre_render_styles() (line 3239 of C:\wwwroot\drupal\includes\common.inc).
Notice: Undefined index: base in _color_rewrite_stylesheet() (line 448 of C:\wwwroot\drupal\modules\color\color.module).

tim.plunkett’s picture

Version: 7.7 » 8.x-dev
kkuhnen’s picture

For anyone who copied color code from another theme (ie: Bartik, in my case) --

I applied this patch, and was still getting errors like "Notice: Undefined index: base in _color_rewrite_stylesheet()"
In order to fix the error, I had to add a color field in color.inc named 'base'. Bartik does not have a field named as such. Once I added this, error messages went away.

Devin Carlson’s picture

Status: Needs review » Reviewed & tested by the community

I've tested this with a variety of colorable themes using the fix provided in #1 (implemented in the patch in #6) and it solves the issue.

As #1 described, without returning $palette, if you add new colorable items to a theme they will not be displayed under the custom color scheme if the user was already using a custom color scheme.

I'm marking this RTBC because my patch simply implemented the fix in #1, I've tested this with themes that support color module and the color module itself is not very popular (from my research) and does not have a maintainer to contact for review.

Please change the issue status if you think otherwise!

bowersox’s picture

The patch looks good. This can go into 8.x and then 7.x.

catch’s picture

Status: Reviewed & tested by the community » Needs work

This could use two things:

- an automated test so it doesn't get broken again.

- an inline comment to explain why we're adding the + $palette (the original summary in this issue would be a good base for that).

tingdongc’s picture

Status: Needs work » Needs review

#6: include-newly-added-colorable-elements-1236098.patch queued for re-testing.
doesn't work for me. bartik used.

griz’s picture

Doesn't work for me either.

misthero’s picture

patch doesn't work for me either, the only fix was adding "base" to the color fields replacing "bg"

$info = array(
  // Available colors and color labels used in theme.
  'fields' => array(
	'base'=> t('Background'), // labelled "background"
	'sitetitle'=> t('Site Name'),
        'sponsors' => t('Sponsor background'),
        ......
onewomanbiz’s picture

Title: Theme settings form should include newly added colorable elements » Theme settings form should include newly added colorable elements, error color.module

For anyone, using the color module within theme parameters to customizes colors and getting errors similar to the following after modifications:
Notice: Undefined index: base in _color_rewrite_stylesheet() (line 479)...

Patch solution #1 works for Drupal 7.X using skeletontheme.

Some reported trouble still and could appear to be the case. In order for it to take effect, it was necessary to run the update script. For good hygiene, I ran cron and cleared cache as well.

markcarver’s picture

markcarver’s picture

Title: Theme settings form should include newly added colorable elements, error color.module » Notice: Undefined index in _color_rewrite_stylesheet()
jlporter’s picture

Version: 8.x-dev » 7.x-dev
Status: Needs review » Needs work

This function has been refactored in 8.x. This is now a 7.x only issue.

jlporter’s picture

FileSize
93.55 KB

Attached screenshot of 8.x working as intended. I manually added the Fireeeee color set.

jlporter’s picture

Version: 7.x-dev » 8.x-dev
FileSize
493 bytes
FAILED: [[SimpleTest]]: [MySQL] 57,917 pass(es), 24 fail(s), and 15 exception(s). View

I was able to reproduce d8 not showing new *fields*. Patch attached that fixes that thanks to @markcarver

jlporter’s picture

Status: Needs work » Needs review
markcarver’s picture

Awesome! Patch looks great :) Will need to manually test this again once it comes back green.

Issue summary still needs an update, @jlporter and I had a hard time figuring out exactly what the issue was actually about at first.

Status: Needs review » Needs work

The last submitted patch, color-newFieldsMissing-jim0.patch, failed testing.

npoku’s picture

I simply reinstalled my theme and got it working.

  1. I noticed the default theme garland wasn't giving me errors, but my new theme was
  2. '

  3. After I re-installed theme I set the color preset of theme to an already available option - it worked
  4. And then set it to "custom" (after step #above), made changes and then saved it.
  5. Hope this helps someone.

    My issue might have been i tried to alter CSS manually, which first caused the issue.

    On D7 if anyone wanted to know

Lams’s picture

Drupal 7: I was not able to get new colorable elements to work properly because of color.module: line 475 (Check if this is one of the colors in the default palette.)

The fix for this: make sure the color you have defined in the css file (the one specified in $info['css'] ) is the same color as the one in $info['schemes']['default'] (your default color profile)

xeeshangulzar’s picture

The last submitted patch, 6: include-newly-added-colorable-elements-1236098.patch, failed testing.

nerdoc’s picture

any progress on this? I am using the "skeleton" theme - and by now the colors seem to be "random" after saving.

DuneBL’s picture

#6 doesn't work for me... still get "Undefined index: base in _color_rewrite_stylesheet when updating color"

But I was able to resolve this issue by making sure I had a a base, text and link variable set for each color palette in color.inc

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hobbes_VT’s picture

#9 saved me lots of time figuring out what was going on. Did my first color module implementation for a theme I developed, and started out with what I found in Bartik -> as kkuhnen pointed out, if "base" is missing in the field definitions, it throws this error.
I just renamed my background field to "base" and works like a charm.
Thanks kkuhnen!

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

rwam’s picture

The notice still exists in version 8.3.2. And the current solution for me is the same like mentioned in #9: using of a field with the key base and it works fine. If there is no fix available or planned, it should mentioned on the official documentation.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

chmez’s picture

timisoreana’s picture

I've tested patch from #37 and it's looking good.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ddrozdik’s picture

Status: Needs review » Reviewed & tested by the community

#37 works well. I've tested it, no notices anymore.