Overriding module CSS files does not work with unlimited_css [#693180]

Have a look at these long issues:
#163785: Themes can't override core & module stylesheets
#189568: Overriding module CSS with theme CSS

and this manual page:
http://drupal.org/node/263967
("Overriding style sheets from modules and base themes")

Essence:
To disable a core or module CSS file (such as system-menus.css) through your theme, you just need to add the filename in your .info file. This will either replace the file (if a file with this name exists in your theme), or disable it (if the theme does not have such a file).

It seems that this overriding trick does not work with unlimited_css.

If you work on this, please also consider the following cases:
- CSS aggregation can be on or off.
- The file in the theme can exist or not.
- The CSS file you want to override can be in any module folder or subfolder (/css).
- Theoretically, two modules can have CSS files with the same name. Drupal core does not support this situation.

So, I think what we need to aim for is not to replicate D6 core behavior. If D6 core gets it wrong, this module should do the same.

Thanks!

Comment	File	Size	Author
#2	unlimited_css.module.txt	5.19 KB	donquixote

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

donquixote CreditAttribution: donquixote commented 23 January 2010 at 06:52

Oops.. I notice that the manual page is not relevant here, as it describes a different method used for D5. No themename.info files involved.

I know there is a more relevant manual page somewhere, but I cannot find it atm.

Maybe this Lullabot article helps:
http://www.lullabot.com/blog/fixing-menu-css-themers-6

Comment #2

donquixote CreditAttribution: donquixote commented 13 February 2010 at 23:54

File	Size
unlimited_css.module.txt	5.19 KB

I have a new version of the module.
The attached file replaces the original file (I think this is easier than a patch).

A lot is copied/adapted from drupal_get_css().

What it attempts to do:
- Include exactly those CSS files that would be included without this module. Not more, not less.
- Keep CSS files in the same order as it would be without this module.
- Use the @import method if the total number of css files is greater than 21. (this way, we leave a bit of space for explicit inclusions in the page.tpl.php, that we don't know about).

Comment #3

donquixote CreditAttribution: donquixote commented 13 February 2010 at 23:56

Priority:	Normal	» Critical
Status:	Active	» Needs review

There is a solution, so I set this to "needs review".
I set it to "critical", because the original module does not do what it's supposed to do, and can break a site layout.

Comment #4

bcobin CreditAttribution: bcobin commented 14 February 2010 at 13:41

Gosh, donquixote - thanks for the work, but it doesn't work in my case, at least not on IE6. CSS still needs to be compressed for the site to work.

I have a lot of customizations to my template.php which are not part of the base distro, so this might be specific to my installation.

Thanks for staying on top of this very important issue - I will keep checking in!

Comment #5

donquixote CreditAttribution: donquixote commented 14 February 2010 at 23:09

Interesting.
Can you tell me a bit more about your [themename]_preprocess_page(), and the resulting html source with my version of the module enabled and CSS aggregation off?

Comment #6

ademarco CreditAttribution: ademarco commented 15 February 2010 at 10:44

Status:

Needs review

» Active

Thanks for the patch donquixote, it is committed to HEAD: http://drupal.org/cvs?commit=328892. I'll wait for an answer from #4 before to close the issue.

Comment #7

donquixote CreditAttribution: donquixote commented 15 February 2010 at 20:44

#4 sent me a PM with his HTML sourcecode.
He has > 31 CSS files all with <link type="text/css">.
My quick guess is that other implementations of hook_preprocess_page override what unlimited_css does. I am waiting for more information from #4.

Comment #8

donquixote CreditAttribution: donquixote commented 12 March 2010 at 21:17

I did not get any further infos from #4.
I think you should publish a snapshot release for the 1.x branch, so others get a chance to download and test the patched version!
If the problem from #4 is what I imagine, then there is no way that unlimited_css can fix that, with or without patch.