In default color set or if I choose another one or even if use custom color set, all regions are white. I cannot change any color. No problem when adding or removing the logo. Only problems are with the colors.
NB: Garland 7.8 works (ie. display is correct) but only in "Blue lagoon" (Default) color set. Other set leads to text only design.

Server info:
Apache version 2.2.19
PHP version 5.2.17
MySQL version 5.1.56-log
Architecture x86_64
Operating system linux

Folders configuration:
chmod 0705 for folders and 0604 for files (all subdirectories) - NB: I don't know if it is a good configuration but there is no "How to setup chmod when using Drupal" for dummies on drupal.org and it is very difficult to find simple information about this :)

CommentFileSizeAuthor
#26 Capture.PNG50.08 KBraeasah

Comments

antcw’s picture

I've just seen exactly the same thing. Changing the colour scheme creates a directory with full access in:

default/files/color/bartik-629802a3

However the directory doesn't contain any files. Should it?

This is on a new install of drupal 7.8, with no custom modules enabled.

brightbold’s picture

Assigned: Unassigned » brightbold
brightbold’s picture

Assigned: brightbold » Unassigned

When I attempted to reproduce this on a clean installation on a local WAMP server, it works as designed. Inside the default/files/color/bartik-whatever directory, it has created two files: color.css and logo.png. So I think this reinforces your theory that the problem is related to file permissions. Try 666 instead.

S3bastien’s picture

Well, mavenhosting server doesn't allow 666 it seems - tried several combinations and only allowed (and working to run drupal) is chmod 0705 for folders and 0604 for files (all subdirectories)
with Drupal 7.7 it works ok but not with 7.8, it seems

couturier’s picture

Have you tried just creating your own Bartik sub-theme with your own set of chosen colors? I wonder what would happen if you disabled the Color module in core and just configured a colors.css file with the colors you want? Not the best solution, I realize.

By the way, even if you were to get the Color module working properly and if you are created a sub-theme of Bartik that relied on the Color module, you currently cannot change the colors of the borders using the Color module. You have to change border color manually in the CSS file.

wreckage’s picture

Hello all.

I have the same/similar issue with Bartik.

I have a fresh upload of Drupal 7 onto my web host and made it a sub-domain so I can work on the site, but I cannot change the colour of the Bartik theme. Only the standard 'Blue Lagoon' works. No other pre-configure colour schemes work, and any custom colours merely show white.

I have made sure all directory permissions are '777'.

Can anybody point me to a possible reason for this, as I simply cannot progress without setting the base theme colours.

All help appreciated.

Thank-you.

couturier’s picture

Are you sure that the color module is enabled? You might want to check what the cache setting are for code changes from your server as well as from your browser. Start by clearing the caches in Drupal under Configuration > Performance. Then, make sure your host's server is not caching any CSS code, and if it is, that you have access to clear it. And finally, clear your browser cache as well.

penguinbe’s picture

I think I found the problem, not the solution
The files created while changing are owned by the apache user.
For me that means I can't even take ownership or delete the files since I don't own the server.
This is for drupal 6 - >8

wreckage’s picture

Hello, couturier.

Yes, I have flushed the browser cache and also Drupal's cache.
I don't know how to make sure my host's server is not caching any CSS code, but I'm also experiencing weird behaviour with different browsers - as below:

Here's what happens using three different computers:

Home Desktop:

FireFox: Can log in to my site as admin but any colour change appears white except Blue Lagoon.
Chrome: Cannot log in and any previous colour changes appear white, except Blue Lagoon.
IE : Cannot even log in to my site – colour change appears white except Blue Lagoon.

Home Laptop (on same network):
----------------------------------------------

FireFox: Can log in to my site as admin but any colour change appears white.
Chrome: Cannot log in and any previous colour changes appear white, except Blue Lagoon.
IE : Cannot even log in to my site – previous colour change appears white.

Work Desktop (Corporate LAN)
----------------------------------------
FireFox: CAN log in but any any previous colour changes appear white, except Blue Lagoon.
Chrome: CAN log in but any previous colour changes appear white, except Blue Lagoon.
IE : Cannot even log in to my site.

When the logins are unsuccessful in Chrome and IE, I don't get any errors - the page simply refreshes to the login prompt.

