JavaScript and CSS files are currently attached to a page. However, (semantically) they should be attached to the page fragment they belong to. This is required so that cached page fragements retain their CSS/JS when loaded from cache. Example:
- Block adds JavaScript file using
drupal_add_js
- Block content is being cached
- Another page: Block is retrieved from cache and displayed
The Problem: The added JavaScript file is no longer present as it was added to the original page, and not associated with the block
The same problem also applies to CSS files, HTML headers (using drupal_set_html_head
), HTTP headers and so on.
The same problem exists not only for blocks, but for most cachable items which can arbitrary actions (e.g. forms are cached, too).
The cache API already has a partial solution for this: the $headers
parameter. This should be extended to allow arbitrary “meta data” to be associated with a cachable item.
The Vertical Tabs patch needs this in order to show descriptions on submitted forms (e.g. the preview button).
Comment | File | Size | Author |
---|---|---|---|
#4 | block_meta.zip | 3.21 KB | kkaefer |
#3 | js-css-recording.patch | 3.1 KB | kkaefer |
Comments
Comment #1
kkaefer CreditAttribution: kkaefer commentedWhen reproducing, please note that UID 1 never uses the block cache.
Comment #2
kkaefer CreditAttribution: kkaefer commentedI'm currently not sure if it really makes sense to extend the cache tables because both the block and forms implementation have to be modified to cache js/css files and there's little code that can be shared among the two. Also, we can't move the functionality of adding the JavaScript files back to the current page when a cached item is retrieved since that cached item might not be used on that page.
Comment #3
kkaefer CreditAttribution: kkaefer commentedThis patch goes another way: it records function calls and replays them when requested. That way, we can record drupal_add_css/drupal_add_js function calls and replay them when the cached item is used.
Comment #4
kkaefer CreditAttribution: kkaefer commentedThis module provides proof that this works. You should test with a UID > 1 and block cache enabled.
Comment #5
dmitrig01 CreditAttribution: dmitrig01 commentedneeds top be extensible, ATM css and JS are hardcoded
Comment #6
kkaefer CreditAttribution: kkaefer commentedIt is extensible; you can use
drupal_record()->add('drupal_set_html_head', array('<title>Foo</title>'));
.Comment #7
dmitrig01 CreditAttribution: dmitrig01 commentedi mean in blocks and forms you're limited to css and js
Comment #8
dmitrig01 CreditAttribution: dmitrig01 commentedmaybe just 1 array for all stuff that needs to be readded?
Comment #9
kkaefer CreditAttribution: kkaefer commentedAh yeah, makes sense... Do you have a name suggestion?
Comment #10
David StraussSubscribing.