Attaching scripts to blocks using the current implementation will fail if block cache is turned on since the hook_block_view_alter will never be called.
This patch checks the cache setting of the block, and if cacheable adds a small script loader to the block's markup so it'll always be in the cached version. Because it's loaded via an HTTP request, it should have a similar effect to putting it in the footer as it won't block the page as inline js would.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1404206-5.inline-cached-blocks.patch | 2.48 KB | ksenzee |
| #4 | 1404206-4.inline-cached-blocks.patch | 2.48 KB | ksenzee |
| #3 | js-libs-inline-cached-blocks-3.patch | 2.09 KB | msonnabaum |
| js-libs-inline-cached-blocks.patch | 1.83 KB | msonnabaum |
Comments
Comment #1
pwolanin commentedI don't think that's the right approach - what if JS aggregation is enabled?
Comment #2
msonnabaum commentedWell, clearly it won't be aggregated. That seems like a reasonable trade off unless I'm missing some other consequence of this.
Comment #3
msonnabaum commentedHere's a new version that makes sure block cache is enabled before doing anything, and it also checks Drupal.settings before adding a script to make sure it hasn't been added in another block already.
Comment #4
ksenzeeTalked to pwolanin and msonnabaum about this, and we agreed it's more consistent to use the script loader for all block JS, regardless of whether the block is currently cached or not, to avoid changing the order of script loading when block caching gets turned on. Here's a new version that
- always uses the script loader for block JS
- resolves stream wrappers, so jQuery isn't trying to GET public://some.js
- makes some fixes to the script loader JS
Comment #5
ksenzeeOops. Stray single quote at the end of the script block, fixed in the attached patch.
Comment #6
pwolanin commentedDo we even need this patch, if this patch goes in to core: https://drupal.org/node/1460766 ?
Comment #7
pwolanin commentedcommitted