| Project: | Context |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
This issue attempted to fix the issue of context blocks not being sorted:
#1038580: Blocks not sorted by weight before building region
However the fix committed there doesn't take into account that blocks may be added to a region by something else as well (i.e. Block module). And so while context's block will get sorted, they won't be in the proper order with the other blocks.
Most people don't try to use Block module and Context module to display blocks, but will have Block module enabled so that blocks can be edited. So this bug really only manifests itself if you are trying to use Context module to place a block above the system-main block (the primary page content). In this case Block module places system-main first, and Context module places its blocks second (at the bottom of the page) regardless of block weight.
The fix is simple. Patch forthcoming.
Comments
#1
#2
So the uasort is still needed to get blocks from different contexts to sort correctly, so I removed that part of the patch.
#3
Updating this patch for the latest context dev release (7.x-3.x-dev (2011-Jun-20)).
#4
I was trying to place a block in a context in the same region as the system main block. It was supposed to be above it, but no matter which weight, it would always drop to the bottom of it. (using beta1)
The patch solved the issue for me.
#5
Not sure why, but after applying this patch, my home page got a two-sidebar class instead of a no-sidebars, breaking all content.
It seems that empty regions are being processed as non-empty and causing this.
#6
Here is a workaround for this issue:
1) Open your current Structure->Blocks page in a browser window. Open a second window for the steps below
2) In your second window, create a new context, call it "Global sitewide blocks".
3) Under conditions, choose "Sitewide Context" and then check "Always Active"
4) Under Reactions, choose "Blocks"
5) Get both windows side by side and add each block that was in the global block system to the Blocks reaction. If you press "show row weights" on both sides, you can set the weights to be the same as well.
6) Save your context in Window #2.
7) In window #1, set all the blocks that are active (which are now also added from your sitewide context) to be hidden.
8) Now your global blocks list should be empty, and all those blocks are added instead from context module by your sitewide context. That means the weights will properly sort, so that blocks added with a lower weight WILL appear above the main system content.
#7
That works - just didn't realize there was a sitewide context. That's cool! Appreciate it!
#8
@franz: May be the problem is just on your setup. Here i have the one-sidebar working just fine.
I think this should be an official patch.
This works for me just fine, mixing "contextual" blocks and "core" blocks. I can move the "contexual" blocks BEFORE or AFTER the "core" blocks at my desire.
#9
Sorry, i have to retract now. It seems i cannot move as it appeared at first.
I will look for a better patch to solve this and post here.
Best regards!
#10
Hi!
Here is my patch to achieve what i need. I hope it serves for the other use cases, and also somebody can point me some ugly code to refactor it?
Best regards!
#11
Dont know why. Eclipse builds a very wrong patch on #10. Here is repost the correct one.
#12
Raising to critical: somebody, please look at this?
#13
Javier note that this issue isn't critical (some blocks show in the wrong order only in some configurations).
I reworked your patch in such a way that should be more performant and easier to understand.
#14
This should probably be committed to HEAD. It solves a great deal of trouble trying to sort out weights, especially when system: content is involved. I used #13 and it worked like a champ.
#15
I was experiencing this problem, where the block ordering defined in the Context admin UI was not honored by block-system-main. I fixed this with a one-liner:
Index: sites/all/modules/contrib/context/plugins/context_reaction_block.inc===================================================================
--- sites/all/modules/contrib/context/plugins/context_reaction_block.inc (revision 997)
+++ sites/all/modules/contrib/context/plugins/context_reaction_block.inc (working copy)
@@ -220,7 +220,7 @@
foreach (array_keys($all_regions) as $region) {
if ($this->is_enabled_region($region)) {
if ($blocks = $this->block_get_blocks_by_region($region)) {
- $page[$region] = isset($page[$region]) ? array_merge($page[$region], $blocks) : $blocks;
+ $page[$region] = isset($page[$region]) ? array_merge($blocks, $page[$region]) : $blocks;
}
}
}
I simply merge the previous blocks into the Context-ordered ones, rather than the other way around. This ensures that Context's ordering takes precedence. Is this not sufficient for the general case?
Above patch is attached to this post as well.
#16
@jdolan, unfortunately no. See the notes in
http://drupal.org/files/1169264-context_block_weight-13.patch
that talk about restoring the weights that Block module manufactured. Also take a look at _block_get_renderable_array() to see how the weights returned by block module are "made up".
#17
Patch #13 worked for me.
#18
We applied and tested the patch in #13 and it worked for us too. Thank you!
#19
yes, #13 works, the system-main block is paced correctly between context blocks
#20
#13 worked for me as well
#21
by the way, I was grappling with this problem for a long time before I realised that stripping all block content that I could out of the main theme/block regions and then exclusively applying them via Context enabled me to place all block content exactly where I wanted it. I.E. if all the blocks are placed via Context arguments I can weight and/or apply them in whatever order I want. Sorry if that's too obvious for you egg-heads out there but it works great for simple designers like moi.
#22
Patch #13 worked for me as well, please commit.
#23
is this committed ?
#24
Patch #13 worked for me as well, please commit.
#25
Patch #13 worked for me too - thank you dalin :)
#26
+1 too. This with a proper fix on #1468864: Save correct weight for all blocks in all contexts of region when saving.
#27
+1 from me as well for #13.
I had worked around this by moving all my blocks to a sitewide context, but that doesn't solve the problem for views pages!
After applying #13, my block set in a context with a <0 weight appears above my view page output like it should.
Thanks for the fix, dalin!
#28
Committed http://drupalcode.org/project/context.git/commit/2b41e1d0451712e7d3725f8... thanks for the bug report and for the patch.
#29
#30
Automatically closed -- issue fixed for 2 weeks with no activity.