Closed (fixed)
Project:
Skinr
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Sep 2010 at 18:39 UTC
Updated:
8 Oct 2010 at 19:30 UTC
Jump to comment: Most recent file
I'm developing a subtheme for Fusion 6.x-1.0 and Skinr 2.x-dev,. Until the August 26 version of Skinr 6.x-2.x-dev, all was well. Since then, skin options are appearing in the modal and choosing an option adds the css class to the element, but the css file isn't being referenced in the head. I'm putting the skins in /sites/all/skins (btw, nice idea for making it easier to share skins). Probably user error--did the location or method of referencing css files change?
Loving Skinr 2. Wish I could do more than just send user feedback, but hope it helps.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | skinr_904628_css.patch | 886 bytes | ericduran |
Comments
Comment #1
kdmarks commentedForgot to mention that when I roll back to the skinr.module,v 1.13.2.6.2.31 2010/05/01 file, everything is fine and stylesheets get referenced.
Comment #2
jacineCan you please post the code you are using? Maybe it's a syntax issue? Thanks :)
Comment #3
kdmarks commentedHere's an example from /sites/all/skins/blocks/asufusion-blocks.info:
Comment #4
jacineThanks :) As long as your CSS file is in /sites/all/skins/blocks/asufusion-blocks.css, I would say this is most likely a valid bug ;)
If you move the Skin back to the theme .info it works I assume...? Will try to test this locally when I get a few minutes.
Comment #5
kdmarks commentedYes, my css file is in /sites/all/skins/blocks/asufusion-blocks.css, and everything works when i roll back the skinr.module file to the earlier version. If you need any other files or info, let me know.
BTW, skins in the theme .info file work fine. It's only /sites/all/skins that isn't working.
Comment #6
g76 commentedHi,
I have the same issue, could very possibly be doing something wrong on my end though.
Comment #7
nomonstersinme commentedI can confirm this as a bug.. looking through the function skinr_skin_get_files it seems its only looking for external files in the themes directory.
Comment #8
g76 commentedwould placing a copy of the skin directories in the theme itself, temporarily serve as a fix? And would it find it at sites/all/themes/themedir/css/myskinset/ or sites/all/themes/themdir/skins/myskinset/, or would the individual css files have to reside directly in the themes css directory with no myskinset subdirectory.
Sorry if I am making this more confusing than it needs to be, I was just hoping something would work. I would be more than happy to test anything, just let me know what I can do.
Comment #9
ericduran commented@g76, would you mind trying something for me ?
I think the stylesheets are being loaded with the wrong path.
There's a block of code the the _skinr_skinset function that look like this (it should be line 730)
Would someone try commenting the if statement so it looks like this
Let me know if this works. I'm not saying this is the solution. I just think the path is never being added to those css/js that are not in the theme directory.
If this fixes your problem I'll look at the code in more detail and come up with an actual patch. (sorry, not in front of a pc right now).
Comment #10
ericduran commentedOk, so I reviewed the code. The problem was the correct path not being added to the css/js. (skinr was just adding the right path to skin that where inherited and it was ignoring every other skin).
This patch should fix this problem.
Comment #11
g76 commentedthank you:),
I was going to do that for you, I just got back in. Let me test that and get back to you. I should be able to do this within the next few hours. Is there anything else I can test as well?
thanks again,
Jen
Comment #12
ericduran commented@g76, You can just test the patch now. It should fix your problem.
Comment #13
ericduran commentedOh you might also want to try moving the skins around. I testing in sites/all/skins and sites/themes/themename/skins. They both seem to work for me.
Comment #14
g76 commentedshould I comment out the if statement? I didn't see it in the patch file, but it could very well be me, I am taking multi-tasking to a whole new level today:)
Comment #15
ericduran commented@g76, no need to comment out the if statement. The if statement is still needed for skins that are inherited.
The patch fixes the issue by moving the _skinr_add_paths_to_files function out of the if statement. Which I believe shouldn't be there.
Comment #16
kdmarks commentedThank you so much! The patch works beautifully.
Comment #17
moonray commentedAs per #16 it works.
Comment #18
g76 commentedworks great, thank you!
Comment #19
jacineCommitted :) Thanks!
http://drupal.org/cvs?commit=426986