Path to custom CSS not working [#1169148]

Is there anything in 7.x that would prevent the path to a custom CSS file from working? When I set my path to %t/css/print.css, the styles are not read, but if I overwrite the module's print.css with that file and delete the path from the settings, then things are styled the way I want.

I found an old issue saying you needed to use %b at the beginning of the path, but this issue has clearly been fixed because if you attempt to add that macro you get an error (and also the instructions now tell you the path should be relative to the base.)

Am I crazy? I can't get this to work.

Comment	File	Size	Author
#5	print-1169148-5.patch	496 bytes	bradjones1
#5

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

candelas CreditAttribution: candelas commented 28 May 2011 at 19:56

the same happens with 6.20
thanks for the module.

Comment #2

jobe12 CreditAttribution: jobe12 commented 1 June 2011 at 02:31

The same issue
I used this patch and everything worked http://drupal.org/node/1110046#comment-4341870. It fixed my print.css issue.

Comment #3

candelas CreditAttribution: candelas commented 1 June 2011 at 10:10

thanks @jobe12 for the link to the path.
i will try it tomorrow to see if i can fix the problem in my site :)
i am in 6.20.
which version do you use?

Comment #4

jobe12 CreditAttribution: jobe12 commented 2 June 2011 at 03:45

i am using 7. i think you should check issues for your drupal version.

Comment #5

bradjones1

English

CreditAttribution: bradjones1 commented 5 June 2011 at 19:31

Status:

Active

» Needs review

File	Size
print-1169148-5.patch	496 bytes

Also experiencing similar behavior - without a custom css variable set, the module's takes over as expected. However neither a hard-coded path to the theme nor the %t placeholder appears to work.

This is because if the custom CSS is in a theme directory - which most probably are - it was added in and then immediately stripped along with all the other theme stylesheets. I've just added in an AND to the filter to ensure it's not stripping that custom file we just added. Here's a patch against HEAD.

Comment #6

whitefluffy CreditAttribution: whitefluffy commented 16 June 2011 at 15:43

Status:

Needs review

» Reviewed & tested by the community

I had the same problem, and the patch by bradjones1 solved the problem. Works great for me.

Using 7.x-1.x-dev version.

Comment #7

jcnventura CreditAttribution: jcnventura commented 13 July 2011 at 16:58

Status:

Reviewed & tested by the community

» Fixed

@bradjones1: thanks a lot for the patch.

Unfortunately, the proper solution to this problem is to use the declared CSS group, but your patch reminded me that this quick hack was not the solution (I think I wrote this before CSS groups got introduced in Drupal core)

Anyway, this should now be fixed in dev.