Any ideas would be gratefully accepted, as I am about to give up on Drupal and re-write the site manually (if I don't just start sitting naked in the corner and dribbling first).

Cheers.

couturier’s picture

Like penguinbe said above, it could be that some of your files are "owned by the apache user," which makes changing or deleting certain files difficult or impossible on the particular server you are using. Your server may not allow you the permission to change those files. Please don't give up on Drupal just yet. You have too much to lose because the color changer is just one of many cool new features in Drupal 7 and you'll love it for years if you can just get past this first issue.

As to the log-in failures on various browsers, are you relying on auto-fill or are you manually typing in your username and password each time? You might want to print out your password in notepad and copy and paste it exactly so you are sure you are typing in the right password. I know that I've really had a hard time getting IE to completely flush its cache. You might make sure you have your settings set both on IE and Chrome to delete all cookies and other private data when you close your browsers, and that may help clear out the browsers to accept a log-in. That's just theory, though. The only log-in problems I've ever had were effective across all browsers.

It sounds like your hosting server might be at the root of the color problem since Blue Lagoon (the default colors), are the only ones that show up and changes are not being pushed through. I would first recommend trying out Drupal 7 locally so you can get an idea of what will really work. You can use Acquia Dev Desktop to create a local hosting environment on your own computer and develop your site locally. All your color changes should work just fine there. Then, you can push a copy of your finished site up to your live server.

Or, if the site you want is fairly simple, you can develop a Drupal 7 site for free at Drupal Gardens. If you like the results and want to put your own domain name on the site, you can upgrade to paid hosting for about $9 a month. However, I do not recommend Drupal Gardens if you have a lot of specialty features and modules that you want to incorporate. Drupal Gardens is just more for a brand presence online and the number of modules they support is a fixed amount.

If the results of your local development with Dev Desktop go well and you want to push the site up to better hosting than what is possibly creating some problems for you now, there are plenty of great hosting companies that provide the support you need. When I first started with Drupal, hosting that was not specialized to Drupal caused me a thousand problems, and switching to reliable hosting for Drupal was the best thing I ever did for my site and my sanity. Drupal is a workhorse and requires a tailored hosting environment. Even some of the big companies that "say" they do Drupal hosting may not really give you what you need. I would go with someone who specializes in Drupal-only hosting. My provider is Hosts of America, and this group is active in core Drupal development and hosts major Drupal business websites worldwide. Or, take a look at this list of Drupal hosts (be sure to click all categories at the top to see shared, enterprise, and managed hosting options). I'm curious to know how it goes for you. Stay encouraged! Drupal is great!

wreckage’s picture

Hello, and thank-you for your comprehensive and thoughtful reply.

Like penguinbe said above, it could be that some of your files are "owned by the apache user," which makes changing or deleting certain files difficult or impossible on the particular server you are using. Your server may not allow you the permission to change those files. Please don't give up on Drupal just yet. You have too much to lose because the color changer is just one of many cool new features in Drupal 7 and you'll love it for years if you can just get past this first issue.

You're right - it's far too early to 'give up' on Drupal. I really like what I see so far and will persevere with learning this interesting CMS.

The browser log-in issue is a strange one. I work as a computer techie and it's got me puzzled. Yes, I've emptied caches completely, tried typing/copying/Roboforming usernames and passwords all to no avail, but I will re-visit this issue and try to figure it out.

I initially started this Drupal project using MS WebMatix and Acquia Drupal, and still use that set-up as a test/comparison for the standard Drupal core I have on my web host. Of course, colour changes, etc., all work perfectly well on the Acquia installation.
I was advised earlier that it may be preferable to simply use the standard Drupal Core rather than face lagging behind in core/module updates, etc. using Acquia, and this made sense to me.

...you can push a copy of your finished site up to your live server...

As you say, I can go ahead with the site development using the Blue Lagoon theme, but I will need to know how to change the site colours manually (which CSS files, etc.) when I want to run final checks and go live. Unfortunately, I have just renewed my subscription with my host and do not want to fork out again for a 'Drupal-compatible' host at this stage, otherwise that would have been very tempting.
I do not wish to go the Drupal Gardens route and be tied in to that degree. Besides, it's very expensive.

BTW, here is the error message Drupal throws up:
Location: http://www.nnnnn.nnnnn.com/admin/appearance/settings/bartik?render=overl...
Referrer: http://www.nnnnn.nnnnn.com/admin/appearance/settings/bartik?render=overlay
Message: The file permissions could not be set on public://color/bartik-f3efd97b/colors.css.
Severity: error

I am also unable to install Drupal modules to my host via the URL method. This is also very inconvenient, but I guess I'll just have to do it the old upload way. :-(

Thank-you again for the time and effort you have put into your reply. I'm very grateful. If you could point me in the direction of a resource that will assist me in manually editing the Bartik theme on my host's server for future reference - I will need to know on which files I will have to ask my host for the ownership to be changed, won't I? - that would make my day. ;-)

Thanks again. Sincerely.

couturier’s picture

Here is a link to a tutorial on How to Customize Bartik.

Yes, it sounds like your server is definitely restricting file permissions to write those changes. I made some additional comments about folder permissions at another of your forum posts. I've copied those comments here:

I have experienced the situation with my own host server that some files, particularly in the Sites folder, revert to default permissions even if you think you've set them to 777. So, go back and check to see if they have re-set to default permissions. This seems to be what is happening based on your log error messages. Also look to see what permissions the higher folders have. It is not just the folder you are investigating but also all the folders in the hierarchy above it (sites, default and files) that must have permissions set to 777 before changes can be made. If you are restricted from changing these permissions, then it is an issue with the way your host's server is set up. You'll need to contact your hosting provider and request that they grant you added permissions for the Sites folder and all the folders within it. Some hosts purposely restrict permissions to the Sites folder and the folders within so that you do not accidentally erase your whole site when you are upgrading Drupal core, so that could be part of what is causing your folders to not be writable.

Drupal Gardens hosting starts at less than $8.50 per month in Australian Dollars, but again, you may want more than a basic site, in which case Drupal Gardens is not for you. You might look into some other hosting when your plan comes up for renewal again. It sounds like you are having some strong file permission restrictions with your current provider. Please let us know how things go.

wreckage’s picture

Thank-you for the tips, couturier.
I did try again re-setting all file and folder permissions (which took forever via FTP) but it did not resolve the issue of not being able to change the Bartik colour scheme.

Today I have updated to Drupal version 7.12 (cleared the caches and performed a database update) and miraculously, with the default permissions, I can now change the colour scheme.

I have no idea why, but am thankful that it works! Yippeeeee! ;-)

