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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Status: Active » Closed (works as designed)

Most 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.

njcheng’s picture

Thanks for explaining. It might be good to document/explain this somehow since the option shows in the UI as the "Allow multiple values" checkbox.

dawehner’s picture

From 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.

El Bandito’s picture

@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 :

If selected, users can enter multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND).

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.

El Bandito’s picture

Status: Closed (works as designed) » Active

Whoops. Didn't change status.

stylesuxx’s picture

I 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

dawehner’s picture

@stylesuxx
From my unterstanding this should be fixed in the 7.x-3.x-dev version....

schildi’s picture

It 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

  // Determine if the string has 'or' operators (plus signs) or 'and' operators
  // (commas) and split the string accordingly. If we have an 'and' operator,
  // spaces are treated as part of the word being split, but otherwise they are
  // treated the same as a plus sign.
  $or_wildcard = '[^\s+,]';
  $and_wildcard = '[^+,]';
  if (preg_match("/^({$or_wildcard}+[+ ])+{$or_wildcard}+$/", $str)) {
    $handler->operator = 'or';
    $handler->value = preg_split('/[+ ]/', $str);
  }

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

  $or_wildcard = '[^+,]';
  $and_wildcard = '[^+,]';
  if (preg_match("/^({$or_wildcard}+[+])+{$or_wildcard}+$/", $str)) {
    $handler->operator = 'or';
    $handler->value = preg_split('/[+]/', $str);
  }

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.

schildi’s picture

FileSize
802 bytes

for simplicity, here is the patch

pbusch’s picture

FileSize
902 bytes
dawehner’s picture

Status: Active » Needs review
Issue tags: -multiple values, -contextual filter +Needs tests

.

weekbeforenext’s picture

Version: 7.x-3.3 » 7.x-3.5
Status: Needs review » Needs work

I'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.

weekbeforenext’s picture

This 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.

couturier’s picture

Status: Needs work » Closed (duplicate)

Marking as duplicate based on #13.

ErnestoJaboneta’s picture

I 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.

budalokko’s picture

#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?

weekbeforenext’s picture

Yes, 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.

pwaterz’s picture

Status: Closed (duplicate) » Needs review
FileSize
902 bytes

I 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.

The last submitted patch, views.1534720.2.patch, failed testing.

gmario’s picture

Status: Needs work » Needs review

#18: views.1534720.2.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, views.1534720.2.patch, failed testing.

imclean’s picture

EricB1021’s picture

Re-rolling patch 2 for views 7.x-3.11

drclaw’s picture

Version: 7.x-3.5 » 7.x-3.x-dev
Status: Needs work » Needs review
FileSize
1.01 KB

I 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.

ladybug_3777’s picture

I 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.

3CWebDev’s picture

Path #23/#24 worked perfect! I can now use multiple contextual filters that contain spaces. Any chance to get the patch committed?

zalak.addweb’s picture

Issue tags: +contextual filter, +views
joseph.olstad’s picture

***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.

schiavone’s picture

Wow 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.

If selected, users can enter multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND).

scott.whittaker’s picture

This 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.

dawehner’s picture

+++ b/includes/handlers.inc
@@ -1090,14 +1090,12 @@ function views_break_phrase_string($str, &$handler = NULL) {
-  if (preg_match("/^({$or_wildcard}+[+ ])+{$or_wildcard}+$/", $str)) {
+  if (preg_match("/^({$or_wildcard}+[+])+{$or_wildcard}+$/", $str)) {
     $handler->operator = 'or';
-    $handler->value = preg_split('/[+ ]/', $str);
+    $handler->value = preg_split('/[+]/', $str);

May I ask what happens if the terms have spaces in their name?

jenlampton’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #24 is working for me on 7.x-3.20.

May I ask what happens if the terms have spaces in their name?

@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.

The last submitted patch, 23: views.1534720.23.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

joseph.olstad’s picture

triggered tests on patch 24

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 24: views.1534720.24.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

jenlampton’s picture

Patch still applies to views 7.x-3.22.

calbasi’s picture

jenlampton’s picture

Patch in #24 still applies to 7.x-3.24.
I'm not sure why the test test_views_break_phrase_string is failing...