Closed (fixed)
Project:
Sky
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Nov 2008 at 09:33 UTC
Updated:
11 Apr 2009 at 20:17 UTC
Hi,
When we switched to private download method for serving files, the sky theme unexpectedly switched back to (default) fixed width instead of the fluid we had choses.
The problem is caused by a file path (c:/wamp/files/sky/custom.css) that is not properly rendered into the /drupal/system/sky/custom.css it should be for this download method.
The custom css is correctly created btw inside the c:/wamp/files/sky/ directory but not included in the final web pages correctly (it's included as http:///drupal/c:/wamp/files/sky/custom.css).
Comments
Comment #1
palazis commentedHello,
Thanks for the excellent theme.
I can confirm that after changing the download method to private, the (default) fixed width is used instead of the chosen one.
Additionally, all the other settings (e.g. fonts, etc) are also ignored.
Most probably the cause is the one mentioned by wvd_vegt.
A fast fix is to embed each and every line of custom.css into style.css.
Of course, it would be much better if this could be fixed in a more "official" way, e.g. by providing a new release.
Thanks in advance
Comment #2
aimutch commentedMy understanding of the private download method is that you are supposed to use relative paths, not absolute paths like C:\wamp\files\....
Try it again with a relative path and let us know if it's still not working.
Comment #3
jacineSorry for such a late response here, this is actually my first time seeing this issue :(
custom.css is a file that is generated according to what your choices are on the theme settings page. I think it's permissions issue caused by setting files to private. As far as I am aware, Drupal only has permission to generate files in the files directory, which is why it's not generated in the theme folder in the first place. There are limitations with Drupal that I am aware of when using Private downloads... For example:
These methods require files to be created in the files directory, like the custom.css file in the Sky theme, so really it's not a bug with the theme, it's a limitation of Drupal as a result of settings downloads to private.
The only thing I can think of to make it work, is to print the generated CSS in the
<head>tag, which I would rather not do, since it's a sloppy way of doing it. Of course embedding the code manually in style.css at the very bottom would work too, though that's not a great solution either.Maybe someone has a better idea? If not, I'm going to mark this issue "Won't fix" though I really mean "Can't fix" ;)
Comment #4
wvd_vegt commentedHi,
It's just the link generated that's not correct (so more a code problem). The css is generated correctly at the place where it should. It's however not included properly. Maybe it's an idea to use/geneate a php script that emits the css with proper mime type (see the following firefox observation below).
One thing though that gives problems (accoriding to my notes) is that firefox has problems with a wrong mimetype when the file is located at files/sky.
Here is my version of the code & comments (note it tests for generated version but uses a manual copy):
$custom_css gets a value of 'c:/wamp/files/sky/custom.css' which becomes something like
http:///drupal/c:/wamp/files/sky/custom.css when used in an hyperlink. And that is an invalid link causing it not to be doenloaded & included as it should.
Comment #5
wvd_vegt commentedHi,
I have got a solution for the problem.
1) In Template.php only use drupal_add_css for public downloads (drupal_add_css fails for private stylesheets).
2) Extend the function _sky_conditional_stylesheets() a bit so it adds the stylesheet after the conditional ones if the download method is private:
3) Now the funny part. When drupal serves a file from base_path().'/system/files' it always seems to use a mimetype of 'application/x-download' unless a module overrides it in a hook_file_download().
This is where FireFox stumbles (IE and others just homour the mime type supllied in the html, FireFox looks to the actual download too and then just refuses it).
Baseline I wrote a very small sky module that supplies the correct mime type when downloading the custom.css file if the download methods is set to private.
Sky.info:
Sky.install:
<?php
sky.module:
So basically for sites with a public download method nothing changes. For private download the location of the custom.css include changes a bit and for FireFox a small module needs to be installed and activated.
As far as i can see the only thing not 100% correct is that if the cache is cleared, the custom.css is not forces to be re-downloaded (by appending random query suffix).
Comment #6
jacineVery interesting...
I'm not 100% sold on adding a module to maintain in order to use the theme, just because of private downloads because I don't believe a contrib theme should contain a module to work properly:
However, IMHO, if this is considered an acceptable solution it would most likely be more useful as an optional standalone module or even core patch because:
Comment #7
aimutch commentedI agree that this should be a problem addressed in the Drupal core code. If Drupal enables this kind of feature, the problem should be fixed there, not at the theme level.
Comment #8
wvd_vegt commentedHi,
Off-course I do agree with both previous posts, I just added the module for those wanting a fix now (even though it's clumsy and should be fixed in the Drupal core).
We use the module with some FireFox users (including our boss) with private upload method and variable width (so a very special case).
So it should not be considered a patch but merely a want to get it working until it's properly fixed in the core (and only if you have this kind of setup). It took me a while to figure out whats causing it and documenting it in a fix is perhaps the best way.
Btw for those using it, you should change the name as a module and a theme with the same name is someting Drupal doesn't like (I know named it sky_fix).
Maybe promoting it as a separate module isn't a bad idea so you can fix certain mime types causing problems.
Comment #9
jacine