Coming from #2048309: Views UI Preview - navigation is broken, see comment #1 point 3 .
If a contextual filter is specified in the preview textbox, this input gets lost when navigating to a different page on the preview.
Steps to reproduce:
- Devel create 50 nodes of type 'article' and 'basic page'
- Clone the 'frontpage' view
- Change display format to e.g. table, selecting 'title' and 'type' fields as columns in the table
- Add a contextual filter to the cloned view, for the 'type' field
- Type 'page' in the textbox for the contextual filter preview
- Click 'Update preview'
- You get a table of only 'basic page' nodes
- Click any page link in the pager
Expected result:
A second page of 'basic page' nodes
Actual result:
A mix of 'basic page' and 'article' nodes, and the contextual filter textbox is void.
Per #31:
Looks like we may not need to push/pop the request in ViewUI::renderPreview anymore. I think that was relevant when that method was calling drupal_render() so that the pager could use a different 'current' request to build its links. But now, since #2412805: View preview does not attach assets provided by plugins, ViewUI::renderPreview returns a render array, so if we push a request and then pop it within the same method this ends up as a no-op, since the rendering occurs at a later stage.
We can clean up some old stale code to get the expected result.
| Comment | File | Size | Author |
|---|---|---|---|
| #81 | 2066207-81.patch | 15.66 KB | adityasingh |
| #81 | interdiff_79-81.txt | 5 KB | adityasingh |
| #79 | 2066207-79.patch | 15.72 KB | megha_kundar |
| #67 | interdiff-64-67.txt | 2.46 KB | Anonymous (not verified) |
| #67 | 2066207-67.patch | 15.9 KB | Anonymous (not verified) |
Comments
Comment #1
mondraketagging
Comment #2
dawehnerWhat happened when you have done the same in Drupal 7?
Comment #2.0
dawehneradded steps to reproduce
Comment #3
mondrakeJust checked in D7, repeating steps 1-8 as per the summary, the result is the 'expected' one.
Comment #4
dawehnerSO this is clearly a bug.
Comment #4.0
dawehnerformatting
Comment #5
mondrakeComment #6
effulgentsia commentedRaising to major, since #2237001: Remove no longer needed _current_path() fallback for early bootstrap is postponed on this.
Comment #7
mondrakeThis is replicating the approach in #2237001-17: Remove no longer needed _current_path() fallback for early bootstrap, i.e. move the contextual filters from the path to a query parameter (only in the context of a view preview, of course). In this case it looks like we would not have to bother manipulating the _current_path at all.
Just throwing as an idea. I'm sure there are better ways...
Comment #9
mgiffordComment #11
rpayanmtrying...
Comment #13
mondrakeRerolled, and added a test + test only patch.
Comment #15
effulgentsia commented#2237001: Remove no longer needed _current_path() fallback for early bootstrap is postponed on this, so adding the "blocker" tag.
Comment #16
dawehnerNote: #2362227: Replace all instances of current_path() is also removing the call to
current_path()Comment #17
mondrake#2362227: Replace all instances of current_path() removed both current_path() and _current_path(), so this is no longer a blocker. However, t seems that this issue is still valid. Patch in #13 needs a reroll for sure, but maybe a different approach too, now a request object is pushed on the stack and working on that maybe a better option than the query parameter.
Comment #22
mondrakeReroll of patch in #13.
This is still using a query parameter to store the contextual filter for the pager link, i.e. sth like
http://{base_url}/admin/structure/views/view/{view}/preview/{display}?page=1&_preview_args=filter1/filter2in D7 the contextual filter is appended at the end of the URL, like
http://{base_url}/admin/structure/views/view/{view}/preview/{display}/filter1/filter2?page=1Comment #23
manningpete commentedI could apply the patch, so no reroll is needed.
Comment #24
dawehnerThank you for working on this issue!! I'm curious whether you have checked how it works in Drupal 7. I remember that it used to work,
maybe it used to be an easier solution ... but in general it seems pretty sane what the patch does.
Just in case, I'd prefer to name it test_argument_paging, because this is still the internal technical term for it.
Comment #25
mondrakedone.
As to why it worked in D7 and no longer in D8, I do not fully understand but I have just a feeling it is related to the changes in the routing system. The '$args' would be picked from the URL in D7 when paging through pager links, but AFAICS in D8 args appended to the URL won't because there's no matching route. So the patch here moves the $args to the URL query parameters which is not influencing the routing and can be treated separately.
Comment #27
mondrakeTrying to fix the failures related to the test view.
Comment #29
mondrakeLet's see this one.
Comment #30
mondrakeComment #31
mondrakeLooks like we may not need to push/pop the request in
ViewUI::renderPreviewanymore. I think that was relevant when that method was callingdrupal_render()so that the pager could use a different 'current' request to build its links. But now, since #2412805: View preview does not attach assets provided by plugins,ViewUI::renderPreviewreturns a render array, so if we push a request and then pop it within the same method this ends up as a no-op, since the rendering occurs at a later stage.Let's see what bot thinks of this.
Comment #34
baisongTriage notes:
Comment #35
xjm(Saving proposed issue credit for discussion and triage participants at LA.)
Comment #38
mondrakePlain reroll.
Comment #39
lendudeDidn't apply anymore, did a reroll.
Comment #42
lendudeReroll.
Comment #45
vprocessor commentedComment #48
tim.plunkett@xjm @alexpott @cilefen @dawehner and I agreed that this is not a major bug because it only affects the Views Preview UI, and only under certain circumstances (contextual filters and pager navigation).
Comment #51
Anonymous (not verified) commented#42 works perfect!
#43, #44 looks like random fails.
Nit reroll. RTBC++
Comment #53
Anonymous (not verified) commentedCS fixed.
Comment #54
borisson_I don't think we need the
taround these buttons as this view is not translated.This is the only nitpick I could find, otherwise this patch looks very good.
Comment #55
mondrakeFixes for #54 and array CS.
Comment #56
Anonymous (not verified) commented#54 was addressed in #55 + array style improved! Thanks, RTBC.
Unfortunately, part of the API required for the test is in the WTB area, so the test also is WTB. But this new test is definitely not prevent the
PreviewTestconverting to JTB.Comment #58
Anonymous (not verified) commentedComment #60
lendudeAlmost ready I think
per codesniffer: missing a trailing comma
Why are we changing this and not just adding a row count to the call? It wouldn't hurt to test that the pager works, right?
Comment #61
mondrakeThanks @Lendude, addressed #60.
Comment #63
mondrake#61 fails because the test assumes the view's style is 'default' and not 'table'. Changed the test view.
Comment #64
Anonymous (not verified) commented#63: Nice catch!
Also I tried to import the view, and noticed that a couple of other fields also need to be updated. So, perhaps it makes sense to add more asserts and expand the test for both content types. Done.
Comment #65
Anonymous (not verified) commented#64: Found an out-of-date assert message (static word: "Page"):
$this->assertEqual(count($elements), 5, 'Expected items of "Page" type.');It should be
$this->assertEqual(count($elements), 5, "Expected items of '$type' type.");It will be fixed if the #64 receives your approval.
Comment #66
lendudeNice, more coverage!
special? 'specific' I'd say.
Check that there are two pages after setting the contextual filter.
debug?
Check that all results are of the expected type.
Yeah use $type here. Also if we have 10 results, 5 page five article and the sorting is by type, this would still be true. So we'd need to test this on the first page of the result too if we want to be sure the filter worked.
Comment #67
Anonymous (not verified) commented@Lendude, thank you! Done.
Comment #68
lendude@vaplas, thanks, look good to me now. Updated the IS a bit to include the findings in #31 that seem relevant to the removal of a big section of code here.
Comment #69
lendudeComment #71
mondrakeComment #72
catchShouldn't this have an assertFalse() for go to page 4 as well?
Comment #78
mondrakeComment #79
megha_kundar commentedComment #81
adityasingh commentedFixed deprecation code and coding standard.
Comment #88
griffynh commentedHola, this came up in the #bugsmash channel as the Views daily triage target.
As we haven't had an update in over four years, if there's no update in the next three months, this issue may be closed.
Comment #89
maxilein commentedBut it is such an annoyance that this functionality is missing ... for everyone who develops using views ...
Comment #90
johnvComment #91
joelpittetThe tests look great, needs a re-roll of course but better to move this to a MR.