Cheers.

wreckage’s picture

Title: Unable to change colors of Bartik 7.8 color scheme (all regions are white) » Unable to change colors of Bartik 7.8 color scheme (all regions are white- SOLVED, sorta.)
onco_p53’s picture

Title: Unable to change colors of Bartik 7.8 color scheme (all regions are white- SOLVED, sorta.) » Unable to change colors of Bartik 7.8 color scheme (all regions are white)
Status: Active » Fixed

Well it looks like this is fixed then, not sure how, but a good result in the end.

MrPhilbert’s picture

Sorry, it's not fixed. I just installed a fresh 7.12 and Bartik still displays white only on color change.

couturier’s picture

Status: Fixed » Active
wreckage’s picture

This may help. I upgraded by creating a new folder like this:

1) Download latest core (*.tar) and expand into a folder

On your web site, all files/folders that ARE NOT inside the folder are considered to be Drupal core.

2) Establish an FTP session and create a folder in 'www' (or your web location) with a unique name.

3) Copy contents of the Drupal archive into the newly-named folder on your web host.

4) Clear the existing site cache: ADMIN > CONFIG > DEVELOPMENT > PERFORMANCE

5) Back-up any other folders that you have created (Images, Profiles, etc)

6) Copy the folder, and any other custom folders (Images, etc.) from your original folder on your host into the new one.

7) Rename the original folder on your host to anything you like will do.

8) Rename the new folder on your host to whatever you previously had your site folder named.

9) Add “/update.php “ to the end of your URL when you first login to your new updated site just to check to see if any module updates are available.

10) Clear the site cache from ADMIN > CONFIG > DEVELOPMENT > PERFORMANCE

11) Review the status report to make sure that the upgrade went successfully with no errors : ADMIN/REPORTS/STATUS

Cheers.

tobbetobbe’s picture

I had this problem after upgrading core from 7.10 to 7.12. I solved it with some help from my webhosting. I had wrong file permissions in Sites>Default>Files folder. I think it differs from server to server and in my case folders needed 755 and php-files needed 644. Both higher and lower permissions caused problems.

S3bastien’s picture

I updated to 7.12.
Then changed again all permissions (755 for folders and 644 for files as Tobbetobbe suggested).
I then switched colors in Bartik theme settings.
And now it works.
Thank you all for your posts.

onco_p53’s picture

Status: Active » Fixed

Ok very tentatively I am once again changing this to fixed, the OP has now solved the problem.
I also got this problem two days ago with changing the location of a drupal installation from a subfolder to the root. In this case I also needed to change the file permissions on folders (but to delete to old ones).

@MrPhilbert does this fix also work for you?

jrdixey’s picture

I just wanted to say thank you to Tobbetobbe also ... this was a problem that really had me puzzled, because it came up in the context of an attempt to work on a bartik subtheme in a different subdirectory, so I thought it was related to that. Fixing the file/folder permissions as described worked perfectly. I did not have to make any changes to my bartik custom colors, but I did have to go into the Bartik theme customization screen and save it as if I had made changes. My custom logo and theme colors are now working!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

fureigh’s picture

One more thank-you to Tobbetobbe. chmod 755 for sites/default/files and the subsequent relevant folders fixed it.

raeasah’s picture

Issue summary: View changes

salam here is a similar problem I lost the control of changing a one color at a time for example if i customized the header color ... all other colors change as a one them .... the key icon is closed

raeasah’s picture

StatusFileSize
new50.08 KB