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.
Problem/Motivation
When adding multiple handlers to a view area (i.e. "Header") you are able to change the order of the handlers. Unfortunately Views doesn't respect this order but prints the items based on the weight each handler sets while rending (i.e. the weight of a block).
Proposed resolution
Update the weight of each area based on its position.
Patch follows.
Comment | File | Size | Author |
---|---|---|---|
#15 | views_does_not_respect-2680227-15.patch | 4.39 KB | k4v |
#10 | views_does_not_respect-2680227-10.patch | 4.39 KB | k4v |
#7 | views_does_not_respect-2680227-7.patch | 4.37 KB | k4v |
#2 | views-order_area_handlers-2680227-2.patch | 756 bytes | stBorchert |
Comments
Comment #2
stBorchertUpdate weight after area rendering. Unfortunately I couldn't find a way to do this directly on render, since each handler does different things.
Comment #3
dawehnerThis patch looks perfect, but given it fixes a bug, we should have a test.
Comment #4
dawehnerComment #6
k4v CreditAttribution: k4v as a volunteer commentedComment #7
k4v CreditAttribution: k4v as a volunteer commentedAdding tests.
Comment #8
k4v CreditAttribution: k4v as a volunteer commentedComment #9
dawehnerThe setup of the test in general looks pretty good. Here are some comments, but after that this is totally perfect.
In order to test that properly we should add
position:
for the two cases.We can remove/drop that bit now.
You should be able to achieve the same by just using
$output = $this->render($view->buildRenderable())
Just a quick comment: You could have used
assertNotEquals($position_powered, 0) and assertGreaterThan
. This makes it a bit easier to read at the end.Comment #10
k4v CreditAttribution: k4v as a volunteer commentedUpdated. I prefer the test with <. "assertGreaterThan" requires to swap the order which confuses me...
Comment #11
stBorchertk4v++
I owe you a beer (or something similar) for writing the test ;)
Comment #12
dawehner@k4v
Okay sure, no worries
Comment #13
alexpott#9.1 hasn't been addressed - is position saved to the view - I think it is. Also I think entity_block_2 should be positioned before entity_block_1 as that is more of a test. Note that changing the position should not affect the order of the blocks in the view.
Comment #14
dawehner@k4v explained me that in person. The position is not setable via configuration, but rather just the order in the files is taken into account there. Given that the testcase itself makes totally sense IMHO, but yeah I agree using the keys in a different order would be nice, just to ensure that we don't sort by keys.
Comment #15
k4v CreditAttribution: k4v as a volunteer commentedI changed the labels in the yml. As dawehner mentioned, I cannot set 'position' in the yml. The order of the blocks is taken from the position in the yml.
Comment #16
k4v CreditAttribution: k4v as a volunteer commentedComment #17
k4v CreditAttribution: k4v as a volunteer commentedComment #18
alexpottCommitted f21cdec and pushed to 8.1.x and 8.2.x. Thanks!
Can we get a followup to add a position key instead of reordering whole sections - doing that making looking configuration changesets much easier. atm the diff is unreadable.
Fix all of this on commit.