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?


tstoeckler’s picture

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.

tstoeckler’s picture

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.

whyscream’s picture

Status:Closed (fixed)» Active

I totally missed the response to this issue. Just verified that this issue is still existing in libraries API 7.x-2.x dated 2014-Oct-12.

I created a module that includes a third-party library. The module is available at https://github.com/whyscream/clubplugin. The library files are restricted, but they're simply 2 css files, named 'style.css' and 'grey.css'.

Trying to use the 'style.css' using libraries api in the module code results in its contents not being applied to the page. After renaming the file (actually symlinking) to a unique name, and using that new name in the module code, all is fine.
See https://github.com/whyscream/clubplugin/blob/master/clubplugin.module#L158 for my implementation.

IMHO easiest way to reproduce is producing a very basic module that loads a library css file named 'style.css' unconditionally, and have that css file apply some really ugly background-color to all pages, or something like that. I'd be happy to do that when this issue is still relevant.

NB Normally I wouldn't follow up on a 2 year old issue, but when this is a core bug, it seems useful enough for a re-open.