As I discovered in comment #58 in #2005970: In renderable arrays, #type should provide a #theme suggestion, similar to how drupal_prepare_form() works, drupal_get_css() will try to process an empty $css array when it could just return an empty string straight after the alter that allows modules to modify the array if it is still empty.
$css is generally only empty during ajax requests it seems.
Not returning early means it would be impossible for somebody to implement #theme 'styles' without causing exceptions on ajax requests, as the drupal_render() in drupal_get_css() would cause the theme system to initialise inappropriately.
Doing a quick empty() check would also be a slight performance boost for ajax pages.
This is probably minor in itself, but it's kind of blocking #2005970: In renderable arrays, #type should provide a #theme suggestion, similar to how drupal_prepare_form() works.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | 2032967.patch | 1.09 KB | catch |
| #24 | 2032967.patch | 689 bytes | catch |
| #5 | drupal_get_css_should-2032967-5.patch | 745 bytes | joelpittet |
| #3 | drupal_get_css_should-2032967-3.patch | 541 bytes | alansaviolobo |
| #1 | 2032967-1.patch | 509 bytes | thedavidmeister |
Comments
Comment #1
thedavidmeister commentedpatch.
Comment #2
webchickSomething has gone horribly wrong if drupal_add_css() is being called on AJAX requests. I wonder if this is actually masking a deeper bug.
Comment #3
alansaviolobo commentedrerolling
Comment #4
jhedstromindeed. CNW.
Comment #5
joelpittetBumping this to 8.1 shortly, It really needs to be sorted out why it's even getting that far with empty arrays.
Here's a hack to see if we can unearth some truths about this...
Comment #6
joelpittetLet's see what happens but bumping to 8.1.x regardless
Comment #8
joelpittetYup it's looks like all AJAX from first glance.
Comment #24
catchRedo of #5 to see if this still happens.
I wonder if this is purely happening when there's only a library or two to load, and the library only contains JavaScript - we don't know whether we need CSS or not until the library definitions have been parsed.
If that's the case, we can skip the sort and optimize, and cache the empty array, but it's absolutely fine and expected for that to happen on AJAX requests.
Comment #25
catchAnd here's what the fix should look like. Not really a bug IMO but saves a bit of work.
Comment #26
lendude#24 shows we have all sorts of test coverage hitting this, so no need to add more, change makes sense.
Updated the title to match the fix, we are not returning early because we want the cache to be set.
Comment #27
quietone commentedChecking RTBC issues. There are no unanswered questions here or other work to do. I did not review the change itself.
Comment #28
alexpottCommitted and pushed dc39dd56b6c to 11.x and e8961de11a5 to 10.1.x. Thanks!
Comment #31
aaronbaumanFor future googlers: the symptom that led me to this thread was "Exception: Invalid CSS asset type" error in dblogs.
This was is in the context of submitting a views exposed filter via ajax (including Better Exposed Filters, which I had originally suspected as the culprit).
patch in #25 fixed it.I take it back. Not fixed. The AssetResolver still chokes on a null-set of CSS assets.Anyone know offhand if there's another issue open for this already?Turns out I had a bad hook_css_alter that was adding an invalid CSS asset, which led to the asset resolver choking. No patches necessary after all.
Comment #33
joelpittetI'm quite sure we should have committed my exception from #5, lol
For the uninitiated https://www.youtube.com/watch?v=-Y-yKmzP-4U