Hi,

Love the new base theme for Drupal. Superb work guys

Just testing it on a fresh install of Drupal 5.0 (cvs) and had problems trying to change the colour scheme.

When I change the colour scheme and click on SAVE CONFIGURATION, I'm presented with a blank page and the theme is broke, i.e. I have to RESET to DEFAULTS to get back the default colour scheme.

I tried it on 2 different installs of todays CVS download (Oct 30th) and was able to replicate the problem.

Just wondering if it is a server issue with file permissions. I had a quick look at the color.module and color.inc and noticed there are files to 'copy over'.

Apologies in advance if this is a known issue. Seeing that it's the default theme, I thought it best to raise the issue asap.

Dub

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webernet’s picture

Title: can't change color scheme on garland theme » Can't change color scheme on garland theme

Could this be due to caching? I noticed that if you change your colour scheme, and cache is enabled, anonymous visitors will get a broken theme (since the new images/css have a different name and are in a different folder. Perhaps a cache_clear_all() might be appropriate after changing the theme colour?

Dublin Drupaller’s picture

had a look at that, thanks webernet, but it didn't solve the problem.

I notice I can't delete the files and folders under /files/color/ that are created when you enable the garland theme (install Drupal).

So I'm guessing it's a file premission issue.

Dub

Dublin Drupaller’s picture

had a look at that, thanks webernet, but it didn't solve the problem.

I notice I can't delete the files and folders under /files/color/ that are created when you enable the garland theme (install Drupal).

So I'm guessing it's a file permission issue.

Dub

greggles’s picture

I can't reproduce this problem.

Can you look in your error log when you get this problem and see if that has any clues?

Dublin Drupaller’s picture

no obvious clues greggles...just a bunch of 'file not found' error messages

 page not found 10/31/2006 - 17:50 files/color/garland-5e37ba43/style.css 
 page not found 10/31/2006 - 17:50 files/color/garland-5e37ba43/style.css
 page not found 10/31/2006 - 17:49 files/color/garland-5e37ba43/style.css 
 page not found 10/31/2006 - 17:49 files/color/garland-5e37ba43/style.css 

I've tried it twice with fresh installs and there is another problem - you can't delete the files and folders the color.module creates under /files/color/

I'm guessing it's a file permissions problem when the files are copied across.

hope that makes sense

Dub

drumm’s picture

The not deleting might be fine. I often have apache writing files under it's own username and not bothering to give my account any access. This is fine as long as Apache can get to everything.

What files, if any, are in the files directory?

FiNeX’s picture

I've just downloaded the drupal 5.0 beta, the problem is still present. I've checked the logs but I've found nothing.

jeffleeismyhero’s picture

I downloaded the beta about half an hour ago and the problem you describe is not there. In fact, if you look at my site I have changed the theme using the color picker and everything worked perfectly.

www.winappleblog.com

greggles’s picture

I think it's safe to say that there is a configuration difference that causes this problem on certain hosts. The priority of this issue will depend on common it is. Given that two folks have hit on it in Beta (and even pre-beta) it's probably critical prior to release.

@FiNex - when you say you checked the logs - do you mean the Drupal admin/logs/watchdog page or the apache error log? It's likely that both places are important to review for this matter.

@FiNex and Dublin Drupaller - can you outline the apache, php, etc. options you are using as a way to get towards the source of the problem?

For comparison, I'm using apache2-php5 in cgi mode running as my unix user.

drumm’s picture

Please provide details

- Web server type & version
- PHP version
- List of files in .../files/color/
- Any relevant messages from admin/logs/watchdog on your site.
- Any relevant web server logs.
- Copy of the following line from the source of any page on your site <style type="text/css" media="all">@import "/c-drupal/files/color/garland-57eef1fe/style.css";</style>.

Simply stating whether it works or not won't help us substantially.

pcs305’s picture

(I'm adding this here as I cannot find the Garland theme project page. If this is not the place please let me know.)

I can change my colors just fine but the "color wheel" (for lack of a better word) does not display on the color config page. If you want the evidence for this problem I can post it(XAMPP on XP).

Dublin Drupaller’s picture

- Web server type & version

Apache Version 2.0.52

- PHP version
Version 4.3.9

- List of files in .../files/color/

There are about 10 folders under /files/ e.g. files/color/garland-1845383b/

With the following files in each of the 10 folders:

menu-collapsed.gif
menu-expanded.gif
menu-leaf.gif

note: File permissions are 644 for all files and folders.

- Any relevant messages from admin/logs/watchdog on your site.

Already mentioned. See above

- Any relevant web server logs.

I'll have to dig that out if it's necessary.

- Copy of the following line from the source of any page on your site

@import "/c-drupal/files/color/garland-57eef1fe/style.css";

.

Using out of the box theme the path to theme style.css is:
/test50/themes/garland/style.css

When the theme breaks (i.e. when you try and change the theme colours):
/test50/files/color/garland-16b7ecb3/style.css

Note: there is no style.css in that folder.

Simply stating whether it works or not won't help us substantially.

Apologies in advance if this is a known issue. Seeing that it's the default theme, I thought it best to raise the issue asap.

Just wondering if it is a server issue with file permissions. I had a quick look at the color.module and color.inc and noticed there are files to 'copy over'.

hope that helps Drumm. FWIW I didn't just say it works or not...it's the default theme for Drupal 5.0 and as such I thought it was best to flag it straight away.

Dub

drumm’s picture

Sorry, wasn't trying to direct "Simply stating whether it works or not won't help us substantially." towards Dublin Drupaller, who has been really helpful.

Any information does help, but I want to make clear that more information is more helpful since this sort of issue needs a decent amount of detail and might get quite a few "me too" responses.

webernet’s picture

OK - That narrows down the problem - the files aren't being created. There should be 17 files in the /files/color/garland-xxxxxxxx/ directory (images and style.css)...

The three files that are there are correctly copied unchanged from the theme folder. The others should have been generated.

Do you have the GD2 image toolkit installed?

FiNeX’s picture

software versions
Apache/2.0.55
PHP 5.1.2 (cli)
mysql Ver 14.12 Distrib 5.0.22

files
the directory "/files/color" contains a sub-dir: "garland-0dc66c4d". This directory has the following files:

bg-bar.png
bg-bar-white.png
bg-content-left.png
bg-content.png
bg-content-right.png
bg-navigation-item-hover.png
bg-navigation-item.png
bg-navigation.png
bg-tab.png
body.png
gradient-inner.png
logo.png
menu-collapsed.gif
menu-expanded.gif
menu-leaf.gif
screenshot.png
style.css

watchdog log
There is nothing relevant on the watchdog logs

Apache log
Apache report something interesting:

[Tue Oct 31 22:06:47 2006] [alert] [client 192.168.0.2] /var/www/drupalcvs/files/.htaccess: SetHandler not allowed here, referer: http://hostname/drupalcvs/?q=admin/build/themes/settings/garland
[Tue Oct 31 22:06:47 2006] [alert] [client 192.168.0.2] /var/www/drupalcvs/files/.htaccess: SetHandler not allowed here, referer: http://hostname/drupal/drupalcvs/?q=admin/build/themes/settings/garland

import css code
with the default garland theme:
<style type="text/css" media="all">@import "/drupal/drupalcvs/themes/garland/style.css";</style>

after the color change from the configuration page:
<style type="text/css" media="all">@import "/drupal/drupalcvs/files/color/garland-e5c82974/style.css";</style>

FiNeX’s picture

I've removed the .htaccess file on the "files" directory, and now it works!!!!

FiNeX’s picture

Priority: Critical » Normal

I think this is a server configuration problem, not a Drupal one.

Dublin Drupaller’s picture

thanks finex..I think you're right about it being a server configuration issue, but, removing the .htaccess file under /files/ didn't work for me.

Each time I try and change the colour scheme, 4 new folders are created under /files/color/ e.g. garland-b4ac25c8 or garland-e2aced97

And in those folders are 3 files:

menu-collapsed.gif
menu-expanded.gif
menu-leaf.gif

Am stumped at this end..
Dub

greggles’s picture

Priority: Normal » Critical

@dub - do you have gd installed/working? What does http://www.example.com/admin/logs/status

Regardless of the sourc,e this is critical. We need to know what instructions to give to people (e.g. you need gd for themetastic to work) and people are going to want this feature so a warning will be critical.

webernet’s picture

Try disabling and then re-enabling color.module - it should give you a warning if there are any problems with the GD image toolkit.

Dublin Drupaller’s picture

Hi Greggles,

GD Library bundled (2.0.28 compatible) is working.

I agree with you by the way..as the base theme, it is pretty important that it works flawlessly.

I think it's almost definitely something to do with the file permissions...my files/color folder is now full of folders (over 20) from testing this...and what's got me thinking it's almost certainly a file permissions issue is that I can't delete them as normal using FTP.

See below:

Command:	DELE /httpdocs/test50/files/color/garland-f58e0d86/menu-collapsed.gif
Response:	550 /httpdocs/test50/files/color/garland-f58e0d86/menu-collapsed.gif: Permission denied
Command:	DELE /httpdocs/test50/files/color/garland-f58e0d86/menu-expanded.gif
Response:	550 /httpdocs/test50/files/color/garland-f58e0d86/menu-expanded.gif: Permission denied
Command:	DELE /httpdocs/test50/files/color/garland-f58e0d86/menu-leaf.gif
Response:	550 /httpdocs/test50/files/color/garland-f58e0d86/menu-leaf.gif: Permission denied
Command:	RMD /httpdocs/test50/files/color/garland-f58e0d86/
Response:	550 /httpdocs/test50/files/color/garland-f58e0d86/: Permission denied

I'm not an expert in file permissions or server configs etc. so I'm only guessing that the _color_rewrite_stylesheet function might need some server configuration that - if it's not enabled/set - breaks the site and leaves a lot of files on the server.

Does that make sense?

Dub

drupal.padilla’s picture

I am using the private files method (uploaded / generated files stored out of the document root for security). The garland theme files are being created in the correct location, but the URLs generated to access those files is being created incorrectly (using the files directory as part of the URL: /var/vhosts/filedir/...). The URLs are of the form /files/.... instead of /system/files/.....

cog.rusty’s picture

I have the same problem. Changing color scheme breaks the theme.
The wachdog gives me "files/color/garland-1d51ad5c/logo.png" etc messages.

Maybe this path is not correct. I use the private download method, and the files have been created correctly under my private files path, outside the web root (not under public_html). If private storage works like it did in 4.7, then the files should be accessed using "system/files/color/......"

cog.rusty’s picture

Oh, and I cannot change it back because color picker does not work in this themeless view. I can only choose another theme.

As a workaround, I copied the files over to where the watchdog says and it does work.

cog.rusty’s picture

@DublinDrupaller: It is normal that you can't delete those files because Drupal created them through Apache, so their owner is now 'apache' (or 'nobody'). An ls -l command would confirm this. To delete them you have to either ask your host or use a script like phpshell (http://mgeisler.net/php-shell) so that you can work through apache (just like Drupal did when creating them).

mhs-1’s picture

I fixed it liek this :

I ran 'chmod +x' on themes/garland/color/*

that fixed the problem of the color picker not showing up.

however the real issue I had , was my website host does not support many of the .htaccess directives

when you change the color palette on a theme, drupal generates the relevant css files and images in a temp folder in your "files" directory (the one which you tell drupal to store misc stuff) and as a security feature also adds an .htaccess file there. (which prevents indexing of that dir)

I had to remove the .htaccess file (from your_drupal_dir/files/color) every time I changed the color setting to anything other than the default blue.

So in all, chmod +x the above mentioned files, and remove .htaccess (if you have to).

cog.rusty’s picture

In my case, files/.htaccess was already there (not added by color picker) and I had fixed it according to issue http://drupal.org/node/86314 .

webernet’s picture

Anyone that is having issues with this should note that the .htaccess file is automatically created in the /files directory as a security measure and should not be removed without careful consideration of the consequences.

If you are having this problem with the color changer, please:
-Leave the .htaccess file intact
-Provide the relevant lines from the apache (web server) error logs
-Provide a list of files in /files/color/

cog.rusty’s picture

I think we are dealing with two different problems (bugs?) here.

1. Failure to generate and/or write all the files into the files directory (writes the gifs, doesn't write the png and css files).
or
2. Successful generation and writing, failure to retrieve them from the right *private* files path.

Jhef.Vicedo’s picture

Version: x.y.z » 5.0-beta1
Component: color.module » theme system

I had a similar problem when I tried to change the color of the garland theme. I viewed the HTML source of one page and compare it against a source when I reverted the theme to default. One difference I noticed is this:

On the broken theme, the code looks like this:

<style type="text/css" media="all">@import "/drupal/drupal5/themes/garland/color/preview.css";</style>
<style type="text/css" media="all">@import "/drupal/drupal5//home/jhef/WebData/drupal/drupal5/color/garland-ca1661a5/style.css";</style>
    <script type="text/javascript" src="/drupal/drupal5/misc/jquery.js"></script>

And on the correct one:

<style type="text/css" media="all">@import "/drupal/drupal5/themes/garland/color/preview.css";</style>
<style type="text/css" media="all">@import "/drupal/drupal5/themes/garland/style.css";</style>
    <script type="text/javascript" src="/drupal/drupal5/misc/jquery.js"></script>

Notice the double forward slashes on "<style type="text/css" media="all">@import "/drupal/drupal5//home/jhef/WebData/drupal/drupal5/color/garland-ca1661a5/style.css";</style>"

I think this is the cause of the problem.. There's no problem when my file system path is inside my drupal installation folder. But when I set it outside the Web Document Root, the theme breaks.

cog.rusty’s picture

Version: 5.0-beta1 » x.y.z

Although this is in "beta-1" too, when you tag it "beta-1" it disappears from the "Critical issues" list linked from the front page. I already filed an issue about that.

webernet’s picture

Rok Žlender’s picture

FileSize
941 bytes

As I see it this is a problem in drupal_get_css function in common.inc and also with private downloads with file system path outside apache document root. Let me explain.
If filesystem path is outside www root than custom garland theme files will be saved in lets say /var/www/files/color/garland-******/* and pah to style.css file will also be absolute /var/www/files/color/garland-******/style.css. When drupal_get_css function is called it automatically prepends base_path() so after this css import line will look sth like this

<style type="text/css" media="all">@import "/drupalBeta1//var/www/files/color/garland-e63ad372/style.css";</style>

I fixed this with an ugly hack (see attachment).
So now it looks like this

<style type="text/css" media="all">@import "/var/www/files/color/garland-e63ad372/style.css";</style>

But this does not solve the problem.
Another problem is that css files AFAIK must be inside www root so that browsers can access them. If your private file system path is outside www root than style.css cannot ba accessed. I have no idea how to solve this other than having garland custom files somewhere else.

cog.rusty’s picture

Oh... and I guess this problem has also to be solved for all other future themes which are going to use the color switcher. So, color switcher might be the right candidate for maintaining such a public directory.

Or is it time to consider a required public "assets" directory in Drupal, additionally to any private files directory?

Rok Žlender’s picture

FileSize
2.17 KB

I added color module setings page which is shown if private downloads are enabled and lets you choose where to put custom themes. I tested it and it works. If public files are used there is no difference if private is used themes are put into dir you choose on color module settings page.

One thing is still missing. If private downloads are used and this new color module directory is not set color picker should not be seen on theme configure page. I will try to write this today.

Steven’s picture

The proposed patch incredibly hackish. It turns the 'private' setting into a 'hybrid' mode, where some files are still stored publically. But, it only works for color.module and is accessible only from a confusing settings page.

There are three acceptable solutions as far as I can see:

  1. We introduce this hybrid ability in the file system properly (i.e. always provide a publically accessible path, for those cases where it is needed). This setting would be located in the file system screen too, clearly documented and transparently used.
  2. We alter the stylesheet generation code to output private file URLs when needed. The performance of this would be pretty bad though, as we'd be doing a full Drupal bootstrap for every single image + the stylesheet (that's 16).
  3. We disable color changing when private files are used.

#2 seems like a very bad idea, while #1 seems like too big a change to do in mid code freeze. I'm inclined to pick #3 for now.

cog.rusty’s picture

Although I am not qualified to have an opinion on what is acceptably clean for core, it doesn't seem so hackish to me because its public files are not user files. They are theme files.

I'd rather see Rok's patch live and be tested (if not in core, then as an alternative contributed color module). Otherwise, if the use of private storage is penalized according to Steven's #3, the users would have to manually modify Garland, possibly using the files generated by the color module in a test site.

Rok Žlender’s picture

FileSize
842 bytes

I totally agree patch is hackish it is more a conecpt of how things can be solved and not a perfect solution.

The first solution would be perfect but as Steven said now is probably not the right time to implement this into core.

I added a simple check in form_alter function to see if public downloads are used in other case color picker is not displayed see attached patch.

Ryanbach’s picture

Status: Active » Needs review
azugaldia’s picture

I don't know exactly if the error I've found is caused by the same reason, but I'm not able to change the color of garland (minnelli) either. I'm using beta 1 and I get the following (real domain name changed to mydomain.com):

    * warning: mkdir(): SAFE MODE Restriction in effect. The script whose uid is 10197 is not allowed to access /home/httpd/vhosts/mydomain.com/httpdocs/beta/files/color owned by uid 48 in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 217.
    * warning: copy(): SAFE MODE Restriction in effect. The script whose uid is 10197 is not allowed to access /home/httpd/vhosts/mydomain.com/httpdocs/beta/files/color owned by uid 48 in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 233.
    * warning: copy(files/color/minnelli-cf6cb27a/menu-collapsed.gif): failed to open stream: Success in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 233.
    * warning: copy(): SAFE MODE Restriction in effect. The script whose uid is 10197 is not allowed to access /home/httpd/vhosts/mydomain.com/httpdocs/beta/files/color owned by uid 48 in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 233.
    * warning: copy(files/color/minnelli-cf6cb27a/menu-expanded.gif): failed to open stream: Success in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 233.
    * warning: copy(): SAFE MODE Restriction in effect. The script whose uid is 10197 is not allowed to access /home/httpd/vhosts/mydomain.com/httpdocs/beta/files/color owned by uid 48 in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 233.
    * warning: copy(files/color/minnelli-cf6cb27a/menu-leaf.gif): failed to open stream: Success in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 233.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/body.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-bar.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-bar-white.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-tab.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-navigation.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-content-left.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-content-right.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-content.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-navigation-item.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/bg-navigation-item-hover.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/gradient-inner.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/logo.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: imagepng(): Unable to open 'files/color/minnelli-cf6cb27a/screenshot.png' for writing in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 379.
    * warning: fopen(): SAFE MODE Restriction in effect. The script whose uid is 10197 is not allowed to access /home/httpd/vhosts/mydomain.com/httpdocs/beta/files/color owned by uid 48 in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 319.
    * warning: fopen(files/color/minnelli-cf6cb27a/style.css): failed to open stream: Success in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 319.
    * warning: fwrite(): supplied argument is not a valid stream resource in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 320.
    * warning: fclose(): supplied argument is not a valid stream resource in /home/httpd/vhosts/mydomain.com/httpdocs/beta/modules/color/color.module on line 321.
Dries’s picture

Hi Rok. Thanks for the patches. If this is a temporary solution, maybe add a little code comment (TODO) to the code? Otherwise, we'll forget about it.

Rok Žlender’s picture

I added a TODO and rerolled the patch to the latest version of color.module

chx’s picture

Status: Needs review » Reviewed & tested by the community

We can always patch more... temprorary yes but good.

drumm’s picture

Status: Reviewed & tested by the community » Active

Committed to HEAD (Sorry, vim did not want to put in 'Ž).

Now how do we fix this?

chx’s picture

Priority: Critical » Normal

I doubt this is a critical now...

chx’s picture

Version: x.y.z » 5.0-beta1
netbjarne’s picture

"mee too"

I have always have troubles with drupal creating folders, throwing "safe mode restriction errors". The workaround for me have been to create the /files and /files/temp folders by FTP and setting write permissions. I can also create a "/files/colors" folder - no biggie.

"but now!"

The Garland theme seems to create folders with RANDOM NAMES as subfolders to /colors. This I cannot do via FTP - as I cannot know the foldername until Garland creates it - and then it is too late.

Thats a real shame - cause I found the color picker very useful (until I recognized I wouldn't be able to use it)

Bjarne

Dublin Drupaller’s picture

HI Bjaarne,

The Garland theme seems to create folders with RANDOM NAMES as subfolders to /colors. This I cannot do via FTP - as I cannot know the foldername until Garland creates it - and then it is too late.

I'm having the same problem. There is a php workaround that will override file permissions but seeing
that it is the new default theme, I think it's worth drilling down to iron out that problem.

Leaving behind a load of randomly named folders that people can't remove normally might baffle and freak out newbies who aren't experts in server configurations and file permissions.

Dub

cog.rusty’s picture

What could that be?

A page with a listing of files/directories created by drupal or modules, with a check box for deleting and with a tag saying who needs it? (Sounds like a feature of course).

Perhaps everything in an always public files directory (called assets?) not necessarily associated with the user files directory or with any hybrid private/public feature.

Chill35’s picture

Title: Can't change color scheme on garland theme » I have reproduced the problem on my machine

I have the GD Library bundled with php running just fine (2.0.28 compatible), or so says my Status Report. My color module is activated.

Here's the problem :

If I change to another color theme (belgian chocolate, mercury, etc.) and save these changes, the styling is gone. Going back to the default color theme brings back the styling. Customization of the color theme creates the same problem. By 'styling gone' I mean that the Garland stylesheet is not applied.

- Web server type & version

Windows XP SP2 with Apache 2.0.59 (win32, obviously)

- PHP version

5.1.4.

- List of files in .../files/color/

After applying "belgian chocolate" : There is a folder .../files/color/ but it is empty.

- Any relevant messages from admin/logs/watchdog on your site.

None

- Any relevant web server logs.

The latest log entries (while I was changing the color theme) :

[14/Nov/2006:14:28:11 -0500] "GET /drupal-5.0-beta1/?q=admin/settings HTTP/1.1" 200 11282
[14/Nov/2006:14:28:11 -0500] "GET /drupal-5.0-beta1/filesupload/color/garland-99302314/style.css HTTP/1.1" 404 343
[14/Nov/2006:14:28:13 -0500] "GET /drupal-5.0-beta1/filesupload/color/garland-99302314/style.css HTTP/1.1" 404 343
[14/Nov/2006:14:28:12 -0500] "GET /drupal-5.0-beta1/?q=admin/build HTTP/1.1" 200 8284
[14/Nov/2006:14:28:15 -0500] "GET /drupal-5.0-beta1/filesupload/color/garland-99302314/style.css HTTP/1.1" 404 343
[14/Nov/2006:14:28:15 -0500] "GET /drupal-5.0-beta1/files%5Cupload/color/garland-99302314/screenshot.png HTTP/1.1" 404 349
[14/Nov/2006:14:28:14 -0500] "GET /drupal-5.0-beta1/?q=admin/build/themes HTTP/1.1" 200 13303
[14/Nov/2006:14:28:21 -0500] "GET /drupal-5.0-beta1/filesupload/color/garland-99302314/style.css HTTP/1.1" 404 343
[14/Nov/2006:14:28:20 -0500] "GET /drupal-5.0-beta1/?q=admin/build/themes/settings HTTP/1.1" 200 14502
[14/Nov/2006:14:28:24 -0500] "GET /drupal-5.0-beta1/filesupload/color/garland-99302314/style.css HTTP/1.1" 404 343
[14/Nov/2006:14:28:24 -0500] "GET /drupal-5.0-beta1/?q=admin/build/themes/settings/garland HTTP/1.1" 200 16218
[14/Nov/2006:14:28:37 -0500] "POST /drupal-5.0-beta1/?q=admin/build/themes/settings/garland HTTP/1.1" 302
[14/Nov/2006:14:28:39 -0500] "GET /drupal-5.0-beta1/filesupload/color/garland-5fc1090b/style.css HTTP/1.1" 404 343
[14/Nov/2006:14:28:38 -0500] "GET /drupal-5.0-beta1/?q=admin/build/themes/settings/garland HTTP/1.1" 200 16297

ERROR LOG :

[Tue Nov 14 14:28:11 2006] [error] [client 127.0.0.1] File does not exist: F:/htdocs/drupal-5.0-beta1/filesupload, referer: http://localhost/drupal-5.0-beta1/?q=admin/settings
[Tue Nov 14 14:28:13 2006] [error] [client 127.0.0.1] File does not exist: F:/htdocs/drupal-5.0-beta1/filesupload, referer: http://localhost/drupal-5.0-beta1/?q=admin/build
[Tue Nov 14 14:28:15 2006] [error] [client 127.0.0.1] File does not exist: F:/htdocs/drupal-5.0-beta1/filesupload, referer: http://localhost/drupal-5.0-beta1/?q=admin/build/themes
[Tue Nov 14 14:28:21 2006] [error] [client 127.0.0.1] File does not exist: F:/htdocs/drupal-5.0-beta1/filesupload, referer: http://localhost/drupal-5.0-beta1/?q=admin/build/themes/settings
[Tue Nov 14 14:28:24 2006] [error] [client 127.0.0.1] File does not exist: F:/htdocs/drupal-5.0-beta1/filesupload, referer: http://localhost/drupal-5.0-beta1/?q=admin/build/themes/settings/garland
[Tue Nov 14 14:28:39 2006] [error] [client 127.0.0.1] File does not exist: F:/htdocs/drupal-5.0-beta1/filesupload, referer: http://localhost/drupal-5.0-beta1/?q=admin/build/themes/settings/garland

- Copy of the following line from the source of any page on your site

@import "/c-drupal/files/color/garland-57eef1fe/style.css";

.

The two last stylesheets that my pages link to are :

@import "/drupal-5.0-beta1/themes/garland/color/preview.css";@import "/drupal-5.0-beta1/files\upload/color/garland-5fc1090b/style.css";
Chill35’s picture

Title: I have reproduced the problem on my machine » Whooo Hooooo
@import "/drupal-5.0-beta1/files\upload/color/garland-5fc1090b/style.css";

What is that backslash doing there, LOL...?

I think I know what my problem is.

LOL... I hope you'll have some comical relief here, like I have.

I will be back just to confirm if things work.

Chill35’s picture

Title: Whooo Hooooo » Thanks to Drumm's checklist

I found out what my problem is. WELL... in this particular situation.

I was having problems with my upload module last night so in my File System config, I changed the File system path to files\upload, instead of files/upload. I am not dyslexic, I am just not very good with slashes. Relative paths always use the regular slash << talking to myself here.

If I REALLY reproduce the problem mentioned here, I'll be back.

Have a nice day!

netbjarne’s picture

Just a thought:

One possible sollution to this and similar problems relating to "SAFE MODE restriction in effect" errors when drupal tries to create folders, could be a system wide "Use FTP for creating folders" option.

A similar patch was once made for Mambo CMS. Mambo allows installation of modules and themes within the administration menu, but this requires creation of folders. Configured with a valid FTP account, Mambo would use FTP for these file operations instead of, eh, php? - this helped a lot of people.

Bjarne

havran’s picture

Similar problem in color.module is mentioned here: http://drupal.org/node/97945 - Replace mkdir('my/path/') with mkdir('my/path')

serving’s picture

Priority: Normal » Critical

Fresh install. I change theme to a preset one "Greenbeam" and got the blank page.
Clicking back in my browser I am able to see the site again but without styles.

View source :

@import "/head-5/files/color/garland-d2052c61/style.css";

Checking my file system. There is no style.css in /head-5/files/color/garland-d2052c61/

Please advise.

Serving

Dublin Drupaller’s picture

navigate back to the ADMIN -> THEMES page and click on reset to defaults.

That won't fix the problem, but, it will let you see your site again with styling.

It sounds like the same problems I discovered, so don't try changing the theme colours again, as it automatically generates a randomly named folder and puts some files under the site files folder that can't be removed using standard FTP, normally. You need a PHP workaround that allows you to reset the file and folder permissions first.

I haven't worked out a solution to the problem yet...I think it's to do with assumptions made with the server side configuration, so it will only affect some users with standard shared webhosting accounts, or in my case, a VPS account.

hope that helps

Dub

Dublin Drupaller’s picture

Serving. Try the very latest version of Drupal 5. There was an update to the color.module a few days ago that might have fixed this issue.

I'm testing it now and it appears to work.

Dub

serving’s picture

Hi Dublin Drupaller

Yes. I am able to get the site back to defaults.

My installation is less than 12 hours old. I did a cvs checkout just to see if this was fixed since my first install of 3 days ago.

It is not fixed in HEAD as of 12 hours ago.

Please post whether yours is working or not. What version you downloaded?

Have a great one.

Serving

cog.rusty’s picture

The patch just disabled the color module for those who use the "private download method" (in http://dru5.cogville.com/admin/settings/file-system) until a better fix is found. If you don't use the private download method then this is another problem to fix.

chx’s picture

Priority: Critical » Normal

As there are no repeated instances of this bug, for now I demote it from critical status. We can put it back if it's necessary.

Now... have you checked whether you can upload files -- so that you know that your files dir is OK?

serving’s picture

Priority: Normal » Critical

Hi chx

I am abale to attache files to my posts and my test ended in

mydomain.tld/head-5/files/a_topfiller.jpg

my web root is mydomain.tld/head-5/

However, I am still not able to change theme colors as I explained in my previous posts.

I just did a cvs update -dP and the problem is still there. So this bug is not fixed nor gone.

The missing style.css in /head-5/files/color/garland-d2052c61/ is still missing. Only 3 files are in there menu-collapsed.gif menu-expanded.gif menu-leaf.gif.

I don't beleive I have a filesystem permisson problems but I may be wrong. If I am could someone please point my error to me?

Have a good one.

Serving

chx’s picture

Priority: Critical » Normal

Thanks for your fast reply.

Could you please add a drupal_set_message($style) after $style = file_get_contents($paths['source'] .'style.css'); in color.module to see whether the stylesheet gets loaded at all. Second, after $file = fopen($paths['stylesheet'], 'w+'); add if (!$file) drupal_set_message('Unable to open for writing');. This way, we will know where the error lies.

serving’s picture

Hi chx

The second line now looks:
$style = file_get_contents($paths['source'] .'style.css'); drupal_set_message($style)

The second line looks like:
$file = fopen($paths['stylesheet'], 'w+'); if (!$file drupal_set_message('Unable to open for writing');

but now I get blank page on evey page I try to access.

I tried to add ";" to the end as in drupal_set_message($style); but still blank pages. I am no php programmer and I don't play one on TV. :D

Nothing in error_log

Thank you for your help

Serving

cog.rusty’s picture

You forgot to close a parenthesis in the second line, in (!$file).
And yes, a ";" is needed in the first one.

serving’s picture

Thank you CogRusty for the correction..

now the site works. I still get the blank page when I chagne garlans colors and I can not see any error mesgs. Just the blank page after I click submit.

Serving

cog.rusty’s picture

Hmm... I wonder if color has a fallback so that it can be tested with javascript disabled in the browser. I guess not, but let's see...

serving’s picture

Cool.. let me know if I can be of help..

Serving

cog.rusty’s picture

Try it and see what happens.

If you disable javascript in your browser you don't get the color wheel but you still get the selection lists, and this does create a garland-xxxxx subdirectory under files/color.

See if you get a message this way.

serving’s picture

nop.. still don't see anything. :(

Darren Oh’s picture

Component: theme system » color.module
serving’s picture

I don't get it.. (chewing gum)

netbjarne’s picture

Version: 5.0-beta1 » 5.0-beta2
Priority: Normal » Critical

Problem still exists in 5.0-beta2

Color.module creates folders with random names, that interferes with php safe mode restriction on host.

Heres the ugly bunch of errors thrown at me:

* warning: copy(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.
* warning: copy(files/color/garland-43d5d4dc/menu-collapsed.gif): failed to open stream: Success in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.
* warning: copy(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.
* warning: copy(files/color/garland-43d5d4dc/menu-expanded.gif): failed to open stream: Success in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.
* warning: copy(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.
* warning: copy(files/color/garland-43d5d4dc/menu-leaf.gif): failed to open stream: Success in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: imagepng(): Invalid filename in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 380.
* warning: fopen(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 320.
* warning: fopen(files/color/garland-43d5d4dc/style.css): failed to open stream: Success in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 320.
* warning: fwrite(): supplied argument is not a valid stream resource in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 321.
* warning: fclose(): supplied argument is not a valid stream resource in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 322.

cog.rusty’s picture

This is probably a different issue (I think), a special case caused by the so called "safe mode" in php5, which is going to be removed from its next version. Serious hosts don't use it. In some cases a workaround is to create your 'files' and 'tmp' (without a front slash) directories yourself under drupal and make them 777. But in this case we have dynamically created directories and I am not sure if this would work...

jhm’s picture

* warning: copy(): SAFE MODE Restriction in effect. The script whose uid/gid is 151617/151617 is not allowed to access /hsphere/local/home/oldrup/test.oldrup.dk/files/color/garland-43d5d4dc owned by uid/gid 398/398 in /hsphere/local/home/oldrup/test.oldrup.dk/modules/color/color.module on line 234.

I see the uid/gid of the script is different from the uid/gid of the files/color/garland-43d5d4dc directory. Can you try to change the uid/gid of color.module to the same uid/gid of the web server executing the scripts (151617/151617)?

This is what the php manual says about safe_mode and chown:

Note: When safe mode is enabled, PHP checks whether the files or directories you are about to operate on have the same UID (owner) as the script that is being executed

maybe the color.module should check if the uid/gid of itself is the same as the uid/gid of the server process when running in safe_mode before allowing the use of color changing?

azugaldia’s picture

Just to say that I've just installed beta2 and the problem with garland/color and the safe mode is still present. There isn't any possible workaround?

cog.rusty’s picture

I am not an expert but I wouldn't have high hopes. PHP's "safe mode" has been treated as a pathological situation in the past too. Currently the color module does not even work at all with the "private download method", which is much more common situation than "safe mode".

Possible solutions...

- Color module finds a way to create directories owned by yourself. Something similar to FTP. I have no idea how, but (a) logically it would need your web accounts login/password and (b) such a Drupal mechanism seems too much to expect for a cosmetic core module such as the color module. Other methods such as SUID scripts are "iffy" and dangerous.

- Color module uses just one directory which you can create yourself and allow access, just like the files directory. This seems more realistic.

If none of the above... I think it will be just "php safe mode is not supported."

serving’s picture

Hi all

I did a chmod 777 on the files/color dir and the dir garland-1f2ee811 in it generated by the module to contian the style.css .

That garland-1f2ee811 keeps changing with every color chagne.. Right now the files/color is full with 10s of such dirs. Should'nt there be a way to clean up those dirs?

Also, files menu-collapsed.gif menu-expanded.gif menu-leaf.gif are copied inside every garland-xxxxxxxx file created. How come styles.css could not be created there ?

Serving

cog.rusty’s picture

Back to the old issue then...

The difference is that those three files are just copied while style.css and the other images are rewritten (fwrite). What that means, is the next question.

jhm’s picture

The difference is that those three files are just copied while style.css and the other images are rewritten (fwrite). What that means, is the next question

looking up the copy command at php.net explains it. Writing files is ok as long as the permissions are ok, even under safe_mode. Copying files is crippled under safe_mode.

A work-around for color.module could be to write the files instead of copying them. That is open the file and then create a new file and write the stream to it.

cog.rusty’s picture

Actually the 3 unmodified copied files were the ones which got written. Which made me wonder if writing on a copy would work for the other files too. A mystery.

cog.rusty’s picture

Oh, and I am not sure this was also a safe mode case.

Lenz Grimmer’s picture

I observed the same problem on a fresh installation of 5.0b2 - after toying around with the Colors in the Garland Theme and saving the changes, I ended up with a blank page and the CSS was borked afterwards. I checked the Apache error log and noticed the following error:

[Thu Nov 30 01:32:47 2006] [error] [client 127.0.0.1] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1726720 bytes) in /srv/www/htdocs/drupal/modules/color/color.module on line 340, referer: http://localhost/drupal/?q=admin/build/themes/settings/garland

I then changed memory_limit in php.ini from 8MB to 16MB - now it works just fine.

Hope that helps!

cog.rusty’s picture

In this case color module's allocated 1.7MB was just the straw which broke the camel's back.

jhm’s picture

Even though I agree with a previous post that safe_mode should not be supported because that makes life easier, there would be a possibility to prevent color.module from doing harm in case safe_mode is true.

I added a function in color.module

function _is_safe_mode_safe ( ) {
	$safe_mode = ini_get("safe_mode");$safe_mode = empty($safe_mode) ? 0 : $safe_mode;
	if($safe_mode and getmyuid() != posix_getuid()){
		return false;
	} else {
		return true;
	}
}

and altered the color.module::color_form_alter function to look like this

function color_form_alter($form_id, &$form) {
  // Insert the color changer into the theme settings page.
  // TODO: Last condition in the following if disables color changer when private files are used this should be 
  // solved in a different way. See issue #92059.
  if ($form_id == 'system_theme_settings' 
      && color_get_info(arg(4)) 
      && function_exists('gd_info') 
      && variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC) == FILE_DOWNLOADS_PUBLIC) {
    $form['color'] = array(
      '#type' => 'fieldset',
      '#title' => t('Color scheme'),
      '#weight' => -1,
      '#attributes' => array('id' => 'color_scheme_form'),
      '#theme' => 'color_scheme_form',
    );
// new code to check for safe_mode
if(_is_safe_mode_safe()){
  $form['color'] += color_scheme_form(arg(4));
  $form['#submit']['color_scheme_form_submit'] = array();
}else{
  unset($form['color']['#theme']);
  $form['color']['#description'] = "this function is not available under safe_mode";
  $form['color']['#description'].= " as long as ".__FILE__." belongs to ".getmyuid()." instead of ".posix_getuid();
}

  }
  // Use the generated screenshot in the theme list
  if ($form_id == 'system_theme_select_form' || $form_id == 'system_themes') {
    $themes = list_themes();
    foreach (element_children($form) as $theme) {
      if ($screenshot = variable_get('color_'. $theme .'_screenshot', NULL)) {
        if (isset($form[$theme]['screenshot'])) {
          $form[$theme]['screenshot']['#value'] = theme('image', $screenshot, '', '', array('class' => 'screenshot'), FALSE);
        }
      }
    }
  }
}
serving’s picture

well well well

adding "php_value memory_limit 124M" to .htaccess solved the problem. I can change colors without the blank page now..

Thank you Lenz Grimmer for sharing your solution..

I wonder why I did not see any error in my error_log though?

Serving

cog.rusty’s picture

You mean that the other files beside menu-collapsed.gif, menu-expanded.gif and menu-leaf.gif were created too with this memory fix?!

serving’s picture

Yup.

bg-bar-white.png bg-navigation-item-hover.png gradient-inner.png screenshot.png
bg-bar.png bg-navigation-item.png logo.png style.css
bg-content-left.png bg-navigation.png menu-collapsed.gif
bg-content-right.png bg-tab.png menu-expanded.gif
bg-content.png body.png menu-leaf.gif

are there now.

cog.rusty’s picture

Nice! So, it seems that is not an issue for the color module any more and the only remaining issues are the postponed task for private downloads and the safe mode restrictions problem.

cog.rusty’s picture

By the way, 124M is too much and will probably have a performance impact. 16M or 24M max should cover any site.

chx’s picture

Priority: Critical » Normal

I am on the edge of won't fixing this. Obviously the 124M is a typo and it's either 12M or 24M both of which is enough. Drupal is a memory hog, this is alas well known. I am on the case -- for Drupal 6.

Steven’s picture

Title: Thanks to Drumm's checklist » Check memory usage before changing color scheme
Priority: Normal » Critical
Status: Active » Needs review
FileSize
2.38 KB

It seems there are two issues here. 1) Problems with safe mode, 2) Problems with running out of memory.

There is not much info about the first one, and I don't know enough about safe mode to comment. I suggest you open up another issue if this is still a problem.

I've attached a patch for the second problem. The memory usage peaks when blending the base.png over the compositing buffer for the final images. At this point, we will have two 32-bit RGBA images in memory, both having the same dimensions as base.png. After this, we deallocate one of them, and from then on we only create small images for the slices (which are, by definition, smaller than base.png). So, we make sure we have enough memory to fit base.png twice in memory, as an uncompressed 32-bit RGBA buffer.

If PHP memory limits are turned off, nothing happens.

I added a parse_size() function to common.inc. It mirrors format_size() and also parses PHP.ini style byte sizes (e.g. "3M" "5K").

pwolanin’s picture

Status: Needs review » Needs work

file.inc already includes a similar helper function used by the upload module:


/**
 * Helper function for file_upload_max_size().
 */
function _file_convert_to_mb($val){
  $val = trim($val);
  $last = strtolower($val[strlen($val) - 1]);
  switch ($last) {
    // The 'G' modifier is available since PHP 5.1.0
    case 'g':
      $size = $val * 1024;
      break;
    case 'k':
      $size = $val / 1024;
      break;
    default:
      $size = (int) $val;
  }
  return $size;
}

Either use this function, or replace it- no sense in having a redundancy.

Steven’s picture

Status: Needs work » Needs review
FileSize
3.8 KB

My function is written to be more generic: it parses both php.ini style sizes (123M, 123K, 123, ...) as well as the prettier format output by our own format_size function (123 MB, 123 KB, 123 bytes).

I removed _file_convert_to_mb() and updated file.inc. See attached patch.

neclimdul’s picture

I hate to nitpick but shouldn't we solve out the constant multipliers for sites that don't have optimizers?
For example:

$suffixes = array(
  '' => 1,
  'k' => 1024,
  'm' => 1048576, // 1024 * 1024
  'g' => 1073741824, // 1024 * 1024 * 1024
);

This also seems to be the approach taken by some other functions like format_interval.

ChrisKennedy’s picture

The link should probably point to www.php.net rather than a specific mirror (ca3.php.net).

ChrisKennedy’s picture

Also, in the regex I would make the 's' in 'bytes' optional. If $size == 1 bytes shouldn't be plural, although I have filed a separate bug to fix format_size (http://drupal.org/node/101757).

webchick’s picture

Status: Needs review » Needs work
Steven’s picture

FileSize
3.8 KB

If you're going to nitpick about irrelevant details, please just reroll the frickin' patch.

Steven’s picture

Title changes don't stick?

ChrisKennedy’s picture

I don't reroll patches unless I get confirmation that a suggestion is correct, which is why I also didn't change the status.

Steven’s picture

Status: Needs work » Needs review
ChrisKennedy’s picture

Status: Needs review » Reviewed & tested by the community
ChrisKennedy’s picture

FileSize
3.8 KB

Tested and works correctly. I changed the url to www.php.net and added 'error' as the second parameter to drupal_set_message().

neclimdul’s picture

Sorry, nit picked b/c wasn't at a computer where I could easily make a patch.
Same code with math expressions solved. I'm fine with either of these patches but this looks very RTBC if everyone is ok with the function change.

neclimdul’s picture

FileSize
3.85 KB

And my patch...

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed. Thanks!

netbjarne’s picture

I have the color module working now, on my php safe mode enabled host. This is a quick hack, and it might have consequenses that I'm not yet aware of, but still.

Background: The php safe mode breaks drupals posibility of creating folders, and accessing them afterwards. My work around for that problem, is to create the needed folders (/files, /files/tmp, /files/color) by hand, using FTP. The color.module, for some reason, wants to create folders with random names (/files/color/garland-89528344) - where the number is random. I wanted to stop that, so I can predict the folder name, and create the folder for color.module to put its files.

At line 212 of color.module I found this:
$id = $theme .'-'. substr(md5(serialize($palette) . microtime()), 0, 8);/

I commented out the randomizing stuff, ending with this:
$id = $theme; /* .'-'. substr(md5(serialize($palette) . microtime()), 0, 8);*/

And saved. Now instead of storing generated files in /files/color/garland-29429525 - files are now stored in just /files/color/garland - allowing me to create the garland and 777'ing it on beforehand. And it works!. I have to refresh the page, once new colors are generated, to have my browser recognize it, but thats it...

Now - I'm not going to say, this is a good patch ready for commitment. But I think, it is a good proff of concept. The color.module can made to work on host with php safe mode as well.

Bjarne

bcn’s picture

Version: 5.0-beta2 » 5.0-rc1

I just installed 5.0-rc1 and am still having problems with the color module. Upon first usage of the module, i was able to successfully change the color of the garland theme. However, i had to reinstall, and when i tried to change the color of the theme after a reinstall, I get the out of memory error.

FYI:
PHP 5
Apache
Drupal 5-rc1

kongondo’s picture

Hi,

I was also not able to change garland's colors. I found the problem to be the .htaccess file in /files/ folder. I commented out the last two lines like (see below) this and I was able to change garland's colors. However, my garland folder in /files/color/ disappeared when I was trying to change it's permissions and whenever I recreate another it just disappears. Does commenting out those lines pose a security problem? Thanks.

# Options None
# Options +FollowSymLinks

SERVER SETTINGS

PHP safe mode is on on my host server
PHP 5.2
Apache
Drupal 5-rc1

kongondo’s picture

Sorry, i should have done better research. Ignore my previous post; questions answered :D

Thx,

Steven’s picture

Note: the reason we use random directory names is to avoid the browser caching the stylesheet or images from a previous color scheme.

Anonymous’s picture

Status: Fixed » Closed (fixed)
dkatzman’s picture

Version: 5.0-rc1 » 5.0
Status: Closed (fixed) » Active

Hi,

I have tried EVERY solution I found in this and other topics for the color changer problem with the SAFE MODE error. The only solution I see as plausible is to stop Drupal from randomizing the created folders so I can chmod the folder and allow Drupal to place the files (BTW I don't get ANY files at all). Solution in the comment #107 from netbjarne seemed plausible... I'm running Drupal 5.0 so the line to be changed in color.module is 229. The problem is that when I change it Drupal breaks, I get this error:

syntax error, unexpected T_FUNCTION in /mounted-storage/home39c/sub003/sc30883-FDZZ/mysite.com/modules/color/color.module on line 269

Please help me, and hundreds of Drupal users it seems, find a solution! I believe THIS IS a critical issue, after all Garland is the default theme and color customization is the most basic look improvement users have.

In the meantime, I just need Garland with the Belgian Chocolate color set... Could anyone please create a version for me and send it to cyrik@hotmail.com? It's no fix... But at least I'll have what I need right now...

Thanks in advance and congratulations on a great system,

DK

  • www.secretia.com
  • www.unmentor.com
  • www.mythos.es
  • www.jewishculturela.org
  • www.profesorblog.com
  • www.drbolsa.com
  • www.certifik.org
  • Heine’s picture

    Version: 5.0 » 5.0-rc1
    Status: Active » Closed (fixed)

    @dkatzman, please open a new thread (or support issue) for this.

    Oh, and can you please cut back on the signature? Esp. in the issue tracker.

    Jonathan Webb’s picture

    Version: 5.0-rc1 » 5.1
    Priority: Critical » Normal
    Status: Closed (fixed) » Active

    I am having a color-scheme problem in Drupal 5.1. On a fresh install I changed my filesystem to "private" and setup a files directory not accessible over the web (as suggested). After this I attempted to alter the color scheme of garland and noticed that no color picker was there (because there is no color folder created anywhere, I presume). I see other users have had this problem, but don't see a solution.

    I think the root question is: why is the color module using a folder assigned for file transfers?

    cog.rusty’s picture

    About the "Private" setting, since these discussions it has been documented that the color picker will be disabled.

    There are workarounds, for example producing the color scheme in another installation and copying it as a named subdirectory under the Garland theme's directory.

    About the "root question", I am not sure I understand what you mean. If you mean "Why does it have to write inside the 'files' directory" (wherever that is), the answer probably is that according to the "big plan" that is the only directory designed to allow the server to write in.

    Darren Oh’s picture

    You should search to see if anyone has created an issue to request that Drupal have a writable directory that is always public. If you don't find an existing issue, you should submit a feature request.

    Darren Oh’s picture

    Wait, that's stupid. The sites directory is supposed to be that. Color picker ought to save its files there.

    Darren Oh’s picture

    Status: Active » Closed (fixed)

    Let's not reopen this old issue. Discussion continues in issue 181003.