Includes not being loaded

Hmm, that sounds like a bug to me :)

Thanks for the report, we'll look into it.

The skin CSS styles should not disappear. The permissions only pertain to applying a change of settings, not to displaying the CSS classes.

I'll have to look at why that seems to be happening though (perhaps a caching issue?).

Access control is working as it should, so I'm going to close this ;)

No don't close this yet! :)

I'm actually having the same issue. I'm only using skinr in blocks.

What's weird is that Skinr seems to be working on the admin part. For example, if you're looking at the administer blocks page, but does not work on the normal pages of the site that users see, even logged in.

I hope that makes sense. Let me know if you need me to be more descriptive.

Also, I've attached an image to show what I mean by the blocks page and the normal, regular pages.

Thanks

I've got a slew of demo sites I'm using it on and have never seen this sort of problem. Just showing a picture of the styling doesn't really tell me anything. The actual code showing or not showing the CSS class would be a better indicator.

There are a couple of reasons why this might happen...
1 - You could have the CSS aggregation on, need to flush your cache to get updated version of the CSS
2 - You could possibly be loading stylesheets for certain roles, or sections of the site
3 - Your paths to the background images in the CSS file could be wrong, etc..

Basically make sure the CSS file that contains your Skinr styles is actually loading on the page and that it's up to date.

Yep, CSS is loading fine. When I look at the block code in Firebug, it just shows class="" but in the blocks page, if you look at the code in firebug, it shows the correct class names (class="box")

All of my css is working perfectly, if I add the class name through firebug, the block displays correctly. So definitely not an issue with the css. Any other suggestions?

Are you sure you are printing the $skinr variable in the template file? Are you doing anything in preprocess that might affect that block or region?

It's really hard to me to guess what's going on without actually seeing your theme.

Hey Jacine,

It's earnest. So, i looked at this as I've had a simliar issue before with skinr ( but love the module ).

I think the issue has to do with the laoding of the includes. Example, if I added to the line around 580 and made the skir_fetch_data siganture look like:

/**
 * Fetch Skinr configuration data from modules
 */
function skinr_fetch_data() {
  // NOTICE NEW INCLUDE HERE
  require_once(drupal_get_path('module', 'skinr') . '/modules/block.skinr.inc');

  static $cache = NULL;
  if (!isset($cache)) {
    $cache = module_invoke_all('skinr_data');
    foreach (module_implements('skinr_data_alter') as $module) {
      $function = $module .'_skinr_data_alter';
      $function($cache);
    }
  }
  return $cache;
}

It works. notice that i have included the block include. So in my patched version, I am using the file include function in the handler to pre-load all the files in the /modules folder. At the time, I don't have time to roll out a complete patch, but I can perhaps over the weekend, but wanted to give you some insight. Perhaps you know more of the issue and have a larger picture as I may have just found a symptom and not a solution to the problem.

- e

Addendum: Note, with the /modules/block.skinr.inc not being included, when the module_invoke is run, the data for the blocks is never included. I'm surprise more people haven't run into this issue, so perhaps its user-error/bad-use.

Hey Earnest!!!

Thank you so much for chiming in.

I've discussed with moonray and although this isn't the right fix, it's definitely the problem. We'll need to figure out where it's not loading includes before all the other Skinr stuff.

Thanks for the help guys!

Oops, and ladies :)

haha, np geocalleo ;)

I can't seem to reproduce this problem using Aquia Prosper. I think the only way I'll be able to get to this is to have a list of modules that are enabled for this site, and any settings that aren't default.

Ah, yes that module is Skinr's arch enemy! :P

Thanks for reporting back to let us know. I'm glad we can close this one.