I used to be able to have a list (text) field type attached to users (checkboxes in this case), but no matter what I do views will not treat multiple values for an argument separated with the "+" sign as multiple values even when the "Allow multiple values" checkbox is checked. The generated SQL query is obviously incorrect but I can't figure out where this is generated in the handler code.
In my below use-case, field_admin_groups is a list (text) of checkboxes with text keys (e.g. staff|Staff) attached to users and I'd like the view to accept multiple of these arguments (e.g. to return 'staff' and 'faculty_nonsenate' types), but the resulting SQL simply retains the + sign in the WHERE clause rather than separating into IN ('staff', 'faculty_nonsenate').
SELECT users.name AS users_name, users.uid AS uid, users.created AS users_created
FROM
{users} users
LEFT JOIN {field_data_field_admin_group} field_data_field_admin_group ON users.uid = field_data_field_admin_group.entity_id AND (field_data_field_admin_group.entity_type = 'user' AND field_data_field_admin_group.deleted = '0')
WHERE (( (field_data_field_admin_group.field_admin_group_value = 'staff+faculty_nonsenate' ) )AND(( (users.status <> '0') )))
ORDER BY users_created DESC
With other fields that take numerical values, I have "Allow multiple values" set on contextual filters and this works as designed. I can't get any multiple string values to work. Have I missed something obvious?
Comment | File | Size | Author |
---|---|---|---|
#24 | views.1534720.24.patch | 1.01 KB | drclaw |
#23 | views.1534720.23.patch | 902 bytes | EricB1021 |
#18 | views.1534720.2.patch | 902 bytes | pwaterz |
#10 | views.1534720.1.patch | 902 bytes | pbusch |
#9 | multivalue-blanks.patch | 802 bytes | schildi |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedMost text fields do not support the phrase breaking method (which is the + or ,) in arguments. Typically that's only used for numeric fields, though some very particular text fields might support it.
Comment #2
njcheng CreditAttribution: njcheng commentedThanks for explaining. It might be good to document/explain this somehow since the option shows in the UI as the "Allow multiple values" checkbox.
Comment #3
dawehnerFrom my understanding this is a duplicate of #1424500: Transform spaces to dashes in URL in list fields does not work so i would be happy if you could try out that patch on a site backup.
Comment #4
El Bandito CreditAttribution: El Bandito commented@dawnehner. I don't think #1424500 is a duplicate of the issue njcheng has raised.
I will re-iterate as even if the functionality is as designed ( as per Merlin's comment ) the Views interface leads one to believe it should work, and this has cost me several hours of misguided investigation which it would be good to remedy for others.
I have a multi-value field of type 'List (text)'. I have added this field as a contextual filter and selected the 'Allow multiple values' checkbox which states :
However when I access the path with using multiple values separated by either '+' or ','characters' ( e.g. my_view_path/cf1+cf2 )the Where clause Views generates looks like :
WHERE (( (field_data_field_sector.field_sector_value = 'cf1+cf2' ) )AND(( (node.status = '1') AND (node.type IN ('person')) )))
In other words the operator is simply integrated as a simple character into the string matching query.
IMHO this should either work ( ideal ! ), the interface should make it impossible to configure, or the help text should have a warning that might save people plenty of time.
I am changing this issue to open so it gets one more chance to be resolved.
Thanks for all your efforts on Views.
Comment #5
El Bandito CreditAttribution: El Bandito commentedWhoops. Didn't change status.
Comment #6
stylesuxx CreditAttribution: stylesuxx commentedI have the same problem when I try to use multiple values from a List (String) field where the key is a string and not an int (using ints as Keys is not an option for me).
I have solved this by adapting the regex in the views_break_phrase method and commenting out the check for numeric values.
In my opinion there should be a check if a List has Strings or ints as keys and the according method should be called.
Cheers
Chris
Comment #7
dawehner@stylesuxx
From my unterstanding this should be fixed in the 7.x-3.x-dev version....
Comment #8
schildi CreditAttribution: schildi commentedIt is not fixed at all in version "2012-Aug-09".
A blank in a string is still handled as a (logical) separator in a contextual filter. For example, in my case the title string
Rheinisch-Bergischer Kalender
is converted (multiple values switched to ON) for the query to
(biblio.biblio_secondary_title IN ('Rheinisch-Bergischer', 'Kalender'))
So, it looks that a blank is handled as an OR/IN operator.
Checking the "+" operator (should result in an OR / IN) the following contextual filter value
Rheinisch-Bergischer Kalender+XYZ
yields to
biblio.biblio_secondary_title IN ('Rheinisch Bergischer', 'Kalender', 'XYZ')
Switching "Transform spaces to dashes in URL" to ON does not help. Just additional strange effects:
(biblio.biblio_secondary_title IN ('Rheinisch', 'Bergischer', 'Kalender', 'XYZ'))
EDIT:
Having a look at file views/includes/handlers.inc in function about line 1085 you see
The comment here describes that a space is handled as an OR operator if a plus sign is found in the string.
I don't have any idea why it is treated this way, but wiping out the special handling of blanks leads to
what yields in a where clause
AND (biblio.biblio_secondary_title IN ('Rheinisch-Bergischer Kalender', 'Bergischer Kalender'))
what looks really fine to me.
Someone who is familiar with the code should check this.
Comment #9
schildi CreditAttribution: schildi commentedfor simplicity, here is the patch
Comment #10
pbusch CreditAttribution: pbusch commentedComment #11
dawehner.
Comment #12
weekbeforenextI'm having a similar problem. I'm trying to accept multiple uid values and it doesn't work. I made the changes from your patch in Views 7.x-3.5 and it didn't make a difference. I will take a look at this and see if I can figure it out.
Comment #13
weekbeforenextThis doesn't really solve the root problem here, so I created a new issue with a patch that allows you to accept multiple User IDs as a Contextual Filter.
http://drupal.org/node/1798270
Just posting here in case it helps someone.
Comment #14
couturier CreditAttribution: couturier commentedMarking as duplicate based on #13.
Comment #15
ErnestoJaboneta CreditAttribution: ErnestoJaboneta commentedI don't think this is a duplicate... This issue is about spaces being treated as separators when using multiple valued contextual filters. The issue in #13 is about using multiple UID's in contextual filters, which don't have spaces. Am I mistaken?
Either way, #10 worked for me.
Comment #16
budalokko CreditAttribution: budalokko commented#10 worked for me too.
It looks strange the logic after views_break_phrase_string() method with spaces, which is to consider spaces as part of the string for 'AND', but not for 'OR' logical operators.
I also don't understand how it can be a duplicate of Contextual Filter User ID Allow Multiple. I tested the patch in the other issue and it didn't solve this one. weekbeforenext, could you explain us why the two issues are related?
Comment #17
weekbeforenextYes, this is not necessarily a duplicate issue. I was trying to accept multiple user IDs or usernames in a contextual filter. Selecting the "Allow Multiple values" checkbox didn't completely solve my problem because there was no logic to handle multiple values. I originally posted here because I thought the Allow Multiple values should have worked for me. I posted a second message to share a solution to my problem that is related, for people that found this thread in their search. To be able to accept multiple user IDs or usernames, you have to select the "Allow Multiple values" in addition to my changes in the other issue.
Comment #18
pwaterz CreditAttribution: pwaterz commentedI can confirm the bug noted in #8. Currently if you have space in a contextual filter it breaks spaces into separate arguments. I have updated the patch against views 3.7.
Comment #20
gmario CreditAttribution: gmario commented#18: views.1534720.2.patch queued for re-testing.
Comment #22
imclean CreditAttribution: imclean commentedRelated issue: #1027458: Allow to use multiple arguments with spaces
Comment #23
EricB1021 CreditAttribution: EricB1021 commentedRe-rolling patch 2 for views 7.x-3.11
Comment #24
drclaw CreditAttribution: drclaw at Fuse Interactive commentedI can confirm that the patch works as described. I've re-rolled it against 7.x-3.x-dev with an update to the comment about spaces since it's no longer applicable.
Comment #25
ladybug_3777 CreditAttribution: ladybug_3777 commentedI can confirm that #23 is working well for me on views 7.x-3.11. I'll be running this through more tests and will report back if I find any problems.
Comment #26
3CWebDev CreditAttribution: 3CWebDev commentedPath #23/#24 worked perfect! I can now use multiple contextual filters that contain spaces. Any chance to get the patch committed?
Comment #27
zalak.addweb CreditAttribution: zalak.addweb commentedComment #28
joseph.olstad***EDIT****
Actually, I am not sure if we need this patch yet or not.
I'm thinking that we can process multiple terms from a contextual filter (terms provided by node) by using a with depth (using joins) contextual filter.
this Content: Has taxonomy term ID with depth (using joins)
Display content if it has the selected taxonomy terms, or children of the selected terms. Due to additional complexity, this has fewer options than the versions without depth.
***EDIT***
Confirm this issue, going to review this patch very soon. Our site builder spent weeks banging his head on this issue until we decided to determine if it was a bug (which it is). I made my own solution however I believe that this patch is likely the best solution.Alternatively, by implementing a hook_views_query_alter and we were able to make the regular contextual filter do what we thought it should.
I may spend some more time looking into this.
Comment #29
schiavone CreditAttribution: schiavone commentedWow this has been around almost six years and one can still run into this issue. #28 works for version 7.x-3.18. I do agree with comment in #4 that the field description is misleading since it's not true when using certain filter configurations. in our case we had the filter acting on a multi value term reference field.
Comment #30
scott.whittaker CreditAttribution: scott.whittaker as a volunteer commentedThis is still an issue. this Content: Has taxonomy term ID with depth (using joins) may work with taxonomy terms, it won't help with a list of node IDs.
Comment #31
dawehnerMay I ask what happens if the terms have spaces in their name?
Comment #32
jenlamptonThe patch in #24 is working for me on 7.x-3.20.
@dawehner I tested this patch on a site that uses the filter on a multi-value text field, and all the values for the field I tested had spaces in the names. I'm not entirely sure my use-case is the same as terms with spaces in the name, but the spaces didn't present a problem for me.
I'm changing the status to RTBC, feel free to change back if we need to do more testing for terms.
Comment #34
joseph.olstadtriggered tests on patch 24
Comment #36
jenlamptonPatch still applies to views 7.x-3.22.
Comment #37
calbasiThe same on d8: https://www.drupal.org/project/drupal/issues/3086745
Comment #38
jenlamptonPatch in #24 still applies to 7.x-3.24.
I'm not sure why the test
test_views_break_phrase_string
is failing...