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

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.

tstoeckler’s picture

Title: Workaround for ill-named library files » Implement/document a workaround for ill-named library files
Category: Support request » Task

Sorry for the long turnaround, I took a look at this and there's this gem in drupal_get_css()

  // Remove the overridden CSS files. Later CSS files override former ones.
  $previous_item = array();
  foreach ($css as $key => $item) {
    if ($item['type'] == 'file') {
      // If defined, force a unique basename for this file.
      $basename = isset($item['basename']) ? $item['basename'] : drupal_basename($item['data']);
      if (isset($previous_item[$basename])) {
        // Remove the previous item that shared the same base name.
        unset($css[$previous_item[$basename]]);
      }
      $previous_item[$basename] = $key;
    }
  }

So in fact you're right, Drupal will only load a single style.css per page. How bizarre!

Looking at the code linked to above, what might work is the following:

		'files' => array(
			'css' => array(
				'style.css' => array('group' => CSS_DEFAULT, 'basename' => 'clubplugin-style.css'),
				'clubplugin-grey.css' => array('group' => CSS_DEFAULT),
			),
		),

I.e. set a custom basename key. Can you see if that works? Then we can maybe consider doing something general in Libraries API.

whyscream’s picture

That actually works :)
I fixed my module now using a prefixed basename.

While reading the code in drupal_add_css(), I can understand it's not a bug but a feature (:P), making it easier for people to override a complete css file in another module, in stead of manually overriding all css definitions in a different file.

But some documentation of this obscure feature seems to be useful. Since the feature is there for a reason, other people are probably using it in their modules, or would like to use this, or get unintentionally bitten by this. This thing has cost me three years of my life, after all :)

Thanks a lot Tobias for looking into this!