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
Comment | File | Size | Author |
---|---|---|---|
#105 | color_memory.patch.txt | 3.85 KB | neclimdul |
#103 | color_memory_2.patch | 3.8 KB | ChrisKennedy |
#98 | color_memory_1.patch | 3.8 KB | Steven |
#93 | color_memory_0.patch | 3.8 KB | Steven |
#91 | color_memory.patch | 2.38 KB | Steven |
Comments
Comment #1
webernet CreditAttribution: webernet commentedCould 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?
Comment #2
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedhad 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
Comment #3
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedhad 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
Comment #4
gregglesI can't reproduce this problem.
Can you look in your error log when you get this problem and see if that has any clues?
Comment #5
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedno obvious clues greggles...just a bunch of 'file not found' error messages
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
Comment #6
drummThe 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?
Comment #7
FiNeX CreditAttribution: FiNeX commentedI've just downloaded the drupal 5.0 beta, the problem is still present. I've checked the logs but I've found nothing.
Comment #8
jeffleeismyhero CreditAttribution: jeffleeismyhero commentedI 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
Comment #9
gregglesI 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.
Comment #10
drummPlease 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.
Comment #11
pcs305 CreditAttribution: pcs305 commented(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).
Comment #12
Dublin Drupaller CreditAttribution: Dublin Drupaller commented- 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:
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
Comment #13
drummSorry, 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.
Comment #14
webernet CreditAttribution: webernet commentedOK - 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?
Comment #15
FiNeX CreditAttribution: FiNeX commentedsoftware 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:
watchdog log
There is nothing relevant on the watchdog logs
Apache log
Apache report something interesting:
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>
Comment #16
FiNeX CreditAttribution: FiNeX commentedI've removed the .htaccess file on the "files" directory, and now it works!!!!
Comment #17
FiNeX CreditAttribution: FiNeX commentedI think this is a server configuration problem, not a Drupal one.
Comment #18
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedthanks 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
orgarland-e2aced97
And in those folders are 3 files:
Am stumped at this end..
Dub
Comment #19
greggles@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.
Comment #20
webernet CreditAttribution: webernet commentedTry disabling and then re-enabling color.module - it should give you a warning if there are any problems with the GD image toolkit.
Comment #21
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedHi 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:
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
Comment #22
drupal.padilla CreditAttribution: drupal.padilla commentedI 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/.....
Comment #23
cog.rusty CreditAttribution: cog.rusty commentedI 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/......"
Comment #24
cog.rusty CreditAttribution: cog.rusty commentedOh, 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.
Comment #25
cog.rusty CreditAttribution: cog.rusty commented@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).
Comment #26
mhs-1 CreditAttribution: mhs-1 commentedI 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).
Comment #27
cog.rusty CreditAttribution: cog.rusty commentedIn 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 .
Comment #28
webernet CreditAttribution: webernet commentedAnyone 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/
Comment #29
cog.rusty CreditAttribution: cog.rusty commentedI 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.
Comment #30
Jhef.Vicedo CreditAttribution: Jhef.Vicedo commentedI 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:
And on the correct one:
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.
Comment #31
cog.rusty CreditAttribution: cog.rusty commentedAlthough 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.
Comment #32
webernet CreditAttribution: webernet commentedAnother report: http://drupal.org/node/92449
Comment #33
Rok Žlender CreditAttribution: Rok Žlender commentedAs 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
I fixed this with an ugly hack (see attachment).
So now it looks like this
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.
Comment #34
cog.rusty CreditAttribution: cog.rusty commentedOh... 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?
Comment #35
Rok Žlender CreditAttribution: Rok Žlender commentedI 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.
Comment #36
Steven CreditAttribution: Steven commentedThe 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:
#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.
Comment #37
cog.rusty CreditAttribution: cog.rusty commentedAlthough 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.
Comment #38
Rok Žlender CreditAttribution: Rok Žlender commentedI 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.
Comment #39
Ryanbach CreditAttribution: Ryanbach commentedComment #40
azugaldia CreditAttribution: azugaldia commentedI 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):
Comment #41
Dries CreditAttribution: Dries commentedHi 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.
Comment #42
Rok Žlender CreditAttribution: Rok Žlender commentedI added a TODO and rerolled the patch to the latest version of color.module
Comment #43
chx CreditAttribution: chx commentedWe can always patch more... temprorary yes but good.
Comment #44
drummCommitted to HEAD (Sorry, vim did not want to put in 'Ž).
Now how do we fix this?
Comment #45
chx CreditAttribution: chx commentedI doubt this is a critical now...
Comment #46
chx CreditAttribution: chx commentedComment #47
netbjarne CreditAttribution: netbjarne commented"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
Comment #48
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedHI Bjaarne,
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
Comment #49
cog.rusty CreditAttribution: cog.rusty commentedWhat 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.
Comment #50
Chill35 CreditAttribution: Chill35 commentedI 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";Comment #51
Chill35 CreditAttribution: Chill35 commentedWhat 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.
Comment #52
Chill35 CreditAttribution: Chill35 commentedI 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 offiles/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!
Comment #53
netbjarne CreditAttribution: netbjarne commentedJust 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
Comment #54
havran CreditAttribution: havran commentedSimilar problem in color.module is mentioned here: http://drupal.org/node/97945 - Replace mkdir('my/path/') with mkdir('my/path')
Comment #55
serving CreditAttribution: serving commentedFresh 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
Comment #56
Dublin Drupaller CreditAttribution: Dublin Drupaller commentednavigate 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
Comment #57
Dublin Drupaller CreditAttribution: Dublin Drupaller commentedServing. 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
Comment #58
serving CreditAttribution: serving commentedHi 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
Comment #59
cog.rusty CreditAttribution: cog.rusty commentedThe 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.
Comment #60
chx CreditAttribution: chx commentedAs 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?
Comment #61
serving CreditAttribution: serving commentedHi 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
Comment #62
chx CreditAttribution: chx commentedThanks 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+');
addif (!$file) drupal_set_message('Unable to open for writing');
. This way, we will know where the error lies.Comment #63
serving CreditAttribution: serving commentedHi 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
Comment #64
cog.rusty CreditAttribution: cog.rusty commentedYou forgot to close a parenthesis in the second line, in (!$file).
And yes, a ";" is needed in the first one.
Comment #65
serving CreditAttribution: serving commentedThank 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
Comment #66
cog.rusty CreditAttribution: cog.rusty commentedHmm... 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...
Comment #67
serving CreditAttribution: serving commentedCool.. let me know if I can be of help..
Serving
Comment #68
cog.rusty CreditAttribution: cog.rusty commentedTry 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.
Comment #69
serving CreditAttribution: serving commentednop.. still don't see anything. :(
Comment #70
Darren OhComment #71
serving CreditAttribution: serving commentedI don't get it.. (chewing gum)
Comment #72
netbjarne CreditAttribution: netbjarne commentedProblem 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.
Comment #73
cog.rusty CreditAttribution: cog.rusty commentedThis 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...
Comment #74
jhm CreditAttribution: jhm commentedI 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:
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?
Comment #75
azugaldia CreditAttribution: azugaldia commentedJust 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?
Comment #76
cog.rusty CreditAttribution: cog.rusty commentedI 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."
Comment #77
serving CreditAttribution: serving commentedHi 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
Comment #78
cog.rusty CreditAttribution: cog.rusty commentedBack 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.
Comment #79
jhm CreditAttribution: jhm commentedlooking 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.
Comment #80
cog.rusty CreditAttribution: cog.rusty commentedActually 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.
Comment #81
cog.rusty CreditAttribution: cog.rusty commentedOh, and I am not sure this was also a safe mode case.
Comment #82
Lenz Grimmer CreditAttribution: Lenz Grimmer commentedI 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!
Comment #83
cog.rusty CreditAttribution: cog.rusty commentedIn this case color module's allocated 1.7MB was just the straw which broke the camel's back.
Comment #84
jhm CreditAttribution: jhm commentedEven 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
and altered the color.module::color_form_alter function to look like this
Comment #85
serving CreditAttribution: serving commentedwell 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
Comment #86
cog.rusty CreditAttribution: cog.rusty commentedYou mean that the other files beside menu-collapsed.gif, menu-expanded.gif and menu-leaf.gif were created too with this memory fix?!
Comment #87
serving CreditAttribution: serving commentedYup.
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.
Comment #88
cog.rusty CreditAttribution: cog.rusty commentedNice! 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.
Comment #89
cog.rusty CreditAttribution: cog.rusty commentedBy the way, 124M is too much and will probably have a performance impact. 16M or 24M max should cover any site.
Comment #90
chx CreditAttribution: chx commentedI 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.
Comment #91
Steven CreditAttribution: Steven commentedIt 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").
Comment #92
pwolanin CreditAttribution: pwolanin commentedfile.inc already includes a similar helper function used by the upload module:
Either use this function, or replace it- no sense in having a redundancy.
Comment #93
Steven CreditAttribution: Steven commentedMy 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.
Comment #94
neclimdulI hate to nitpick but shouldn't we solve out the constant multipliers for sites that don't have optimizers?
For example:
This also seems to be the approach taken by some other functions like format_interval.
Comment #95
ChrisKennedy CreditAttribution: ChrisKennedy commentedThe link should probably point to www.php.net rather than a specific mirror (ca3.php.net).
Comment #96
ChrisKennedy CreditAttribution: ChrisKennedy commentedAlso, 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).
Comment #97
webchickComment #98
Steven CreditAttribution: Steven commentedIf you're going to nitpick about irrelevant details, please just reroll the frickin' patch.
Comment #99
Steven CreditAttribution: Steven commentedTitle changes don't stick?
Comment #100
ChrisKennedy CreditAttribution: ChrisKennedy commentedI don't reroll patches unless I get confirmation that a suggestion is correct, which is why I also didn't change the status.
Comment #101
Steven CreditAttribution: Steven commentedComment #102
ChrisKennedy CreditAttribution: ChrisKennedy commentedComment #103
ChrisKennedy CreditAttribution: ChrisKennedy commentedTested and works correctly. I changed the url to www.php.net and added 'error' as the second parameter to drupal_set_message().
Comment #104
neclimdulSorry, 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.
Comment #105
neclimdulAnd my patch...
Comment #106
Dries CreditAttribution: Dries commentedCommitted. Thanks!
Comment #107
netbjarne CreditAttribution: netbjarne commentedI 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
Comment #108
bcn CreditAttribution: bcn commentedI 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
Comment #109
kongondo CreditAttribution: kongondo commentedHi,
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
Comment #110
kongondo CreditAttribution: kongondo commentedSorry, i should have done better research. Ignore my previous post; questions answered :D
Thx,
Comment #111
Steven CreditAttribution: Steven commentedNote: the reason we use random directory names is to avoid the browser caching the stylesheet or images from a previous color scheme.
Comment #112
(not verified) CreditAttribution: commentedComment #113
dkatzman CreditAttribution: dkatzman commentedHi,
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
Comment #114
Heine CreditAttribution: Heine commented@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.
Comment #115
Jonathan Webb CreditAttribution: Jonathan Webb commentedI 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?
Comment #116
cog.rusty CreditAttribution: cog.rusty commentedAbout 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.
Comment #117
Darren OhYou 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.
Comment #118
Darren OhWait, that's stupid. The sites directory is supposed to be that. Color picker ought to save its files there.
Comment #119
Darren OhLet's not reopen this old issue. Discussion continues in issue 181003.