Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
views.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
1 May 2014 at 10:28 UTC
Updated:
29 Jul 2014 at 23:35 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
damiankloip commentedRough initial patch.
Comment #2
jrbeemanThis appears to be working well so far, with the exception of a minor form issue found below.
To test, I used a D8 install profile I've been maintaining that sets up a content structure with various relatioships. Then, I created content with relationships and attempted to filter based on those parameters. You can see the exported view in the profile repository.
There was an issue with the contextual filter having a required form field, causing other filter options to fail even when this filter option wasn't selected. To address this, I removed the required attribute, but there may be a better solution to that particular issue (see attached patch).
I ran into an issue with regard to multiple argument filtering behavior, but based on the QueryParameter plugin architecture, I believe this issue may lie outside the plugin referenced in this patch. To validate this, I built a separate View that did not use the QueryParameter plugin, and replicated the issue. Currently, d.o issue search is giving me a WSOD, so I can't verify if this issue is known already. Once I can verify, I'll follow-up here with a link to a related or new issue.
Comment #3
dawehnerIt would be great to have some unit test coverage ...
<3, but I wonder whether we should get the request from the view object itself instead. This would allow us here to safe at least a couple of lines.
We can use $this->t() always ...
Is this really always about GET, ... note that we might have AJAX request, crazy exposed forms/VBO and what not.
Comment #4
jrbeemandawehner, I was wondering the same thing about your third point. I don't know enough about how the request handling works, but if it's parsing out any request parameters, whether they be GET or POST, then it makes sense to clarify those descriptions. I would anticipate users wanting that capability, regardless.
Comment #5
dawehnerAdded some nice little unit test
Comment #6
damiankloip commentedMhh, removing this will mean this plugin will only work for page views. Not blocks etc...
Comment #7
dawehnerI would argue that https://api.drupal.org/api/drupal/core%21modules%21views%21lib%21Drupal%... should inject the current request into the view executable.
Comment #8
damiankloip commentedThat would be fine - that is not what's happening right now though :)
Comment #9
dawehnerWell I don't have a checkout of drupal by hand.
Comment #10
dawehnerOpened up a critical for that: #2261181: Always pass in the request into the view executable
Comment #11
dawehnerSo for now, #6 is fine and kind of orthogonal to the request issue.
Comment #13
chx commentedIs it true that arguments so far were admin only? So they were considered safe. If so, are we introducing a security weakness / hole here by changing that assumption?
Comment #14
dawehner@chx
Can you be more detailed? Views has argument validation so we can sure that things are always valid.
Comment #15
chx commentedAh, never mind, I get it. Arguments themselves were always user supplied so they weren't treated as safe. And this just changes the defaults but the defaults don't get any special treatment, they just get loaded into arguments which are treated unsafe.
Good to go.
Comment #16
xjmReroll for #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4.
Comment #17
alexpottCommitted 742fe61 and pushed to 8.x. Thanks!
Fixed on commit. The code change is just a spelling mistake.