Where you have this:

  'fields' => array(
    'wall' => t('Base background'),

you need to change "wall" to "base", or, at the very least add a "base" key to the array. Drupal's color module expects the existence of this array key. You probably won't notice this being an issue unless you start changing colors so you are on the "custom" setting instead of a preset color set.

I can't remember the exact problem that I had that caused me to come across this but I ended up tracing through the code with xdebug until I found this was the cause of my problem.

Comments

mermentau’s picture

mermentau commented

@Reg, I kind of volunteered to pick up the maintenance here so don't know the code by heart yet. Could you give a file name and line number and that would be a time saver for me. Thanks

tanitani’s picture

tanitani commented

File:
sites\all\themes\mayo\color\color.inc

line 28

$info = array(
  // Available colors and color labels used in theme.
  'fields' => array(
    'wall' => t('Base background'),
    'bg' => t('Page background'),

wall is referenced for each pre-defined color scheme below the above definition.

HTH,
Gábor

mermentau’s picture

mermentau commented
Status: Active » Closed (works as designed)

OK I see that the original developer of MAYO used 'wall' => t('Base background') instead of 'base' => t('Base background'), but I can't see any problems with custom color settings in two of my testing installations. I used "custom" and then edited "Base background". The change was applied to the colors.css that the color module creates. I also edited various other color settings in Settings>MAYO, and they were applied as designed.

While I see that the the key "wall" could have been more aptly named "base" I can't see where the color module expects it. The Bartik theme doesn't use it and seems to work fine.

Bottom line if I can't duplicate a problem or see some documentation as to the code being in error I'm reluctant to change it. I'm open to more information.

tanitani’s picture

tanitani commented

First of all, John, let me thank you for your quick responses.

I understand and agree with your approach to not fix something that is not broken.
However, this thing might be broken.
Please look at http://drupal.org/node/693504#comment-2514504

In my site any time I save the Mayo settings there exactly 100 error messages like this one:
Notice: Undefined index: base in _color_rewrite_stylesheet() (line 448 of C:\wwwroot\drupal\modules\color\color.module)

The above is NOT my message I copied it from http://drupal.org/node/1236098#comment-5013982, because I am in the process of deploying my site and do not want to cause any disturbances in the setup. The saving would create a new folder like the following:
Z:\xampp\htdocs\crossroad\sites\default\files\color\mayo-34e32893\colors.css
where the colors would revert to some set which I do not know where it comes from.

However, when I actually tried to fix the issue by replacing the "wall" with base I ended up with a white screen of death. Unfortunately I am very new to Drupal and have not worked with php for years.

Thanks,

Gábor

mermentau’s picture

mermentau commented

@tanitani, I think you must be careful when you research to check the version of the issue. The first one you mention is for Drupal 6. If you check Drupal 7 core issues for the color module you only see one open bug and it does not relate.

The second bug you linked to is for Drupal 8 which is still in very early development.

reg’s picture

reg commented

You need to change "wall" to "base". If you need proof, just go to the api documentation and look through the code for "_color_rewrite_stylesheet()". Even better look through all the code in color.module for the use of the base key. It will become obvious to you that that key is required to avoid errors and for the module to work properly under all circumstances - in Drupal 7 (along with all previous versions of Drupal I suspect.)

Yes, I got those errors from this theme in Drupal 7. I Traced the error (I'm a developer of many years with Drupal) back to the color module. If you want one last piece of evidence before talking any action, try finding another well used and robust theme that ~doesn't~ use the array key "base".

mermentau’s picture

mermentau commented

As I said in #3 Bartik doesn't use 'base' and I had looked at "_color_rewrite_stylesheet()". I'm open to the probability that you may be right since you have more experience than I do, but I just don't see anything causing issues. I realize you saw a problem, but you can't show me how to reproduce it.

I can't remember the exact problem that I had that caused me to come across this
reg’s picture

reg commented

Honestly, I am not going to undo my changes back to over a week ago to reproduce a problem to tell you exactly what the error message was and exactly what combination of factors triggered it. That could be 2 days work which is asking too much.

However it should be clear from these two lines in the _color_rewrite_stylesheet() function (not next to each other, I'm making it easy to see by removing the lines in between):

 $base = 'base';
        $chunk = _color_shift($palette[$base], $default[$base], $chunk, $info['blend_target']);

That with "$palette[$base]" (and $default[$base]) and $base being the word "base" that the key "base must exist in the arrays otherwise you will have an error (the error being: "Array key does not exists"). $palette is the palette the user chose in your color.inc file and $default is your default palette in your color.inc file.

However, PHP 5.2x and below is much more forgiving than PHP 5.3x so if you have a lower version that 5.3 you may not see an error message if with an error. Also, if you have various error checking suppressed or turned off (mostly warnings) then you may also not see it. As a developer, I make it my business to have all error reporting on so that I see any and all errors that crop up in code and I run 5.3 for the same reason.

As for Bartik, it is probably a bug in it that either hasn't been fixed or hasn't been reported yet. Alternatively, they might have made their theme in such a way that that particular bit of code is never triggered. If I was to guess it just hasn't been reported and I might raise the issue for them but I'll check the issue queue for it first just to see if it's a pending fix.

I can't really do anymore. If you still don't want to believe me no worries, all as I can suggest is get a programmer friend you trust to look at it and get a 2nd opinion. However, from a damage point of view look at it like this: it can't hurt your code at all to rename wall to base throughout all the files, it's a quick simple operation (I checked when I did the renaming, wall is only used for this one key and doesn't exist for anything else). So even if I was wrong, you will do no harm at worst. At best, you fix a bug. All for a minute or two of "search and replace".

reg’s picture

reg commented

FYI:

http://drupal.org/node/789554

Bartik is having the same problem however they are arguing whether it's a core problem or a Bartik issue. Until they change the core (color.module) to behave differently it's all themes issue (except themes that are part of the Drupal core like Bartik since they get to point fingers elsewhere) that doesn't use "base" as one of its keys.

I suspect the original developer of mayo looked at the Bartik code for a reference but never sifted through its issue queue so never saw that what he was doing would cause PHP errors.

mermentau’s picture

mermentau commented

@Reg, I consider myself a developer too, and I work with full error reporting on during development. You have been here long enough to know how this process is supposed to work. You just don't tell the maintainer

You need to change "wall" to "base".

and expect it to get done. You may be right, but the process requires someone to duplicate the issue so that the fix can be tested against that. It would not hurt to re-read "Making an issue report".

Honestly, I am not going to undo my changes back to over a week ago to reproduce a problem to tell you exactly what the error message was and exactly what combination of factors triggered it. That could be 2 days work which is asking too much.

If you don't have time to help reproduce the issue we will just have to let it go until someone can. I have invested time here too and I can't replicate the issue from what I have been given.

reg’s picture

reg commented

@bumpaw. Sorry, didn't mean to offend, I just thought it was obvious by looking at the code at:
http://api.drupal.org/api/drupal/modules--color--color.module/function/_...
that a base key was needed. I personally wouldn't need to reproduce the error to make such a change since even if you don't immediately produce an error the code clearly requires that key. Again, didn't mean to offend, just saw the obvious.

If you follow this post: http://drupal.org/node/789554#comment-3249466 you should be able to reproduce the error.
If you follow this post: http://drupal.org/node/781594#comment-2927864 you should also be able to reproduce the error.

Since it's really not going to be an issue unless someone adds a custom color to the css of a stylesheet (color.css or style.css I believe) that's not in the predefined palettes in your theme you can probably ignore it.

Also, even if you don't produce an error, the comment above the line:

// Not a pre-set color. Extrapolate from the base.
(at http://api.drupal.org/api/drupal/modules--color--color.module/function/_...)

implies, and is backed up if you just follow the code, that custom CSS colors will not be "shifted" as they should be with that key missing since the color system won't have a "base" from which to determine the shifting.

mermentau’s picture

mermentau commented

Committed a change of key 'wall' to 'base' in mayo/color/color.inc and made the corresponding change in mayo/color/preview.js. A problem will arise unless after updating the theme the variable color_mayo_palette is not deleted, and allowed to be rebuilt by Save Settings in Administration>Appearance>Settings for Mayo.

It appears that the color.module looks at the array color_mayo_palette in the database variable table, and if your new key (in this case 'base') is not in there it causes an undefined index error and the field will be missing in the color settings for your theme. This behavior is tied to the color module.

tanitani’s picture

tanitani commented

Thank you -- I encountered the error you just described a couple of weeks ago, and of course having no idea how to trace and debug in this environment I just decided to roll back.

DELETE FROM `cpc_variable` WHERE `name` = 'color_mayo_palette' COLLATE utf8_bin LIMIT 1;

(When saving the theme right now I receive 108 error messages because of the wall - base naming conflict - so thank you again.)

Gábor

It works like a charm - I LIKE!!

IWasBornToWin’s picture

IWasBornToWin commented

I just upgraded to latest dev and my base color on site is gone. I get this error message;

Notice: Undefined index: base in _color_rewrite_stylesheet() (line 475 of /home/iwasborn/public_html/growtogive.com/modules/color/color.module).
Notice: Undefined index: even in _color_rewrite_stylesheet() (line 475 of /home/iwasborn/public_html/growtogive.com/modules/color/color.module).

Does this have anything to do with this issue?

IWasBornToWin’s picture

IWasBornToWin commented

I rolled back to previous version and my base color is still gone and i get these messages; weird.

Notice: Undefined index: wall in _color_rewrite_stylesheet() (line 475 of /home/iwasborn/public_html/growtogive.com/modules/color/color.module).
Notice: Undefined index: even in _color_rewrite_stylesheet() (line 475 of /home/iwasborn/public_html/growtogive.com/modules/color/color.module).

IWasBornToWin’s picture

IWasBornToWin commented

I just noticed two things;

1. My current version and re-rolling back to prior version do not give me an option to set a base color. The "base" field isn't even in the settings. I looked in your color.inc file and I see it there but not in settings.

2. The error I posted in #15 is referring to the color module in modules/color, not any "color" file in Mayo folders. I expect this is core color stuff and probably for handing theme colors but thought I would point it out. Not sure if that has anything to do with Mayo not giving me an option to set a base color or not?

I've even tried changing page-wrapper color and all sorts of things to get a base color back...but I only get white. I changed the base.png image from white to another color and that didn't do anything either.

I apologize if this is in the wrong issue thread?

IWasBornToWin’s picture

IWasBornToWin commented

I found the problem to my base color issue.

In the sites/all/files/color/mayo/color.css file it had this code with missing base color

body,
#page-wrapper {
  background-color: ;
  color: #434342;

I inserted a color and it works fine. However, there is still not "base" color setting in the color choices on settings page.

IWasBornToWin’s picture

IWasBornToWin commented

Every time I change any settings, the color.css file gets rewritten and leaves out the base-background in the code. I opened up a new issue as a code bug report here http://drupal.org/node/1454490

reg’s picture

reg commented

Some of these problems I am reading here may have nothing to do with the theme but a Drupal core limitation I identified. Please check out this issue too: http://drupal.org/node/1396156 , it might help some of the above. If you find that that is an issue for you please make a comment so the core team knows it's a common problem.

euclid.h’s picture

euclid.h
Euclid.H
commented
Title: "wall" should be "base" » base background
Assigned: Unassigned » euclid.h
Priority: Normal » Critical

Good day everybody my Q: is how can i change base background in mayo theme from color to image ?

euclid.h’s picture

euclid.h
Euclid.H
commented

Good day everybody my Q: is how can i change base background in mayo theme from color to image ?

i need help am new in drupal world.
.
.
.
.