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.
Comment | File | Size | Author |
---|---|---|---|
#59 | undefined-index-in-_color_rewrite_stylesheet-1236098-59.patch | 481 bytes | viniciusrp |
#44 | drupal-1236098-44-undefined-color-index.patch | 2.14 KB | geek-merlin |
Comments
Comment #1
bowersox CreditAttribution: bowersox commentedSolutions
The best solution is a one-line change to color.module:
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():
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.
Comment #2
bowersox CreditAttribution: bowersox commentedCode 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:
Replace THEME with the machine name of your theme.
Comment #4
tim.plunkettTagging.
Comment #5
mgiffordJust 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
Comment #6
Devin Carlson CreditAttribution: Devin Carlson commentedI'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.
Comment #7
adriancotter CreditAttribution: adriancotter commentedI'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).
Comment #8
tim.plunkettComment #9
kkuhnen CreditAttribution: kkuhnen commentedFor 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.
Comment #10
Devin Carlson CreditAttribution: Devin Carlson commentedI'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!
Comment #11
bowersox CreditAttribution: bowersox commentedThe patch looks good. This can go into 8.x and then 7.x.
Comment #12
catchThis 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).
Comment #13
tingdongc CreditAttribution: tingdongc commented#6: include-newly-added-colorable-elements-1236098.patch queued for re-testing.
doesn't work for me. bartik used.
Comment #14
griz CreditAttribution: griz commentedDoesn't work for me either.
Comment #15
misthero CreditAttribution: misthero commentedpatch doesn't work for me either, the only fix was adding "base" to the color fields replacing "bg"
Comment #16
onewomanbiz CreditAttribution: onewomanbiz commentedFor 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.
Comment #17
markhalliwell.
Comment #18
markhalliwellComment #19
jlporter CreditAttribution: jlporter commentedThis function has been refactored in 8.x. This is now a 7.x only issue.
Comment #20
jlporter CreditAttribution: jlporter commentedAttached screenshot of 8.x working as intended. I manually added the Fireeeee color set.
Comment #21
jlporter CreditAttribution: jlporter commentedI was able to reproduce d8 not showing new *fields*. Patch attached that fixes that thanks to @markcarver
Comment #22
jlporter CreditAttribution: jlporter commentedComment #23
markhalliwellAwesome! 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.
Comment #25
npoku CreditAttribution: npoku commentedI simply reinstalled my theme and got it working.
'
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
Comment #26
Lams CreditAttribution: Lams commentedDrupal 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)
Comment #27
xeeshangulzar CreditAttribution: xeeshangulzar commented6: include-newly-added-colorable-elements-1236098.patch queued for re-testing.
Comment #29
nerdoc CreditAttribution: nerdoc as a volunteer commentedany progress on this? I am using the "skeleton" theme - and by now the colors seem to be "random" after saving.
Comment #30
DuneBL#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
Comment #32
hobbes_VT CreditAttribution: hobbes_VT commented#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!
Comment #35
rwam CreditAttribution: rwam commentedThe 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.
Comment #37
lexhoukComment #38
timisoreana CreditAttribution: timisoreana commentedI've tested patch from #37 and it's looking good.
Comment #40
ddrozdik CreditAttribution: ddrozdik as a volunteer and at FFW for Open Y commented#37 works well. I've tested it, no notices anymore.
Comment #41
alexpottThe patch in #37 is a different fix than the one in #21 and there is still no test that @catch asked for in #12 by @catch.
Comment #43
geek-merlinDebugged this and as i grok it the previous patches are only bandaids.
As @joachim noted in the dup #789554-6: Notice: Undefined index: base in _color_rewrite_stylesheet() in line 437, and here in #9, it appears in *any* theme that does not declare a 'base' key in its color configuration.
Current bartik is an instance of this, so reopened #781594: Bartik's color integration misses 'base' key.
Added a draft CR to use in patch.
Patch flying in that
* triggers deprecation errors for any theme that misses a required key
* adds a pragmatic workaround that guesses a missing base key by grepping 'bg' (which works for bartik and some other themes).
Background: Looking sharply at this code, we see that certain keys are required. (and why preceding patches are not enuff).
If we change the deprecation note to an error once we can, imho this is the test we need.
Comment #44
geek-merlinIgnore the last patch, this is the correct one.
Comment #47
milindk CreditAttribution: milindk as a volunteer commentedThis is something color module expect palette setting in your config color.theme.
.yml and schemes->default->colors in color.inc with repsect to text, link and base color schemes.
Ref: https://www.drupal.org/node/108459#stylesheets-css
I set text, link and base color schemes in color.inc and config in color.theme.
.yml and it do not show any notice.
Example:
Hope if it helps but not sure if we need to fix this in code.
Comment #50
partyka CreditAttribution: partyka at Argonne National Laboratory commentedNeed to manually test to see if this is still an issue in 8.x/9.x
Comment #53
salihcenap CreditAttribution: salihcenap commentedStill getting the same error. @milindk can you please tell us where to find "color.theme.yml"?
Comment #54
marvil07 CreditAttribution: marvil07 at Adapt commentedAs mentioned already on this thread, color module expect at least the color keys/variables/names added on the latest patches, i.e. base, lin
k, and text, so on any theme implementing it, they should be defined.
As per the new colors not being detected, the easier work-around it to remove the related configuration object, e.g.
drush cdel color.theme.yourthemename
.I will keep the patch in NW status, and I would suggest to not try to guess, but instead document the needed keys, and maybe verify they are
set if the theme has color integration enabled, e.g. do not let enable the theme if that is missing.
I am also removing the Novice tag, since it changes do not feel trivial.
Finally, I have re-closed #789554-23: Notice: Undefined index: base in _color_rewrite_stylesheet() in line 437 as duplicated of this one.
Comment #55
marvil07 CreditAttribution: marvil07 at Adapt commentedLinking the duplicate.
Comment #58
quietone CreditAttribution: quietone at PreviousNext commentedColor has been removed from core, #3270899: Remove Color module from core.
Comment #59
viniciusrp CreditAttribution: viniciusrp at Open Social commentedI recreated the patch #37 to be compatible with drupal/color instead of drupal-core.