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.
media_gallery_block_view() is currently uncached. It currently takes 12% of request time for a gallery showing four images on a site I'm profiling at the moment.
Here's an untested patch, uses the drupal_render() cache and clears on node update/delete will do some actual testing of it a bit later.
Comment | File | Size | Author |
---|---|---|---|
#23 | 986084.patch | 8.15 KB | catch |
#20 | 986084-cache-20.patch | 8.12 KB | David_Rothstein |
#20 | interdiff-19-20.txt | 1.21 KB | David_Rothstein |
#19 | 986084_cache.patch | 7.95 KB | catch |
#18 | 986084_media_gallery_block_caching.patch | 7.15 KB | catch |
Comments
Comment #1
catchBetter patch. This is working for me although I'm occasionally getting 'no content available', but I get that without the patch too. Should be ready for testing. Attached webgrind screenshots to show the difference - reduces it from 10% to 1% of the request.
Comment #2
catchFigured out my testing issue - applying the patch was changing file permissions. This seems to be working fine.
Comment #3
JacobSingh CreditAttribution: JacobSingh commentedThis looks good, but hard to review since CVS decided to diff the entire thing (not sure why). Can you re-roll so it just diffs the new parts?
Thanks,
J
Comment #4
catchThe reason it did that is the indentation, if it helps there are only a handful of lines changed from the original code in media_gallery_block_build() and they're only at the very top and very bottom.
Comment #5
paul.lovvik CreditAttribution: paul.lovvik commentedThe patch looks good to me, but in testing I noticed that the link to the images shows a lightbox in the original implementation, and goes to the detail page after applying the patch. The behavior is very consistent - roll back the patch, get a lightbox, apply it again, get the detail page.
Comment #6
catchThis is almost certainly down to #859602: #cache does not record the #attached declared in child elements, I'll confirm this and work on a patch for that issue to unblock this one.
Comment #7
catchAdded a patch at #859602: #cache does not record the #attached declared in child elements. I tested this with a local test case, not with media_gallery itself yet. The issue is with hook_node_view() setting #attached - current drupal_render() caching logic can't handle this - so on a cache hit, hook_node_view() doesn't run, and you end up with no css/js from there. If you have time to test again with that patch applied, would be great - if not I'll try to get the boilerplate tests written alongside testing with media_gallery next time I'm working on this.
Marking back to CNR since this bug isn't really specific to the patch here, although this issue might also have to be 'postponed' on the core patch.
Comment #8
paul.lovvik CreditAttribution: paul.lovvik commentedComment #9
effulgentsia CreditAttribution: effulgentsia commentedThanks for the work on this. As per #7, postponing until #859602: #cache does not record the #attached declared in child elements lands in core, but @catch, if you want to add tests and re-roll, go for it!
Comment #10
catchI meant boilerplate tests for the core bug rather than the block itself, although bfroehle ended up adding those. Do you think it'd be worth adding tests here as well? (I haven't looked at media_gallery's test coverage at all)
Comment #11
effulgentsia CreditAttribution: effulgentsia commentedThere is no test coverage at all yet for Media Gallery. It would be great to get some, but no one has had the time yet to work on that. I haven't studied either the core patch or this one in depth enough to offer an opinion on whether this particular patch is one worth adding tests to. In any case, it certainly won't hold up this patch being committed once the core one lands, but if anyone is inspired to write tests for any part of Media Gallery, please do!
Comment #12
JacobSingh CreditAttribution: JacobSingh commentedThis patch seems to have caused some issues.
1 is that the block caches, even if I have block caching turned off.
2 Adds the "Add media" link to every block regardless of display settings and as a side effect, makes people add images to the wrong gallery sometimes if they are on the full view for one gallery and the block of another is on the page.
Comment #13
james.elliott CreditAttribution: james.elliott commentedI've rerolled the patch to address concern #2
Comment #14
catch@Jacob: block caching settings only affects the core block caching mechanism, which this patch doesn't use, this is the same pattern as the forum block in core which also ignores block caching settings and uses the render cache.
Having said that, I think we probably need to invalidate the cache explicitly here on media update and instance changes, most of that logic is in the filter patch so I'll add that today.
Attaching an interdiff of james.elliot's patch, if those links are part of the rendered block, we'll also want to make the cache keys a bit more granular to handle permissions, will look into this as well.
Comment #15
effulgentsia CreditAttribution: effulgentsia commentedThanks catch. If the Media module needs to invoke a new hook somewhere in order to support cache invalidation for modules that render media, like Media Gallery, please feel free to post a patch to the Media queue to do so, link to it from here, and I'll review it.
Comment #16
catchNew hook was a good idea, added a patch to the media queue here #1032186: Add hook_media_rendered_flush().
Uploading a new version of this patch:
- implements the new hook
- additionally implements hook_node_update() to catch changes in there, and uses node_access('update', $node); as one of the cid parts now which ought to make the link appear correctly.
- Since the link is controlled by hook_field_extra_fields(), and there's no hook that runs when those are updated, I used hook_field_update_instance() and checked for the 'media_gallery' bundle as the closest thing, this also catches any other changes to media gallery instances which might affect the node view.
- adds $is_https as one of the cid keys - images are sometimes linked by absolute urls - see http://api.drupal.org/api/drupal/modules--image--image.module/function/i..., so we should ensure there are never mixed content messages. That could be solved more generically by either #1025124: Remove cruft from theme_image_style() and image_style_url() or #1032210: drupal_render_cid_parts() should add http vs. https protocol to cache keys or both.
However I looked through the media gallery code a bit more and there seem to be more issues here:
1. media_gallery_add_images_link_pre_render() is using drupal_add_*() to add assets for the add media link, as does media_include_browser_js() - these would need to change to #attached for this to work properly no?
2. This is the interdiff of james.elliot's patch which I failed to upload earlier:
I'm not at all clear why the node_view() in media_gallery_block_build() wouldn't end up calling _field_extra_fields_pre_render() anyway, so that doesn't look like the right fix, and it's a shame we have to call a private function there. Could you explain how you arrived at that change?
So leaving at needs work for those two questions, but would be great to get reviews of the changes so far.
Comment #17
catchI opened this issue against media module for the #attached issue #1034838: media_include_browser_js() should use #attached instead of drupal_add_*, no patch yet but will try to get that done over the weekend. Once that's resolved the changes to media_gallery_add_images_link_pre_render() should be quite small.
Comment #18
catchRe-rolled this, depends on #1034838: media_include_browser_js() should use #attached instead of drupal_add_*.
By doing $elements['node'] = node_view($node, 'media_gallery_block'); instead $elements += node_view($node, 'media_gallery_block'); I was able to fix the link appearing all the time without having to manually specify _field_extra_fields_pre_render, I think drupal_render() wasn't picking up the pre_render when the node was mixed in the top of the block content array.
Comment #19
catchUpdated patch to go with the new one from #1034838: media_include_browser_js() should use #attached instead of drupal_add_*.
Main change here is I removed the link pre_render - instead adding attached directly to the element. Two reasons for this, drupal_render_collect_attached() apparently does not pick up #attached at the level of an element added by a pre_render - so without the change, the css/js wouldn't appear when the block refreshes.
However the pre_render here isn't necessary because if the link isn't rendered, the #attached doesn't get added to the page anyway, so adding it directly works the same.
I also can't think of a use case to use #attached to an element directly inside a pre_render callback, but if I can figure out a reproducible test case will try to add it to the core issue. Started debugging this but didn't get to the root cause yet.
Confirmed that:
- the block is cached.
- link only shows up when set in field settings
- the link uses the pop-up whether cached or not.
Comment #20
David_Rothstein CreditAttribution: David_Rothstein commentedI reviewed this patch and it looked good to me. It seems to catch all the edge cases I could think of, although as we've seen above this is obviously a pretty scary change :) I haven't actually tested it (and don't have time to right at the moment) so it still needs some testing, but otherwise seems good.
I have also reviewed and commented on the two media issues this depends on:
#1032186: Add hook_media_rendered_flush()
#1034838: media_include_browser_js() should use #attached instead of drupal_add_*
There is one simple problem, though, which is that the patch here was out of date with respect to the name of the hook that was introduced by the media issue linked to above. So, the attached patch changes to use the correct hook name so that it works with the latest patch on that issue. I've attached an interdiff file as well.
Comment #21
catchArghh, good catch David, thanks for reviewing!
Comment #22
David_Rothstein CreditAttribution: David_Rothstein commentedIt turns out this change has a side effect: It messes up the block's contextual links. We have special code in media_gallery_contextual_links_view_alter() which massages the contextual links, but which no longer runs once this patch is applied.
However, the contextual links were already messed up in a different way to begin with. That is described in #870434: Contextual links can be displayed more than once for the same element (Drupal core issue) but it turns out that core patch has problems of its own, so fixing it in the media gallery is the way to go, and moving the node down a level in the block array is part of the solution for that.
So bottom line is that I wrote a separate patch at #1069750: Contextual links appear twice on the media gallery block which moves it down a level in a way that shouldn't break anything. We either need to incorporate those changes here (or commit that first and reroll this).
Comment #23
catchThe other patch looks good to me. This patch didn't apply cleanly any more, so I re-rolled with that change added. Note I didn't test this version yet.
Comment #24
noizo CreditAttribution: noizo commentedHi, i was trying to implement patch #23.
Got some lines rejected.
I think its because .module was patched before.
Thats an rejected code.
Would love to see just the list of manual "to do" changes regarding to original code.
I mean like:
line 200 change to this, and line 400 change to that...
Thanks
Comment #25
lsolesen CreditAttribution: lsolesen commentedCould any of you who worked on this please roll a new patch that applies to the current dev?
Comment #26
lsolesen CreditAttribution: lsolesen commentedComment #27
ivnish CreditAttribution: ivnish commented