Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I installed GMap on a site using a Fusion theme and GMap complained that it was being asked to create duplicate maps. It seems the Fusion call to block_list in fusion_core_grid_info() in template.php was causing all active blocks to be rerendered if not cached. Not sure if this is as intended but seems a waste of processing just to get a block count.
Comment | File | Size | Author |
---|---|---|---|
#26 | fusion-blocks-render-twice-1172280-26.patch | 961 bytes | Poieo |
Comments
Comment #1
rickmanelius CreditAttribution: rickmanelius commentedSubscribing
Comment #2
paskainos CreditAttribution: paskainos commented+1
Comment #3
coltraneSo it's just the fact that blocks get rendered twice (and GMap doesn't like that) due to the calls to block_list() for every visible region?
Comment #4
aquariumtap CreditAttribution: aquariumtap commentedI haven't been able to recreate this bug. Here's what I did:
The map is displaying the correct location and I'm not receiving any errors. I also tried loading the block via admin/structure/block instead of via a Context module reaction, but still no error.
Are you still running into this issue? If so, could you provide more details on how you are creating the map block, and how you are displaying that block (via Context, via admin/structure/block, etc)
Comment #5
esmerel CreditAttribution: esmerel commentedComment #6
girishmuraly CreditAttribution: girishmuraly commentedI am experiencing the same issue. Its not related to GMap though.
I am using Contexts and Fusion_core on my site.
Every block was getting rendered twice and using debug_backtrace() I found that was due to the following call routes (snipped)
1. drupal_render_page -> context_page_build
2. drupal_render_page -> drupal_render -> theme('page') -> fusion_core_preprocess_page -> fusion_core_grid_info -> fusion_core_block_list -> block_list
No 1. seems sensible.
However, 2. seems too much to do. block_list() seems to be used to just see if blocks exist for a region and if so, set a width.
E.g. from fusion_core_grid_info()
The fact that it renders blocks too seems to have been overlooked. This seems to be a major performance drain.
Comment #7
sheena_d CreditAttribution: sheena_d commentedNo further development will be pursued in the 7.x-1.x branch of Fusion, so moving this to the 2.x branch.
Comment #8
aquariumtap CreditAttribution: aquariumtap commentedYes, Fusion checks to see if there will be any blocks populating a given sidebar. If not, the sidebar will not displayed, and the adjacent regions will be allocated their grid units.
Blocks need to be rendered at some point or another. There's no double render. Both the block module's
block_list()
and the context module'scontext_reaction_block::block_list()
have static caching.If a block seems to be rendered twice, it would have to be because both the block module and context module are rendering the same block. Do you have the block module enabled? Are you using it to place blocks into regions?
I haven't been able to reproduce this bug.
Comment #9
girishmuraly CreditAttribution: girishmuraly commented@aquariumtap, thanks for the info. Here's my setup:
* block module is enabled, however it is not being used to place block into regions. It is enabled because a few modules (like AddThis) needs it as a dependency
* context module is enabled and used to place blocks into regions
The blocks are getting rendered twice.
Here is the simplified backtrace with function-name (and args as needed) in reverse order of invocation, when the block is rendered by context on the page. Note that it goes through
context_page_build
.And here is the same block being rendered on the same page again, this time by fusion:
Comment #10
aquariumtap CreditAttribution: aquariumtap commented@girishmuraly - thanks for the backtrace info. Just to confirm, you're seeing the same block twice in your browser? Or is the concern that it's being processed twice?
Comment #11
girishmuraly CreditAttribution: girishmuraly commented@aquariumtap, I should've been more clear. The block itself appears only once, so to the end user its all good. However, yes the concern is that the block is being processed twice.
Comment #12
esmerel CreditAttribution: esmerel commentedComment #13
adf1969 CreditAttribution: adf1969 commentedA few comments regarding this bug (it still exists for me, fusion_core 7.x-2.0-beta1.52-dev, and from looking at the 7.x-2.0 HEAD, it seems the code in fusion_core:template.php is the same as I have, so this problem has not been fixed).
Aquariumtap: While it is *true* that block_list() is statically cached, it is *also* true that at the end of building all the blocks, that "cache" is reset:
in: block.module: block_page_build()
This is what causes the blocks to re-build/re-rendered all over again (every time, on every page-load).
This of course is a major performance issue, not to mention can create all sorts of other "issues" since it runs the code for each block TWICE on each page-load (the GMap issue above is just one example, and any CDN that you use in a block will also get used twice).
I'm looking at some options to fix this bug. If I figure out a way, I'll post my results here.
Comment #14
chirhotec CreditAttribution: chirhotec commentedThis is also breaking a multistep registration form I've created. The form works fine as a page within a fusion theme, or as a block with a different theme. Unfortunately, I need it to be a block, and I've already come along way in my custom fusion based theme.
Comment #15
webkenny CreditAttribution: webkenny commentedCan someone point me to where we believe this is happening in Fusion? We can have a look.
Comment #16
webkenny CreditAttribution: webkenny commentedKris Bulman reports in #1905600: call to fusion_block_list in grid_info causes block alters to load twice which I've marked duplicate:
We agree this is an issue. Any suggestions on how we should address it knowing that we need to know about the content/block list? Open to ideas.
Comment #17
KrisBulman CreditAttribution: KrisBulman commentedDoes Fusion need to receive an array of blocks visible in a region, or just know the exact number of blocks in the region, or does it really only need to know if the region is empty or not?
Comment #18
webkenny CreditAttribution: webkenny commentedMy feeling is, being a newer maintainer, that we only need to know if the region is empty or not so we can render it. I can't see any reason why we have to know what those blocks are. I do see that Fusion Accelerator may need some knowledge of it (given its skinning mechanism) but that's separate and the theme shouldn't depend on the module, IMO. We'll have a look into fusion_core and see what we can find for dependencies. Let us know if you find anything first.
Comment #19
aquariumtap CreditAttribution: aquariumtap commentedHi webkenny - you're right, Fusion doesn't need to know what the block is, just if the region needs to be printed or not. Skinning is entirely the responsibility of Skinr or Accelerator, and the only special accommodation Fusion makes is to print the classes in the right place.
I agree with you that Fusion shouldn't depend on Accelerator, and I think that separation is there or *almost* there. The intention was for accelerator to depend on Fusion, but not the other way around. Without accelerator, the responsive features of Fusion would not be accessible, but the (non-responsive) theme should work.
Comment #20
webkenny CreditAttribution: webkenny commentedFantastic then. We know what needs to be done. I will try to work a patch this week. Thanks for the clarification, aquariamtap. Good to get your feedback on these issues as we work through them.
Comment #21
KrisBulman CreditAttribution: KrisBulman commentedThen really, if the sidebars are empty the only value that needs to be passed is 1 or 0. You should be able to reliably determine if sidebars are rendered from preprocess_page .. doing a check there, then passing the resulting value to the grid function (with a helper function) should do what you're looking for.
Comment #22
Gabriel CreditAttribution: Gabriel commentedIs there a work around for this? Or a way I can tell it's the first call to the block and not the second? I'm rendering out advertising in views on the page via a hook_block_view() and they are being rendered twice as I'm using drupal_add_js() to insert the ad call. I notice any returned values during the first call are thrown away, but the drupal_add_js call can't be disposed of in the same way.
Any suggestions would be greatly appreciated.
Comment #23
gcassie CreditAttribution: gcassie commentedSee #2179559: context_page_build() clears caches too aggressively for a potential fix to Context.
Comment #24
BetoAveiga@Gabriel I "fixed" this but I'm not using context. Maybe this link could help you to find a solution https://drupal.org/node/2178485
Comment #25
dreamingX CreditAttribution: dreamingX commentedThis worked for me (thanx to BetoAveiga):
Changing the lines in template.php:
to:
Comment #26
Poieo CreditAttribution: Poieo commentedAttached is a patch based on #25. Please test this to see if it resolves the issue without creating more.
Comment #28
Poieo CreditAttribution: Poieo commentedComment #29
Poieo CreditAttribution: Poieo commentedThis has been rolled back due to another issue it caused: #2340749: Main content doesn't adjust properly with empty sidebars
Still looking for a fix that doesn't break other functionality.