ctools css files don't load with private system

Crap. drupal_add_css() basically doesn't work with a private file system.

For now, I don't have a good solution beyond suggesting using .htaccess and rewriting the paths and using a symlink so that the files/ctools/css directory can be in a public location.

I was looking at color.module to see how it handles this...and as near as I can tell, it doesn't handle this either.

It seems like there should be an alternative to do drupal_set_html_head if using a private filesystem, but that's going to require more than a quick fix to the css caching system for that to work.

AFAIK private fs is very broken in many aspects. When I tried to use it in 5.x I always had issues in one module or another. Basically, there is not much of testing of private fs in Drupal contrib modules, so you gonna have issues.
If I was you, I would go for some combination of public and private filesystems. Anyway private fs usually needed when you want to limit access to some private info (hence the name) and I doubt CSS files contain such information :-)

There is no way to combine private/public in Drupal, which is a problem.

It seems there are workarounds for that: I remember reading about some module that implements it, probably it was some CDN implementation. But they may need core patching, dunno.

There is no way to combine private/public in Drupal, which is a problem.

Bummer, I was hoping to find a way to still use the "Optimize CSS and JS files" feature with the private file system but hearing this from your mouth is not good!

I searched Google for "drupal optimize css files with private files" and this was #1.

We have to use the private file system for one site and with 36 css files and 9 js files it sure would be nice to make use of this feature.

Not a fan of people who subscribe with no useful input, but nor am I a fan of constant page not found errors clogging my access logs.

*subscribe*

Deciphered: There is unlikely to be a fix in Drupal 6. Alas, CTools derived modules are likely to be incompatible with the private file system. :/

@merlinofchaos.

That's ok, I did a bit of research as even Drupal core javascript translations suffer from this exact error so I can except it won't be fixed, I just wanted to tell myself that I was making some (if only half-assed) attempt to look into the issue instead of just accepting it.

hi,

I'm experiencing the same problem and I can't find any solution. Is there now a solution for this problem or do I have to work with "public file system"?

Thanks.

PS: I'm sorry if I've selected the wrong Status/Category/Priority. I wasn't sure what to select.

Have the same issue though I only need to protect a single directory. I stumble upon this article in the IRC channel. http://www.drupalcoder.com/story/406-mixing-private-and-public-downloads.... This might be a solution, at least for me. By doing this are still keeping the public mode but are able to run this redirect through Drupal's access system.

Anyone seeing any security problems with this hack?

There are some experimental changes in the latest CTools -dev that might actually work with private file systems. They are experimental and I don't remember if they are complete, though.

Ok, I've verified that I needed to implement an additional hook in CTools to get this to work:

function ctools_file_download($filepath) {
  if (strpos($filepath, 'ctools') === 0) {
    $mime = file_get_mimetype($filepath);
    // For safety's sake, we allow only text and images.
    if (strpos($mime, 'text') === 0 || strpos($mime, 'image')) {
      return array('Content-type:' . $mime);
    }
  }
}

I checked this into CTools but if you just add that to the end of ctools.module I think private file systems will work.

I noticed Panels was trying to use CSS caching incorrectly in a couple of spots, so rounded corners and flexible.inc need updates too (I checked those in as well).

Sorry to reopen, but it is still broken. The CSS files are served, but as "application/x-download" type (in my setup it was thanks to IMCE.module's default clause in imce_file_download()). That makes Firefox and Chrome just ignore CSS files.

I baked this solution in few minutes:

function <mymodule>_file_download($filepath) {
  $path = file_create_path($filepath);
  if (strrpos($path,'.css') == strlen($path)-4 && 
    variable_get('file_downloads', NULL) == FILE_DOWNLOADS_PRIVATE) {
    return array('Content-Type: text/css; authoritative=true', 'Content-Length: '. filesize($path));
// This is a hack / fix for .CSS files not properly served when private download method is enabled.
  }
}

The corners are back with the above.

@merlinofchaos, maybe you can roll a .CSS type check like this into CTools?

CTools has this code:

/**
 * Implementation of hook_file_download()
 *
 * When using the private file system, we have to let Drupal know it's ok to
 * download CSS and image files from our temporary directory.
 */
function ctools_file_download($filepath) {
  if (strpos($filepath, 'ctools') === 0) {
    $mime = file_get_mimetype($filepath);
    // For safety's sake, we allow only text and images.
    if (strpos($mime, 'text') === 0 || strpos($mime, 'image') === 0) {
      return array('Content-type:' . $mime);
    }
  }
}

That should work just fine for text/css unless file_get_mimetype() somehow fails. I've tested this previously and it was working, so I'm not sure what's wrong for you. Your code hardcodes the .css stuff, but file_get_mimetype() should be working here. I would need some debug information to explain why this code is not working to implement any kind of hardcoding.

Thanks for the pointer, I looked into file_get_mimetype - it does indeed return text/css for .css files.

I also reviewed other modules, and IMCE was screwing up by adding application/x-download in its else statement, but it was old version of IMCE. So I updated IMCE, and newer version has added file_get_mimetype clause now, so it works fine after the update.

I don't know if "authoritative" statement in content-type would have made any difference (Content-Type: text/css; authoritative=true).

Back to closed.

giorez,

This issue has been closed for almost a year, please don't re-open it, instead create a new issue and if you think anything in this issue is relevant then link to it.

Cheers,
Deciphered.

Reopening a 1 year old issue to do nothing other than point to another already open issue is wrong. Multiple issues for the same problem duplicates effort and creates confusion. Doing this is a great way to upset anyone who might be able to help you. Don't do it.