I'm currently writing a module that uses some third-party css files that I load with libraries api. The thirdparty providing the css files has chosen very generic filenames, and one of the files is named 'style.css'. This file is not loaded by Drupal. After going through the code, it seems to me that the file name conflicts with bartiks 'style.css', and Drupal core (drupal_add_css etc.) doesn't include the file because of this (probably: the theme css file will override the plugin file by design).

While this is not a Libraries API issue per se, there must be more library providers that trigger this issue. I was wondering if libraries API should think about a workaround that makes it possible for implementors to fix this inside the plugin without one of the harder alternatives:
- rename the library files after unpacking them (thereby making install instructions for libraries harder to fllow correctly)
- file a bug report at the third party library about changing the naming conventions (depending on the that party who may be propritary, has a large installbase already, etc etc)

I'm thinking along the lines of some attribute in hook_libraries_info() that triggers libraries api to copy/symlink the library file to a cache directory while prefixing it with the library name, and then pass that file to drupal core for further processing. Does this make any sense?

Comments

Category:feature» support
Status:Active» Postponed (maintainer needs more info)

Hmm, I seem to have missed this issue so far. Sorry for that.

If this is in fact true that drupal_add_css() does not work for something like style.css then that is certainly a Drupal core bug. Can you point me to the library and module you encountered this problem with. If I could reproduce this, that would be nice.

Issue summary:View changes
Status:Postponed (maintainer needs more info)» Fixed

Marking fixed. If you are still experiencing problems, please re-open.

Status:Fixed» Closed (fixed)

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