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.

CommentFileSizeAuthor
#10 skinr_904628_css.patch886 bytesericduran

Comments

kdmarks’s picture

Forgot 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.

jacine’s picture

Can you please post the code you are using? Maybe it's a syntax issue? Thanks :)

kdmarks’s picture

Here's an example from /sites/all/skins/blocks/asufusion-blocks.info:

name = Block styles
description = Various block style skins
version = 6.x
core = 6.x
package = Blocks

; BLOCK STYLES
skinr[options][groups][blocks][title] = Block styles

; Block styles
skinr[asufusion_block][title] = Block colors
skinr[asufusion_block][type] = select
skinr[asufusion_block][group] = blocks
skinr[asufusion_block][features][] = block
skinr[asufusion_block][features][] = panels_pane
skinr[asufusion_block][features][] = panels_display
skinr[asufusion_block][features][] = panels_panel
skinr[asufusion_block][features][] = views_view
skinr[asufusion_block][description] = Select a style for this block.
skinr[asufusion_block][stylesheets][all][] = asufusion-blocks.css
skinr[asufusion_block][options][1][label] = Solid maroon
skinr[asufusion_block][options][1][class] = asufusion-solid-maroon
skinr[asufusion_block][options][2][label] = Solid gold
skinr[asufusion_block][options][2][class] = asufusion-solid-gold
skinr[asufusion_block][options][3][label] = Solid ASU gray
skinr[asufusion_block][options][3][class] = asufusion-solid-gray
jacine’s picture

Thanks :) 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.

kdmarks’s picture

Yes, 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.

g76’s picture

Hi,
I have the same issue, could very possibly be doing something wrong on my end though.

nomonstersinme’s picture

I 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.

g76’s picture

would 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.

ericduran’s picture

@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)

    if (!empty($skinset['options']['inherit_skins'])) {
      // Add paths to $skinr_info.
      _skinr_add_paths_to_files($skinr_info, $path_root);
      // Paths get automatically added to base theme info.
      $base_info  = skinr_inherited_skins($info->name);
      // Merge base theme and current.
      $skinr_info = array_merge($base_info, $skinr_info);
    }

Would someone try commenting the if statement so it looks like this

    //if (!empty($skinset['options']['inherit_skins'])) {
      // Add paths to $skinr_info.
      _skinr_add_paths_to_files($skinr_info, $path_root);
      // Paths get automatically added to base theme info.
      $base_info  = skinr_inherited_skins($info->name);
      // Merge base theme and current.
      $skinr_info = array_merge($base_info, $skinr_info);
    //}

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).

ericduran’s picture

Status: Active » Needs review
StatusFileSize
new886 bytes

Ok, 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.

g76’s picture

Status: Needs review » Active

thank 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

ericduran’s picture

Status: Active » Needs review

@g76, You can just test the patch now. It should fix your problem.

ericduran’s picture

Oh 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.

g76’s picture

should 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:)

ericduran’s picture

@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.

kdmarks’s picture

Thank you so much! The patch works beautifully.

moonray’s picture

Status: Needs review » Reviewed & tested by the community

As per #16 it works.

g76’s picture

works great, thank you!

jacine’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.