Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Looks like the bug relates to the big API changes in drupal_add_css() in D7 beta, and how CSS is now ordered by first by group, then every_page flag, and only then weight.
http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_ad...
Patch forthcoming.
Comment | File | Size | Author |
---|---|---|---|
#1 | wysiwyg-theme_CSS_not_included-974604.patch | 678 bytes | CrookedNumber |
Comments
Comment #1
CrookedNumber CreditAttribution: CrookedNumber commentedComment #2
sunLooks like a valid stopgap fix to me that we can commit. However, we need to revamp the entire asset handling for D7.
Comment #3
jerrac CreditAttribution: jerrac commentedSo I just applied the patch to my dev install of D7 beta 3.
It's definitely pulling in the styles from the theme now.
Though, it pulls in all of them, even the ones I don't want to use... *goes off to search for how to deal with that, since that's how it's probably supposed to work.*
Comment #4
TwoDMarked #975510: drupal_add_css() API change a duplicate of this one. Gábor Hojtsy provided an identical patch just hours after this one was created, probably missed this issue...
@jerrac, the quick tests I made showed it pulled in the same files as before, can you give examples of the unwanted files being included?
@sun, Could you elaborate on this? Shall we commit the fix to this API change and deal with a revamp in another one, so we know we have working code to start with?
Comment #5
sunThanks for reporting, reviewing, and testing! Committed to HEAD.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #6
jerrac CreditAttribution: jerrac commented@TwoD
Yeah, it's pulling the files correctly. It's just that those files contain styles I don't want to use.
It's been a few days, but if I remember right, I just need to define what classes are supposed to show up in the css section of the wysiwyg module interface.
So, I was right, it's working the way it was designed to work. I just need to do some more work to get it customized the way I want.
Comment #7
TwoDAh, that's another issue then.
You can override what files are included using the Define CSS setting under the CSS fieldset. I mentioned how to do that in #990496: wysiwyg_get_css support for module css just recently.
As you probably noticed, the bigger editors like TinyMCE, FCKeditor and CKEditor auto-extract the style rules from the included stylesheets and add them to their "Styles" dropdowns. Those settings can be overridden too - regardless of which stylesheets are used - but exactly how depends on the editor. Unless the settings require Function references or Regular Expressions, you can do that via an implementation of hook_wysiwyg_editor_settings_alter(). If they do require those references, there's still a way but let's take that in a separate support issue.