Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
base system
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Apr 2009 at 03:45 UTC
Updated:
4 Apr 2010 at 21:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
sunFor now, this is by (Drupal core) design. It's a mess, but I can't help, sorry.
Comment #2
sunNo. I don't want this to vanish. This is a critical Drupal core _bug_. D7 can't be released without fixing it.
I hate magic.
Comment #3
sunThis issue gets even more important when considering support for external CSS...
Comment #4
avolve commentedThanks for the quick follow up and outlining the theme function — much appreciated!
Comment #5
caktux commentedsetting back as Wysiwyg API issue, I'm pretty sure this isn't a D7 Core issue if wysiwyg_markitup_settings() has style.css hardcoded in it.
Comment #6
sunDon't do that again.
Comment #7
dvessel commentedI'm not sure this is documented but every single styles sheet must have unique names. This goes beyond style.css. If any theme defined style collides with a module, it'll go missing as it was designed to do.
It can be improved but I haven't seen this encountered very often. If there's a patch I'd be happy to review. Otherwise, your editor will never get fixed.
Comment #8
sunYes, the design is wrong. The CSS filename in question is not under our own control. Users are asked to download that editor, extract it, and be happy. Drupal makes them unhappy.
This is critical.
Comment #9
avolve commentedDigging through CSS i found that the width of the editor window is governed for nodes by
in node.css
For comments, I added a
to the custom-theme.css. Whilst a workaround, it resolves this issue.
[the 90% as opposed to 95% was required by the custom theme. Width can also be set as px, em, etc]
Comment #10
casey commented@sun what exactly is going wrong here?
Comment #11
sunBetter title.
What's going wrong?
1) Put the "library A" into your Drupal installation, which ships with a "style.css".
2) Presuming that you have Garland or any other theme enabled that's using "style.css",
3) Try to load library A's stylesheet.
4) Alright, you managed to do 3) using some weird hacks, but now allow the theme to override the styles defined in library A's style.css.
Comment #12
casey commentedInitial patch. Allows to do the following.
Comment #13
sunThat's quite a ugly hack, but it could work.
Comment #14
casey commentedoww I kinda liked it :p
Comment #15
sun.core commentedCan we resolve this and get this done?
Powered by Dreditor.
Comment #16
sun.core commented#12: cssbasename.patch queued for re-testing.
Comment #17
sun.core commentedComment #19
casey commentedReroll
Comment #20
sunThanks, slightly reworded the comments, RTBC.
@casey: Please make sure you roll your patches with diff -up
Comment #21
sunUpon reading it once more, clarified some more. ;)
Comment #22
sociotech commentedIn the process of porting Fusion to D7 I ran across this problem, since sub-themes can have css files with the same name as the base theme, but they are meant to _add/override_ their css to the base theme's css, rather than _replace_ it.
So, I applied this patch and tested it out. Works great when using the theme name as a prefix in the basename option.
Thumbs up and thanks very much for this handy bug fix.
Comment #23
dries commentedCommitted to CVS HEAD. Thanks.