Pull filter value from an argument?

Seconded.

Sorry, at this time Views does not support anything like that.

I was going to create a new thread but I think what I want to do is either the same or similar enough. Say a view takes a taxonomy term/id as an argument. Can you have an exposed filter drop-down of tax terms and which is autoselected upon the argument.

This is a feature request for 3.x

Moved to task queue.

Marked #150248: Can $args & Argument Handling Code be Used to Limit Views to a Range or Series (as opposed to a single match)? and #878622: Proper way to get "past x years" from argument / altering a date filter with argument handling code as duplicates.

See #702070: Filtering results by CCK field using an argument value for a quick workaround.

marked #495634: Argument programming additions to Views help as a duplicate.
It links to this http://drupal.org/node/372064 handbook page that has a few other ways of limiting a view with php and arguments.

Assigning this to myself.

Subscribing to this. Would this allow for multi-year arguments? For example: academic years (September-August) or fiscal years (March-February, perhaps). The dates would stay the same, only the year would change.

Yes at the end this would be supported. You can do anything with filters but with argument as input.

Subscribing (on the basis of using operators on arguments).

my bad.

in a module of mine, I can give the beginning of a cck field in a formular.
My module shows directly the node if just 1 match, a view if none or more than 1.
I would like the view to consider my argument and apply the filter "begins with my argument".
Is it possible actually ? in 6.x-2? in 6.x-3? Is this issue about that?

Here's something to chew on.
It's a patch against the new 7.x UI branch, but almost nothing there is actually 7.x specific, so it can be backported as soon as we agree on the approach and actually have it working.

Warning: If you are not a hardcore Views developer, stay away from this patch. It will eat your dog.

So, I created a new option in the argument edit form.
Was first in a dilemma whether the option should go to the argument edit form, or the filter edit form.
But I figure argument edit form fits it better (and the logic is easier), and it's an advanced option in already advanced functionality (arguments are more advanced and less used than filters).

If an argument is passing its value to an exposed filter, the exposed value will naturally override the one gotten from the argument.
The passed argument value also doesn't affect the display of the exposed filter.

The non functioning part is that I can't get the complete view object with all handlers (including filters) in the argument options form.
I tried going to views_ui_cache_set() and commenting out unset($view->display_handler); but it didn't help.
So I hardcoded the filter handler list so that I could create something that works, but that needs to be taken care of...

EDIT: Of course, this totally fails if using BETWEEN / NOT BETWEEN as filter operators. Not yet sure how that should be handled (exclude filters that use those operators from the list in arguments edit form? Allow one argument to supply MIN and the other MAX?)

Also note that this makes arguments run before filters when building a query which might have consequences.

Pretty neat stuff!

Sweet!

Coincidentally, I wrote a sandbox module this morning that does a very similar thing, but in a quite different way.
The code might be just a little bit interesting, but the README.txt contains some thoughts that I think are worth considering. In particular, I suggest that in a vast future the only needed argument handler is "Global: Null", which would make arguments a non-handler.
(The entire readme is included to the project description, so there's no need to download the module unless you really want to look at the code or try it out.)

Sandbox project "Views arguments in filters": http://drupal.org/sandbox/itangalo/1086472

Interesting!
Read through the module code, using hook_views_query_substitutions() is a nice trick :)
I'm glad we have finally reopened this topic.

Updating my half-broken patch. It now no longer spews notices, and doesn't prevent new arguments from being added. So it's a touch less broken.

Me and Letharion here at Sheraton Drupal Tower have just made a few screenshots showing what a new interface for arguments/filters could look like, when all the filtering capabilities are moved to filters.

The changes are:

1) There is only one argument handler available, Global: Null. (This would then not have to be a handler, and the name could be just "Argument". The new UI term "Contextual filter" would be reverted.)
2) This also means that there will be no list of argument handlers to select from when adding new arguments – you're brought directly into the argument configuration screen.
3) Configured arguments are probably labeld by their validation, since that is likely the most characteristic feature of each argument. (Naturally, custom admin title is also available.)
4) In filters, the "expose" checkbox is changed to a radio select where you can switch between fixed filter value (the normal case), exposed filter values, and picking filter value from arguments. The last replaces all value input widgets with a select list showing all arguments. (As extra bonus, the third radio button could be hidden if no arguments are configured.)

We both think that it is a better approach to let filters pull in data from arguments, instead of having arguments pushing data to filters. This is for (at least) two reasons:
a) You might want to use the sam argument in multiple filters.
b) It will work well even if a filter has multiple input values.

Notice : I'm not a hardcore Views developer, so I'm staying away from the patches and only proposing approaches and UI stuff.

I agree with the previous work. I was thinking the same thing, a setting for each filter where one can compare it to the value of one of the argument. I was thinking about tokens as in "Rewrite output of this field", like [arg_1] etc. Such tokens may be useful for date comparisons. But the neither the dropdown nor tokens cover all UI cases, sometimes checkboxes maybe necessary. An edge case : say node type is passed in the url, and one wants to filter out results according to certain node types AND argument node type ... Well, just create 2 filters and AND them. End of my edge case (auto-answer :)

Anyway, I don't think if I'm not able to write code, but I'll be happy to review/test patches.

The mockups posted by Itangalo look fantastic.

DjebbZ: huh?

I have a similar request posted in #1057624: Pass a query {table.field} name to filter?. It would facilitate a query like:
SELECT a.field1, b.field2 FROM a LEFT JOIN b ON a.nid = b.nid WHERE ( b.year IN a.start_year )

Both in my issue as this one, you want the filter to handle a variable/token , instead of a fixed value.
Could we join the both issues, refrasing this one to 'pass a variable to filter?'.
There is a big difference, though: The 'argument' is passed as a value before executing the query, whereas the table.field's value is to be copied into the query.
If both requests are too different to merge (I expect so), I like Itangalo's filter's settings. It allows for a new 'Filter value input method'-options to be added, such as 'Filter value is field name from query'.

I played with many filters to see what are all (or at least many) UI cases for input, for several filters. I tested with user reference, file, date, taxonomy (description), taxonomy (depth), taxonomy (term), node status. The UI I saw were : select list with multiple choices possible, 2 radio buttons (boolean), select list for the operator (equals, begins with, ...) + text field, autocomplete textfield. Seeing the multiple cases, I confirm that Itangalo & Letharion's new filter option in step 4) is key here ("picking filter value from arguments").

I've read Itanglo's sandbox project description. Looks good ! A note : if it was to be somehow integrated in views (that's the goal here, right ?), how would you handle raw value and validated value for arguments ? Should we be able to use a raw value in a filter from an argument that didn't validate ?
A question on Itanglo's sandbox project : why do you need to have only one type of argument of type "Globa: Null" ?

The fact that there are multiple different widgets doesn't change much.
The main argument in favor of placing the setting into filters is handling gracefully the case when we have two values instead of one (Min / Max).
It's either two dropdowns on the filter edit screen, or having to edit two different arguments and select Filter #1 - Min, Filter #1 - Max.

@Djebbz
The reason you only need the "Global null" argument after this is done is that it no longer makes any sense to select anything else. You will just add as many arguments to the View as you want to make use of, set and validation, and the pass the argument on to a filter. The filter will now determine against what you filter, instead of the argument.

Subscribing

sub

I tried the patch #18 but could'nt make it work... I selected the "Global : Null" contextual filter, passed it to the "Content : Published" filter with the new checkbox. But in this filter, no new option appeared. How is it supposed to work ? Note that I just downloaded D7 core 1.0, and the latest Views and Ctools release with Git.

subscribe

subscribe

After I talked in IRC with @bojanz, @letharion, @merlinofchaos, it appears that pulling from arguments is the best approach. @merlinofchaos In order to push, the order things are built in a view has to change, which is going to have subtle effects. Pull is better, particularly if using an OR. Where you could have multiple filters pulling from the same argument
@me and @letharion Views UI already use pull, when you "rewrite the output of this field" you pull from other fields with fields tokens.
And it will help having "All filtering happens in filters", better usability

@Itanglo's sandbox is about pulling from arguments, we may be able to use his code as a base. I didn't read it though.

(sorry if my quotes hurt people, I just want to push to make this issue solved, so helpful in my eyes)

subscribe

subscribe

Subscribe.

I know everybody posts 'Subscribe' to keep track of issues, but is there any preferences setting anywhere to be notified of updates by email? I can't find one anywhere.

@scott.whittaker I don"t think so...

@scott: I'm pretty sure there isn't one. If you haven't found the Dashboard functionality on drupal.org yet I strongly suggest checking it out. (Look at your profile page and you'll find it eventually.)

It doesn't replace e-mail updates at all, but it's a start.

Update title to make it more specific.

Here is an initial part of the new approach.

One problem which has to be solved is that $this->value might be an array with 'value', 'min', 'max' for example.

This information is stored in option_definition and could be used there.

This additional information would have to be used on the options_form as well.

It currently works for basic boolean filters.

subscribe

Here is a new version which sort of supports the numeric handler,

There are some problems yet with getting/updating the #depedency. It seems to be that you can't AND dependencies together.

It would be really cool if someone could review the patch.

Changing status

I'm not really convinced that the status is needs review :)

Subscribing...

Subscribe

The patch in #39 doesn't apply against the last 6.x-3.x.

Ups yes, i developed this patch against 7.x-3.x

Am not a Drupal developer yet (so everything mentioned here confuses me),
Is there any way yet I use OR operator with my "contextual filters" like I do with my "filters"?
I think currently when I add two contextual filters it is like using an AND operator by default.

This patch would allow you to do it.

sub

sub

subscribe

I would prefer not to apply patches, is it in the dev release or not yet?

@postscripter : there's no harm in applying patches with Git if you create a local branch before. See Patch workflow

@dereine : I'll find some time this week end to review your patch. I can't wait for this new feature.

Hi,

I need this function(pass argument and handled by filter handler). However, I am running 6.x-2.12 Views. What is the relation between views 2.x and 3.x regards with this issue?

On the other hand, I only need to pass one string argument for now. Is possible to change little code only to connect string argument to filter?

hosais

You should wait for the definitive maintainer'a answer, but I don't think this has any future in Views 2...

For your problem, you may want to code an argument handler, that extends the one you're supposed to use, and return the value you need when the field used in the argument match the string passed in argument. Am I clear ? (honestly I don't think so as you don't provide enough details, you'd better open a support request issue to get more help).

@hosais For a quick workaround see comment #7

Views 2 won't be getting any new features of any kind. It's dead, Jim.

Hi,

thanks for the replies.

@DjebbZ, I would like to reuse the filter to process an argument in a link/URL. With this, it is possible to make the filter dynamic (but without user input, <-- this can be done by exposed filter).

I knew that the argument handler is views_handler_argument_string class. I assume it is possible to perform filter after the argument handling [in theroy before the query is made] but I am not sure how to do it right now.

PS. To change the filter, currently I has created an module to make a new operator in filter (class that extends views_handler_filter_string). Detail is at http://drupal.org/node/1166664.

hosais

Hi,

After checking a little bit the source code , I think if I do the following then it would work :

1)If in argument, I set [pass to filter], then let CHILD_views_handler_argument_string NOT ADD where clause.

2)If in filter, I set the value to [argument handler], then let CHILD_views_handler_filter_string NOT put the value to the argument (let argument handler do it).

Any suggestions?

** By the way, maybe I should move this to another thead for view 2 (because here is view 3 issue).

hosais

@hosais As I said before, for a quick workaround see comment #7 and follow the instructions in that issue. If you need views programming help I suggest you join #drupal, the issue queue is not the right place.

I've just tested the patch with the latest Drupal 7.2, Views dev and Ctools dev (pulled from git one hour ago). The patch applies, and I see the new form options. Cool ! I created a very simple content with the title "Content 1". I set up a very simple view, with a page display (url : /test), where I pass "Content : title" as a contextual filter.

Here's my results :
- I tried to filter the view by "Content : filter" and set the operator to "contains" the value from the argument. Not working.
- I tried to filter the view by "Content : filter" and set the operator to "contains any word" and "starts with" the value from the argument. Not working.
- If I set the operator to "is equal to", it works ! So happy to see it the results, in the results preview as well as at the url "/test/Content 1" and "/test/Content%201". Great !

Cheers!

I am also looking forward the new figures in View 3.

For my part, I will continue to figure out.

Thanks for the reply.

hosais

Thanks for testing

Indeed the string filter is not the simplest one.

I'd have a use-case where I need an operator for an argument, but does only work for filters. That patch would help, but I guess it would still apply the argument-filter what would be unwanted in my case.

I do think to properly solve this view arguments need to be built upon filters. The argument should care about getting dynamic values into the view and *always* pass it on to filters - once there is a value it really doesn't do anything else then filtering right? This also would very much fit to the name "contextual filter".

So the argument handler should care about where to get the right value, handle extra argument-stuff like summaries and just pass the value on to filters. With that architecture it would be easy to pass on argument values to multiple filters, or just have everything supported as for filters - like operations. Also passing argument values on as default value for exposed filters would be nice. (Imo exposed filters are conceptually not far from arguments, but currently work totally different.)

@fago: Well summarized – I agree completely.

If you want to solve the problem at hand, without waiting for a neater solution, use the "global: null" contextual filter. It will take an argument, but without altering the query.

Let's be realistic here.

I'd have a use-case where I need an operator for an argument, but does only work for filters. That patch would help, but I guess it would still apply the argument-filter what would be unwanted in my case.

In general there are two ways to do it: pulling or pushing.
I guess the pulling module is the one which fits better, because only the filter knows what values it needs.
Arguments are single valued, so there is no hard limit here.

While the pushing module would have to know how filters look like and there are quite some difficult ones.

About the query issue, wouldn't it be possible to disable querying when a filter value is pulled?

Let's discuss this first before wasting developers time to do it. In general i'm open for both sides of solution.

sub

> Arguments are single valued, so there is no hard limit here.

Not always -- taxonomy term arguments allow combining terms with + and , for AND and OR (though I can never remember which is which...)

As I see it, we currently have three ways for filtering a views query:

- a fixed value set in the view itself
- a value taken from the url
- a value entered by the user in a form

The first can happen in filters or arguments (exposed values), and the second two are divided between arguments and filters.

I think a pull model makes more conceptual sense, where a filter handler can say, for example: "take my value from a) the 2nd url piece, or b) the form if that is set, or c) fall back to this fixed value".

Argument handlers would then just be about defining which position holds what, and doing the non-filtery stuff that some arguments do (is there a list BTW of these?)

Argument handlers would then just be about defining which position holds what, and doing the non-filtery stuff that some arguments do (is there a list BTW of these?)

Good question i guess there are some custom ones around in the world which does special things.
Additional arguments are about displaying the value as title in the url. See modules/node/views_handler_argument_date_various.inc

- a fixed value set in the view itself
- a value taken from the url
- a value entered by the user in a form

You missed "- a value taken from a context", but context means here either for example a panel or some default argument plugin or even a validation plugin which changes the argument.

Ah so even more ways of getting a value...

Ok so wacky post-breakfast idea: what if we have a new type of plugin called 'filter value source'. In *each* filter handler, you can enable one or more of these. (Do we need them to be orderable?)

Eg, in the 'node type' filter, you could say:

- try to get a value from the exposed form
- otherwise, get a value from argument at position 1
- finally, fall back to this fixed value

'basic' filters would just have the fixed value one; arguments as we used to understand them would be a combination of an argument handler + a filter set to take an argument value (and maybe fall back to fixed); exposed filters would be the exposed form value + possibly the fallback value.

subscribing

subscribing.

Part subscribe, part crappy solution suggestion.

Via Services API and the services_views module, I was trying to pass the Content: Title argument to the Content: Title filter so that I could utilize the "contains" functionality for a simple search. After flailing for a bit on a solution, I noticed one potential option that may not work for everyone or every goal, but did work for me and my goal.

One option may be to set the Filter, like Content: Title, to be an Exposed Filter which opens up a GET variable that is configurable under More (after Exposing the filter). You will notice under the input for Filter Identifier that it says "This will appear in the URL after the ? to identify this filter. Cannot be blank." which screamed to me, "GET variable!". Since services_views already expects arguments, display ID's and what not as GET variables, I simply replaced ?args=query in my request with ?title=query and voila.

I know this is not a great or versatile solution, but if your goals are simple or a GET variable potentially averages in, it may be one option out of the box.

Okay just had some motivation to work on the issue. Here are some screenshots how it works at the moment.

In general all the form code is somehow ugly because it has to handle two cases:

* It's just $form['value']
* It's $form['value']['value'];
* It's $form['value']['foo'] etc.

First just find out this by reading the array is kind of hard, some kind of api/extension to option_definition would help
but this maybe would break existing handlers.

Anyway feel free to test it, review the code etc.

@dereine: Great work. I won't close this tab until I have tried out this patch.

One thing which definitive has to be figured out: How to disable the filter part of the argument but keep other things like title which depense on the argument value.

Patch is tested, and I have some comments:

* Generally it works very well. Awesome.
* I was surprised to see that the "Select value from argument for [field]" was present even when using exposed filters. But it actually makes sense – just as you can enter a default value manually, you can then use arguments to set the default value for the exposed filter.
* When using exposed filters, the argument input is also available for "type" of input. (This might only be present when doing dates – where you can switch between "date" input and "offset" input.) I experimented with it, but I couldn't make the argument input to make any sense here. Probably you didn't intend to have it here – and I realize it is difficult for Views to know which input should be able to set with arguments. But if there is a way to block it in this case it would be great.
* The dropdown for selecting a value from arguments is pretty big, and pretty much in the way if you don't want to use it. I don't have any good method for showing/hiding it, other than making it an option similar to exposed filters. (But then we might miss the possibility to combine exposed filters with argument input.)

This is awesome work. I felt right away that it made more sense in how I was filtering with arguments. Conceptually, I think it will be much easier for people to grok.

Thanks a bunch.

Oh great actual feedback. I really appreciate it.

and I realize it is difficult for Views to know which input should be able to set with arguments. But if there is a way to block it in this case it would be great.

You nailed it. I had to make the assumption that $form['value'] only contains things which actually could get an argument.
Just added somehow an api.

 The dropdown for selecting a value from arguments is pretty big, and pretty much in the way if you don't want to use it. I don't have any good method for showing/hiding it, other than making it an option similar to exposed filters. (But then we might miss the possibility to combine exposed filters with argument input.)

Agreement here. This is certainly a more advanced feature so it should be hidden by default.
Damn it's hard to find a short word/two words for the button. I'm currently going with "pull values" but this is probably too technical.

Additional i made quite some changes to have a better code feeling, because i can't sleep at the moment.

Long speak here is the updated code. Some of the value_definition's could be created but as they are optional it could be done later. Still this argument-query problem has to be figured out.

Haven't been able to test this functionality lately, but here's my drop:
A suggestion for the button text: "pull values" = "value source" / "value sources"

I think we perhaps need some sort of rule for who wins when there is both argument and filter data.

I can see these possibilities:

- always use the argument
- always use the argument, *and hide the exposed filter* -- this lets you link to a view to make it act as a sub-listing, eg taxonomy terms.
- always use the argument, but if the filter is changed, remove the argument from the destination URL -- same as above but let the user 'break out' of the sublist.
- always use the filter

What about:
- if the argument is empty or has an invalid value, use the filter. If the argument is OK, use it. But let the user change the value unless a checkbox with an option to prevent this is marked.

For the text:
"Use argument for value"
"Use argument"
"Argument as value"
"Pull argument"
"Dynamic values"

Elaborating on #81 : "if ..., use the filter. If the argument is OK, use it."
I'd prefer to let the user set the pulled value explicitly.
- standard setting 'use filter'
- after choosing the advanced button 'pull values' a select list appears with possible options (plug-ins: argument will only be one of the possibilities!)
- the select list will also have the default value 'filter', which will be set if no advance button is choosen.
- each pull-algorithm can have it's own fall-through logic, just as the current 'use filter' has.

#80: No, I actually don't think we need to determine what should happen when filter value is exposed AND it's getting pulled from an argument – it works in a natural way right now.

The way it works is that the pulled value is treated just as it was written manually in the Views admin – meaning that it becomes the default value for the exposed filter. (If we want avoid having both exposed and pulled values for the same filter, it would make sense to turn the "exposed" option into a select list where you can select filter value input: "by admin", "by user", or "by argument/context".

#81: I'd like to add the suggestions "use context value" and "use argument value", depending on what the labels for contextual filters will be.

subscribe

subscribe

All this is amazing work and looks awesome -- really hope can be ready soon.
(apologies if this is off topic)

Questions for a use case of this new feature:
1 - I have a view (sheesh how often do you hear that) for hotels. Each hotel/node has (1) location.
2 - The view should have an exposed filter that value is generated from the current "hotel node" location_city value. (i.e. location module)
3 - The user can then select from the list and the view updates to only show the (1) city the user selected.

Please let me know if this is inline with what you re doing and if so I can load on a test site to tes.

Thanks!
Hg

p.s. attached an image to help better express the idea.

Correction -- red circle should be over "lhasa city" and NOT "Tibet Hotels"

@HyperGlide: I don't think this is directly related to the issue discussed here – it seems more like an implementation of the existing exposed filters and/or summary settings for contextual filters.

@Itangalo -- Thanks for the reply. Apology was off topic. (will start a new thread on this support request)

Awesome! Just what I would really need! When will this be available?

Sometimes i'm not sure whether people use sarcasm or not :)
I pretend not, so... it's done when it's done.

It definitive needs some testing and review by some people. Then all different kind of filters should be tested
and some more. Once this is done, it can be commited.

Excuse me, I did not mean to be sarcastic. It was possibly the work pressure mixed with the happiness of seeing that it will in time be a feature of views! I should find time to contribute with testing.

In the end, I was able to solve my problem in an other way.

I've been testing the patch from #78, and I've started building a Selenium test to minimize the need of repetitive testing work (see attachment).

The Selenium test requires that the Date module is installed, and it requires that JavaScript is turned off in your browser. Selenium apparently has some problems with the overlay-ish dialogues used in Views UI. Otherwise, use on a standard Drupal installation, with Views, Views UI, Date, Date API and Date Views enabled.

When testing the patch from #78, I get errors when trying to pull values from arguments:

* Notice: Undefined index: #weight in views_handler_filter->show_pull_value_form() (line 268 of …/sites/all/modules/views/handlers/views_handler_filter.inc).
* Notice: Undefined index: #dependency in views_handler_filter->show_pull_value_form() (line 270 of …/sites/all/modules/views/handlers/views_handler_filter.inc).
* Notice: Undefined variable: options in views_handler_filter->show_pull_value_form() (line 280 of …/sites/all/modules/views/handlers/views_handler_filter.inc).
* Warning: Invalid argument supplied for foreach() in form_select_options() (line 2593 of …/includes/form.inc).

Ooops, the uploaded Selenium test suite wasn't really updated. Now it's better.

Here's a quick video showing what this Selenium thing is all about: http://vimeo.com/31718798
If you want to know more about Selenium testing in Drupal, you can check out these screencasts: http://nodeone.se/node/912

Here is a new patch which just fixes the notices.

Hm, two of the errors have disappeared, but the last two ones are still present. (And I don't get any arguments to choose from in the dropdown.)

Selenium says "no". Sorry!

I'm not sure whether we should concentrate on getting date handlers working, because well they are kind of special
and there are a bunch of other handlers which could work here as well.

#98: Fair enough – I'll drop the date handlers from the Selenium test for now. (But note that they have not yet been used in the test – the errors are produced by other handlers.)

sub

Ugh, I get the following errors/warnings when trying to apply the patch:

357082-pull-filter_value-argument-1.patch:9: trailing whitespace.
    $options['argument_value'] = array('default' => array());
357082-pull-filter_value-argument-1.patch:12: trailing whitespace.
    $options['pull_value'] = array('default' => FALSE);
357082-pull-filter_value-argument-1.patch:20: trailing whitespace.
   * Define how value looks like.
357082-pull-filter_value-argument-1.patch:21: trailing whitespace.
   *
357082-pull-filter_value-argument-1.patch:22: trailing whitespace.
   * This function is not required but it helps views to adapt it's behavior.
error: patch failed: handlers/views_handler_filter.inc:60
error: handlers/views_handler_filter.inc: patch does not apply
error: patch failed: handlers/views_handler_filter_date.inc:13
error: handlers/views_handler_filter_date.inc: patch does not apply
error: patch failed: handlers/views_handler_filter_numeric.inc:19
error: handlers/views_handler_filter_numeric.inc: patch does not apply
error: patch failed: includes/admin.inc:1898
error: includes/admin.inc: patch does not apply
error: patch failed: js/views-admin.js:801
error: js/views-admin.js: patch does not apply

@morningtime: Any chance of a re-roll on the patch?

Here's a reroll.

Thanks tim.plunkett! Patch applies well, and the contextual filters now show up in the filter configuration.

When applying them and previewing with a contextual filter value, I get the following error messages:

    Warning: array_values() expects parameter 1 to be array, string given in views_handler_filter_in_operator->op_simple() (line 353 of /Users/johan/Sites/111128/sites/all/modules/views/handlers/views_handler_filter_in_operator.inc).
    Warning: Invalid argument supplied for foreach() in DatabaseCondition->compile() (line 1848 of /Users/johan/Sites/111128/includes/database/query.inc).
    SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')) ))) subquery' at line 1

My conclusion is that the $options array contains the wrong type of values.

@#106: Have you also tried setting an argument value? That's when it failed for me.

Thank you it is very useful path

Do I have to apply this patch if I downloaded Views' dev version of 9 Dec 2011?

mghatiya, yes. The code from this patch is not in views core yet.

I just rolled the patch at #104 against 7.x-3.0: all seems to work fine and the dialogue seems as intuitive as the rest of Views (ie, not immediately obvious, but a bit of poking around and the pennies start to drop). Thanks @tim.plunkett - a fantastic job.

This patch has given me all the functionality I need to manage AND/OR for contextual filters, and offers a *massive* amount of flexibility to Views queries now. A few other reviewers probably needed to look at the other areas discussed in this thread, but let's hope this can be RTBC and committed to Views soonest.

I was unable to fully apply the patch #104 (http://drupal.org/node/357082#comment-5300156) to Views 7.x-3.x-dev as of 2011-12-22,
Drupal 7.10

(...)

The text leading up to this was:
--------------------------
|diff --git a/handlers/views_handler_filter_numeric.inc b/handlers/views_handler_filter_numeric.inc
|index 767654b..239804a 100644
|--- a/handlers/views_handler_filter_numeric.inc
|+++ b/handlers/views_handler_filter_numeric.inc
--------------------------
Patching file views_handler_filter.inc using Plan A...
Hunk #1 FAILED at 19.
1 out of 1 hunk FAILED -- saving rejects to file views_handler_filter.inc.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/includes/admin.inc b/includes/admin.inc
|index 08f1740..1726405 100644
|--- a/includes/admin.inc
|+++ b/includes/admin.inc
--------------------------
Patching file views_handler_filter.inc using Plan A...
Hunk #1 FAILED at 1899.
Hunk #2 FAILED at 4397.
Hunk #3 FAILED at 4418.
3 out of 3 hunks FAILED -- saving rejects to file views_handler_filter.inc.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/js/views-admin.js b/js/views-admin.js
|index 104239a..b0f03d7 100644
|--- a/js/views-admin.js
|+++ b/js/views-admin.js
--------------------------
Patching file views_handler_filter.inc using Plan A...
Hunk #1 FAILED at 806.
Hunk #2 FAILED at 820.
Hunk #3 FAILED at 828.
3 out of 3 hunks FAILED -- saving rejects to file views_handler_filter.inc.rej
done

The patch #104 applied against Views 7.x-3.x-dev as of 2011-12-22 , Drupal 7.10
caused
Fatal error: Cannot redeclare views_handler_filter::value_definition() in /***/sites/all/modules/contrib/views/handlers/views_handler_filter.inc on line 99

I applied the patch from #104 successfully against 7.x-3.0 but I can't seem to figure out how I would go about creating an OR link between two contextual filters.

Can anyone point me in the right direction?

@xanderol: The logical grouping is managed by ordinary filters. Add "global: null" contextual filters, and then pull these values in ordinary filters.

The ordinary filters can be grouped into logical AND/OR sets using the "rearrange" option in the "add" menu.

this is pure awesomeness :) thanks !

for eventual new testers - one thing that took me a while to realize : you need to use a global:null contextual filter in order for it to pass silently to the filter ( i kept getting both >= and = in my where clause with the original filtering contextual filter).

2 notes :
- after deleting a contextual filter which was in use as a value to filter, it creates an error
- the "normal filter" that is obtaining values from the contextual one, doesnt show it on the view config page - looks like a missing value - i have : Commerce Product: Product ID (>= )

Can't apply patch #104 against latest releases (7.x-3.1 and 7.x-3.x-dev (1 Feb 2012)).

error: patch failed: handlers/views_handler_filter.inc:60
error: handlers/views_handler_filter.inc: patch does not apply

Been using the functionality for a few weeks now under a patched 7.x-3.0 and it has been fantastic. Not sure I've been thorough enough, but if the patch can be re-worked, can we review all this a little quicker and get it committed. Against 3.0 I've encountered no problems; just awesomeness.

patch #104 not able to be applied on 7.x-3.x-dev -- 2012-Feb-07, hope to see the latest patch soon, expecting this function for a long time, thanks!

Trying 7.x-3.0 views patched with #104 to display list of nodes number of comments of which exceed or equal the number provided by argument (contextual filter). The argument value is defied by a user filling CCK field during a node creation. Let's call this field as a Goal. So the idea is to have a list of nodes, which has at least as many comments as defined by Goal fields of their respective nodes. Unfortunately the possibility of pulling argument to filters introduced by the patch doesn't work in my situation, the list is always empty. What I might be doing wrong?

Edit: Exposing mysql query for my views gives:

SELECT node.nid AS nid, node_comment_statistics.comment_count AS node_comment_statistics_comment_count, node.title AS node_title, 'node' AS field_data_field_image_node_entity_type, RAND() AS random_field
FROM 
{node} node
INNER JOIN {node_comment_statistics} node_comment_statistics ON node.nid = node_comment_statistics.nid
WHERE (( (node_comment_statistics.comment_count >= '') )AND( (node.status = '1') AND (node.type IN  ('blog')) ))
ORDER BY random_field ASC

which means argument was not pulled at all: (node_comment_statistics.comment_count >= '')

I've just added a comment count argument with 7.x-3.0 and patch #104 and the correct SQL is generated. @yngens: Did you check the 'Pick values from arguments' checkbox?:

Arrrgh, yes I did. And then comment count argument is actually pulled out at my installation too. However, the problem is when matched with a value in CCK field it does not work - SQL generates request with empty argument.

I tried otherwise too - have added CCK field as an argument and comment count as filter element and tried to match (compare) them, unfortunately again CCK field value returned empty.

Silly question: why go through the hoops of pulling filter values from arguments? Why not just support AND/OR groups in Arguments, the way we do in Filters?

Applied the patch cleanly to 7.x-3.0. Built a view to list Event nodes where "individuals invited" (an entity reference field for adding users to an event) = global:null argument I created to catch the UID from the URL.

I know it is catching the UID from the URL correctly, because a) I have validation for the argument, and b) I've added a global:text field to the view to output !1 . But when I use it as a filter "individuals invited = global:null", it generates invalid SQL. Same as yngens, the WHERE clause is empty: "WHERE (( (node.status = '1') AND (field_user_groups_taxonomy_term_data.uid IN ())". Will investigate further today.

I built a simpler view just showing events and filtering based on individual invited grabbed from the global:null argument, and it worked. So I went back to my original view to look for differences.

I removed all requirements from relationships on the original view, and the SQL was valid again. I could filter based on "individual invited" as this patch intends.

The point of the relationships is for the second half of the view results: I want to include events that share taxonomy terms with the user entity referenced in the URL. So I added a filter group (OR operator between the groups), and a second filter comparing "related term content:user name(uid)" to the global:null argument... and I got invalid SQL again. A closer look at the filter I was using shows that it expects the user name in text, rather than a numeric UID. So I think the reason I had invalid SQL is just a misconfigured filter.

But this raises an issue: do we need some kind of validation to make sure that input from the argument is valid for the selected filter?

#122: (a) Filters also have the ability to use different operators, and (b) conceptually it doesn't make sense to have two different parts of Views doing filtering when it could be only one part. (Kind of.)

Decided to reroll this patch against 7.x-3.3 so I can update views in the process :)

Patch applied cleanly and seems to work.

@blazindrop: Yes the patch was applied successfully, but when I accessed the view, error occurred.

Notice: Undefined index: argument_value in views_handler_filter->pre_query() (line 777 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Notice: Undefined index: argument_value in views_handler_filter->pre_query() (line 778 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Warning: Invalid argument supplied for foreach() in views_handler_filter->pre_query() (line 778 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Notice: Undefined index: argument_value in views_handler_filter->pre_query() (line 777 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Notice: Undefined index: argument_value in views_handler_filter->pre_query() (line 778 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Warning: Invalid argument supplied for foreach() in views_handler_filter->pre_query() (line 778 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Notice: Undefined index: argument_value in views_handler_filter->pre_query() (line 777 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Notice: Undefined index: argument_value in views_handler_filter->pre_query() (line 778 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).
Warning: Invalid argument supplied for foreach() in views_handler_filter->pre_query() (line 778 of /subdomains/client/sites/all/modules/views/handlers/views_handler_filter.inc).

legendm33066: I looked at that line of code and make sure you have an argument supplied so the filter can pull that.

As bojanz said earlier in #15, stay away from these patches unless you're very familiar with views internals and can contribute to fixes on this thread.

Attached is the screenshot. I want to get all nodes with "associated_clients" field equal to the argument supplied by URL. But the instructions and documentation seem a little confusing. Is there anything wrong with my configuration?

Patch from #126 is missing a line which was in patch #104 in handlers/views_handler_filter.inc (aprox line 95)
$options['argument_value'] = array('default' => array());
you can try add it manually to see if it helps,
also you ca see the difference by comparing first lines of both patches

apart from that I was able to apply patch #104 on D7.12 with views 3.3, although with manual intervention on few chunks and had no complains so far, thanks allot

@dscutaru: Thank you so much! Now everything is fine. No error message and the function seems fine.

Based on patch from #126 and implements the fix from #130, here is a minor re-roll of the patch.
This patch is applied on the 7.x-3.3 tag and not the 3.x-dev

I've the same problem of @ohthehugemanatee ( comment #123 ): the query have no value in the IN () section. It looks like the value picked from the arguments is not passed to the filter when using entity reference filters.

My issue discussed in 119-121 and legendm33066's issue in 129 have similar task, which has been successfully addressed by me in a custom module by replacing

$query->condition('c.comment_count', 'g.field_goal_value', '>='); 

to

$query->where('c.comment_count > g.field_goal_value');

since it turns out that the second element in $query->condition('1', '2', '3') can not take arguments. I am not sure, but probably if '$query->where(' was utilized instead of '$query->condition(' then lot's of issues mentioned in this thread could be resolved.

Subscribing to this lovely feature request. Will help test and code!

Successfully applied patch #132 and it is working though when dealing with date elements, there are some issue in the options form. When dealing with dates, the value contains value, min and max. All three possibilities are being shown in the options form in show_pull_value_form(). What's more is that in those values settings, there are no titles defined and thus the labels are shown as "Select value from argument for ."

I've attached a screenshot showing the issue.

I'm posting to see if anyone familiar with the code has come across this yet. I'm also willing to work on updating the patch to resolve this issue but wanted to check first to see if anyone else was already on it.

Thanks

Grant

subscribing

I successfully applied the patch, and used a Global:Null filter to pass the context, but I noticed a couple issues when trying to apply this solution to a node reference filter

1. When I create the filter using the "Is one of" operator, I must select at least one (or all) of the available references or else I get the error below, from the filter validation:
   • No valid values found on filter

   Ideally if the option is going to come from an argument, then filter passed-in value would be validated.

2. If I do select one or more options in the filter, & pass in an argument, then I get the error below:
   • SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')) )) ORDER BY node_created DESC' at line 3

@grantlucas,

I'm experiencing the same issue with date field filters. Do you know if there's a patch in the works?

Thanks
-Cameron

@eusonic Not that I know of yet and I haven't had a chance to look into creating one in the past bit. :(

Would it be possible to reroll patch in #132 to the latest dev? Many thanks.

This is really, really useful, thanks! If we can get dev patched with #132, that would be great.

patch #132 works great to me if I consider the values as array

function pre_query() {

    foreach ($this->options['argument_value'] as $value => $argument) {
      if (!empty($argument)) {
        $argument = $this->view->argument[$argument];
          $this->value[$value] = $argument->get_value();
    }
  }

@zabelc (#138): you're experiencing my same problem (#133), the query is not complete on the IN( ) section due to a bug somewhere

bye

I'm curious: If Views is going into core, what are the chances of this feature request being included?

My personal view is that this issue is pretty significant, and would allow Views to do some important new things. And it would probably be very difficult to add as a contrib module, which means it could only be added with new core releases.

Hi Itangalo,
i read with much interest your sandbox project and the 'views_arguments_in_filters'. reading this page i can't see which patch to use for views 3.3 module. i'm not a developer, and i would be much interested in having this functionality. can you tell me which to use ? thanks..

The patch is working well.
I achieved a view showing terms having a field of a value or empty which was impossible before.
I hope this will be integrated in Views core soon !

I tested the module (proof of concept) indicated by itangalo in # 145 for this case:
Display nodes of Type A that referenced the same node type B (with a field_entityreference in the node of type A) displayed in the Type A node currently viewed..
Relations are made with entity reference, and the problem is that I had in my view all the nodes of type A that referenced node type B, including the current node viewed. With this approach, I could easily exclude of the view the current node (nid != %1) and finally obtain an equivalent related content you can have with the taxonomy. However, I hesitate to use this approach in a production site.
I hope this feature will be integrated as soon as, it opens very interesting perspectives.

I apologize for my English

I've cleaned up a lot of the comments, simply because I had a difficult time wrapping my head around what was going on.

I found the "pull_value" (a boolean) option extremely confusing in the code, because it collides with the the "argument_value" (non-boolean). Additionally, the concept of "pulling" the argument seems confusing, and thoroughly detached from the reality of where arguments come from. Although I did not change the functionality at the code level, I did remove it from the UI and replaced it with more natural sounding and helpful explanations about exactly where this data is coming from: a contextual filter. This will make this patch much more appealing to how views 3 works *today* (regardless of how we may eventually like it to work to merge contextual filters back into regular filters, in a single unified interface). IMHO, this is a step in the right direction, until someone can completely merge contextual filters into regular filter hanlder's, which is beyond the scope of this initial proof of concept.

I've rerolled this for both 7.x-3.x-dev and 7.x-3.3.

Oops. here is a re-roll for 7.x-3.3 (forgot to strip down the urls so that git apply would work). Note: this patch is expected to fail, because it will not apply cleanly to 7.x-3.x-dev

Please, rename views-357082-7.x-3.3.patch to views-357082-7.x-3.3-do-not-test.patch because the bot only can run tests for 3.x-dev patches.

subscribing to this thread

applied the patch and global:null on taxonomy field but still no luck... latest views dev and ctools 1.2

I am a PHP developer but a couple of form and field modules are about the extent of my Drupal module development efforts so making changes to Views is a little beyond me at this point.

This seems like the best way to apply conditional argument filters to a view but I have Views 7.x-3.5 installed. Will the patch work on 7.x-3.5? If not, will I need to go back to a previous version of Views?

(I just noticed this is a feature request and the patch only applies to 7.x-3.x-dev)

#151 works for me.

What are the chances of this getting into views?

Re-roll per #153, to get a clean slate. *crosses fingers*

+1

I'm not sure this has much chnance of getting in without tests :)

I've been testing #157 with current Views dev and it seems to work great :)

When adding a filter and setting it to use an argument, I mistakenly selected "dropdown" instead of "autocomplete". This resulted in a "No valid values found on filter" error when I tried to save. But "autocomplete" is the default option so this isn't a big deal.

I'm still a bit wary of using this on a production site as it feels like significant new functionality which might be way off being committed (?).... but it is super-useful...

I'm using views-357082-153-7.x-3.x-dev.patch with Views 7.x-3.5+21-dev.

After adding the filter 'Content: Has taxonomy term' with the operator 'Is none of', using an argument provided by a contextual filter I get...

Warning: Invalid argument supplied for foreach() in views_many_to_one_helper->ensure_my_table() (line 972 of [...]\sites\all\modules\contrib\views\includes\handlers.inc).

... and the view contains only nodes with no taxonomy terms referenced.

If I force views_handler_filter->pre_query() to always return an array then the above filter works as expected.

Patch in 157 worked great for me with latest views dev - awesome feature, would love to see it in views. I did have one challenge in that Global Null does not allow multiples, but that was easily addressed with a views_query_alter to change the '=' to an 'IN' and the value to an array - here it is if anyone needs it:

function mymodule_views_query_alter(&$view, &$query) {
  if ($view->name == 'myviewname') {
    $query->where[1]['conditions'][0]['value'] = explode('+', $query->where[1]['conditions'][0]['value']);
    $query->where[1]['conditions'][0]['operator'] = 'in';
  }
}

general fyi, and to answer #155, the 3.x-dev patch in #157 applies (with offsets) to 7.x-3.5.

Great contribution but it doesn't work when option "Exposed form in block" set to "yes". Someone has a solution ?

Thanks.

@vitchy, I doubt seriously that there is a solution for what you want, but its a valid, albeit edge case. Think about it conceptually... you can't have a value pulled from a contextual filter also exposed to the user without bringing in all kinds of other issues such as which one takes precedence when both the contextual argument is provided AND an exposed filter value is provided. But this is all the more reason why I think "contextual filters" and regular "filters" should all be part of the same mechanism. IMHO, it makes little sense that contextual filters are buried under the Advanced section, when exposed filters are doing a very similar thing... just passing the variable by GET (which is yet another context).

Hi,

I tried the patch from #157 and have some questions:

I created a contextual filter, which I wanted to OR with some regular filters, then I added a regular filter and enabled "Use an argument provided by contextual filters" and selected the contextual filter I just created.

The Views query output showed that I have something like:

(contextual filter condition) AND (contextual filter condition) OR (regular filter conditions)

Which is not the expected result for me as there shouldn't be the first parentheses ... Is there any workaround for this?

Thanks.

I think it may be because you didn't use Global NULL for your contextual filter.

I think it may be because you didn't use Global NULL for your contextual filter.

Ah that's it! Now it works...

Thanks a bunch! :D

So the status of this patch is that it needs to include some new tests for the new functionality, right?

I have issues when trying to use multiple global NULL contextual filters with multiple filters. I can only seem to get one of the values from the arguments to pass through properly (the last of the two).

FYI - In my view I actually use 3 and everything is fine. I also found adding an admin name to each Global NULL contextual filter made selecting the contextual filter to use in the filter easier.

I tried that too. Still, only one of the values gets through. These is some code in the patch to specifically handle things different based on a count of the filter attributes. I couldn't quite understand the point of that, but it seems to be cause of the problem. Removing the special handling gets it working for me. I can not use multiple contextual filters in conjunction with OR filters that use hem.

Hi,
I used this patch and it seems to work properly without any reported errors so far. I have just one question: Is it possible to include a routine that makes it possible to hide entries in subsequent exposed filters? In my case I can see entries that should have been excluded by the first filter (the first filter filters by the uid of the content's author, the second filter gives an exposed filter to select instances of a content type...

regards

Subscribing (on the basis of using operators on contextual filters)

#172: views-357082-172-7.x-3.x-dev.patch queued for re-testing.

I have tested #172: views-357082-172-7.x-3.x-dev.patch on my sites, it applies and works well, I didn't find any bugs, also it is not broke any other functional.
Maybe there are already time to see it in core?

Working great for me; thanks! Would love to see this in absorbed.

Please commit.

This patch also provides a workaround for the issue that some fields, e.g. date fields, do not provide the usual filter options when aggregation(group by) is enabled.
I recently solved such a case by applying this patch and creating a PHP argument.
Good to go.

Tested ...works fine. Please commit.
Thanks

I've patched an older dev with this, which also has the patch at #1766338: Incorrect filter group OR behavior, LEFT JOIN changed to INNER JOIN applied.

Does what it says on the tin.

Tested and got an error/site became unusable after deleting a Contextual Filter that was being used by a filter I setup with this new Filter Criteria feature. So probably should fix that before committing.

(I already restored and don't have the specific error but if you need, you can easily reproduce it by doing the same).

Please always post the actual error, as this already helps to understand it.

("error" as in "error message")

Hey there, just wanted to chime in that this patch worked for me out of the box. After so much work to try (unsuccessfully) to match the spirit of this patch using crazy hacks, I can't recommend this idea enough.

Patch worked straight away on 7.x-3.5.

Created a view which showed just the 'client' content type associated with the current page but all of the 'contractor' content types.

Found the UI very easy to work out.

Hi
Intended usage: Calendar whose Meeting (content type) entries have a link which takes users to a view of Minute Items (content type) filtered by Meeting Type (taxonomy term) then by Start and End times of the meeting (as timestamps). Ultimately, I want the view to show the meeting minutes from that specific meeting - Current Business (things that were on the list 2 weeks before the meeting), New Business (things that were put on the list within 2 weeks of the meeting) & Matters Arising (things that happened during the meeting)

Having problems with getting timestamp arguments into a Post Date filter. Getting a "Invalid Date Format" error. I have tried with multiple combinations of things e.g. Meeting as Entity or Content Type. Different link rewrite rules in the calendar view. Couldn't get the ISO date to work from calendar as it has colons in it!

Using Views 7.x-3.x-dev patched with views-357082-172-7.x-3.x-dev.patch.

Can anyone shed any light on this issue for me please?

Any progress on this? This feature is so ridiculously powerful that it's really something worth releasing...

I implemented patch 172, add the global null for the contextual filter, and added the filter criteria to use the input from the Contextual Filter and I receive an error:
No valid values found on filter: Content: ....

This is not an exposed filter. I'm trying to embed a view and include content with a fieldA=X OR fieldB=Y.

This was extremely simple with views2+ViewsOR in D6, and is unfortunately a showstopper for me now :(

Anyone have any tips on how to implement this functionality without major workarounds? I'll just use D6 otherwise since it's so much cleaner with the ViewsOR.

How about taking this patch further, and merging "Contextual Filters" as "Context" option for regular Filters?

I support this idea, would completely make sense! We have just stumbled into a use case where the merging of Contextual Filters into Filters would have been the perfect solution!

@giorgio79 @temaruk can you explain that idea a bit more? Intriguing :)

Moving Contextual Filters into the regular Filters section as "context" is exactly what I was referring to in passing comments on #150 and #165.

IMHO, this would be the correct way this patch should be reworked; +1

The idea is to get rid of Contextual Filters altogether from the "Advanced" section (third column of Views UI) and rework it completely into the Filters section (first column of Views UI).

1. If you compare the "Add filter criteria" and the "Add contextual filters" popups, they are *almost* the same. These two screens would essentially be combined into a single "Add filter criteria" pop-up.
2. In the subsequent screen, we place in a proper "Source" option list (radio buttons maybe?) to let the user choose where the filter should come from. This would amount to a) hiding the existing "Operator" selector from view, and b) replacing the "Expose this filter" checkbox with a series of radio buttons with the following options:
   • Hardcoded -- filter value is specified in the Views UI, and stored with the view configuration in the database (or exported to code).
   • Exposed -- filter value is pulled from the Query String. Multiple filters can be chained via field=value pairs separated by ampersand; each filter can have a custom exposed field title, and may be limited to either GET or POST values.
   • From Context -- filter value is provided to the view from some context (ideas on possible contexts further below)
3. Depending on which of the three options was selected, further options would appear much like the existing exposed filter checkbox works today.

Context filter could be:

• values pulled explicitly from the URL (eg /page/some+term). This would require explicitly setting up the view with arguments in the path, and this option would be hidden unless the view was setup in such a way
• Query string (ie GET values) -- technically speaking, this obviates the existing "exposed filters" functionality.
• POST values
• values could also be sent to the view from others places, just like how existing contextual filters works today: programmatically; or from panels context argument input; or even just pulled "automagically" from the Drupal path (eg the node id context from the internal Drupal node/X pages).

I don't think you need two tiers of sources for your filter values. It would be easier to have:

- hardcoded
- exposed form
- URL path
- ... etc

> This would require explicitly setting up the view with arguments in the path, and this option would be hidden unless the view was setup in such a way

This would mean we'd still have argument handlers -- just that their function would be reduced to handling and processing the path components on the view and making them available to filters.

I think it makes sense to keep all functionality in current contextual filters, except the actual filtering. Views already has a plugin system that allows arguments to be fetched from different sources (as demonstrated by Views Content Panes), and it makes sense to keep things like validation, title altering and "actions to take if no argument is present".

And I 100% think it makes sense to move the filtering functionality to the filters. (But this is no surprise.)

This would be great. As one would have all possibilities for contextual filters interaging with normal filters, such as grouping with AND/OR combination for example (I'm missing this right now for contextual filters), this feature would become even more powerful.

And it seems, the solving of this issue here will solve almost every problem I've got with views right now. :-)

We quite possibly need to move this issue to D8 core though, and work on it there first before backporting.

I don't think you need two tiers of sources for your filter values.

That makes total sense. In #193 my thinking was that with a 2 level format it would be easier to move over the entire filter criteria form wholesale, without added baggage of restructuring and combining exposed and hardcoded filters with contextual filters. This might still make sense for the initial refactoring, with the goal being one single tier source list as the final product.

I've been using the patch in #172 for quite a while now, and this functionality is super useful.

Regardless of whether or not this is the best way to do this, it doesn't look like anyone has found any bugs with this implementation, and I'd love to see this committed. I do think that in the longer term, reworking the contextual filters into the filters section would be significantly better as described above, but I think this functionality should be committed now so that it is available for use today.

The patch in #172 does not work with date_views, but that's probably because they rename a bunch of form elements temporarily.

#150: views-357082-7.x-3.x-dev.patch queued for re-testing.

@joachim, move this issue to Drupal Core 8.x or create a new one directed at core?

My vote would go to creating a new issue for core, geared at a real proper refactoring.

Patch from #172 works well on Views 3.7, works without any issues for me.

> @joachim, move this issue to Drupal Core 8.x or create a new one directed at core?

Probably the latter, as refactoring would be great too.

But best talk to one of the Views maintainers on IRC and see what they say. I don't know how late it is in the D8 cycle for that sort of refactoring!!!

I'm using this patch with views 3.7 but it causes a little conflict with the filter "Has taxonomy terms (with depth)", when I tried to save the views I receive this error message:

No valid values found on filter: Content: Has taxonomy terms (with depth).

To avoid this I had to modify handlers/views_handler_filter_in_operator.inc line 417 to add a check on the argument_value like this:

if (count($this->value) == 0 && (isset($this->argument_value) && count($this->argument_value) == 0)) {

I'm not 100% confident on this change so I'd better leave this as a comment only for the moment.

Patched views 3.7 and no problems so far - not that I've gone very far with it.

What I gather from the comments is that I don't need or shouldn't use any contextual filter other than the Global:null. I don't understand the Global:null contextual filter. When I set its default value at Content ID from URL, what am I extracting from the URL? And when I pass that value to my regular filter, what am I passing? Aren't there multiple attributes in the URL and so, if Global:null is my only contextual filter, how do I specify which one gets passed to my regular filter?

Global:null basically gets an argument into the $views argument array without doing anything with it. You use it in the same way you'd use other arguments, via %n. I think. ;)

I applied the patch from #172 and it works, but if I use it to filter one value in a in custom field that contains multiple words it doesn't work. It works only when the value of the custom field matches exactly the value of the contextual filter, which is a kind of the same as when you use only contextual filters alone.

I also think #193 could be very exciting, but should be handled in a different issue.

P. S. I've found an interesting article here, that might be of help temporarily:
http://n00bsys0p.co.uk/blog/2012/08/21/drupal-views-3-contextual-filter

Raised #193 as a feature request here #2001764: Merge "Contextual Filters" as "Context" into regular Filters

Maybe I'm configuring it wrong, it seems to work for so many people.

So this is what I do:

- use the patch from #172 against views-7.x-3.7
- create a new view and add a page display
- In the Page settings I set the path to "location/%"
- I add a contextual filter "Global: Null" leaving all settings as default.
- Then a add a Filter criteria for the field I want to filter on, in my case this field is called "Location"
- On the filter settings I check "Use an argument provided by contextual filters", set the operator to "Contains" and choose "Global: Null" as the contextual filter. I am not sure for the value that has to go in the "Value" field, I tried leaving it empty, writing "%", "%1" and so on.

So now when I write "Germany" I get the nodes which location fields contain only the word "Germany". But if there are some nodes, whose location field says "Berlin, Germany" and I try to write only "Berlin" as my contextual filter, those are not found, althogh they should be, as the operator is set to "Contains".

#172: views-357082-172-7.x-3.x-dev.patch queued for re-testing.

While I hope this patch will make it into Views, in the mean-time here's a tiny module (rather than a patch) that may work for some of you: Views Filter Harmonizer.

Giving this a shot in the meantime: https://drupal.org/sandbox/itangalo/1086472

@Renee, #215:
Promising sandbox.
Does that solve:
o dealing with default contextual filters
o filter ranges, eg http://drupal.org/project/contextual_range_filter

I'd say there's a place for BOTH the sandbox project/patches above as well as http://drupal.org/project/filter_harmonizer
Rik

Hi RdeBoer -- it's the creation of @ltanglao; I just found it ;)

- dealing with default contextual filters

No. I use an alter hook; Filter Harmonizer may work great for that for others.

- filter ranges

No. Contextual Range Filter is the solution for that one.

What it does that neither of those do is allow you to use arguments in your filters. So. That's what I'm using it for. It performs as advertised ;) Ideally the patches would get committed, but... yeah :)

Does any of this help override my querystring?

My sample original path below:
mysite.com/search.xml?affiliate=food_service&query=breakfast

I have an exposed views filter that should override "query" with whatever is entered.

Right now it looks like it's doing this, if i enter e.g. "water":
mysite.com/search.xml?affiliate=food_service&query=breakfast?query=water
which of course, returns no results.

Any idea how I can make this work?

@Jumoke, #218
That's exactly what Views filter harmonizer does, as mentioned in #216.
Rik

Sorry to interrupt with a bit of usability/SEO questions: of course, both filter systems are kind of confusing and overlap one another functionality, but the current Contextual filters has interesting feature (although, I think by accident) - www.mysite.com/my_view/my_term_name is much more friendly for web crawlers and for general usability than www.mysite.com/my_view?my_term_name_tid=123
I think in most cases, even in multiple selection there is technical possibility to have clean urls, even semi-clean urls in the case of complex filters like: www.mysite.com/my_view/my_term_name/my_term_name2?my_term_name_tid=3 is much better.

Yes, content is the king, and this is not as much relevant as in the web crawlers infancy but still cool feature ;)

I use hook_views_query_alter() into my small custom module:

function MYMODULE_views_query_alter(&$view, &$query) {
  foreach ($query->where as &$where) {
    foreach ($where['conditions'] as &$condition) {
      if (!empty($condition['value']) && is_scalar($condition['value'])) {
        $value = $condition['value'];
        $arg_key = drupal_substr($value,1);
        if (drupal_substr($value, 0,1) == '!' && is_numeric($arg_key)) {
          if (!empty($view->args[$arg_key-1])) {
            $condition['value'] = $view->args[$arg_key-1];
          }
          else {
            $condition['operator'] = 'IS NULL';
          }
        }
      }
    }
  }
}

use !1, !2,... values as usual in filter criteria condition

#221 does the trick nicely for me. Perhaps someone could just publish this as a contrib module. Perhaps it would be the smallest one ever!

Re #222: the argfilters sandbox linked above is actually even less code, and it works great! :)

I needed to use this "!n to arg(n-1)" filter substitution on a project. Neither #221 nor #223 worked for me. #221 didn't seem to work at all and #223 only worked with field replacements. I needed to insert the view argument into a filter. After two days of running around the internet in circles, I took a look myself. Using Devel, I determined that the value coming out of the filter (e.g. "%!1%") would never match #221's criteria (e.g. "!1"). It also only worked with scalar values. I've rewritten the hook_views_query_alter() function to use regex to replace the !n pattern in the $query's conditions. It works with select lists, Global:Combine filters, as well as textfields. Enjoy!

<?php
function hook_views_query_alter(&$view, &$query) {
//Traverse through the 'where' part of the query...
  foreach ($query->where as &$where) {
    //...and all its conditions
    foreach ($where['conditions'] as &$condition) {
      if (!empty($condition['value'])) {
        //check for multiple values
        $values = is_array($condition['value'])? 
                          $condition['value'] : array('scalar' => $condition['value']);
			
        foreach($values as $key => $value) {
          //find pattern match, extract numerical index of match
          preg_match('/\!([0-9])/', $value, $matches);
				
          if ((count($matches) > 0) && (!empty($view->args[$matches[1]-1]))) {
            //create new condition with matching view argument
            $nc = preg_replace('/\!([0-9])/', $view->args[$matches[1]-1], $value);
					
            //replace original condition with new condition
            if ($key == 'scalar') {
              $condition['value'] = $nc;
            } else {
              $condition['value'][$key] = $nc;	
            }
          }
        }
      }
    }
  }
}
?>

I'm trying the patch in #172, but I guess I need help setting it up.

Background:

Tour booking node:
- has guide field (for overall booking)
- has tours field_collection
- has date/time field (one field collection for each day of multi-day tour)
- also has guide at this level - possible different guide for each day
- has optional tours field_collection
- this is for when a guide "sells" extras during the booked tour(s)
- also has guide at this level (extras can be assigned to a different guide)

So, there are three places where guide can be specified - at the overall node, and in each of two field_collections (which can have unlimited occurrences).

My view needs to show ALL tours for a specific guide. I *think* the view is set up to select from the tours field_collection (instead of the node) - but I can't be sure. I'm returning to this after being away for a while and now I'm realizing that there's no way (or I can't see a way) to find out what a view is based on once it has been created. Can anyone steer me in the right direction on that?

Regardless, the contextual filter should filter on only one of the above. Then the other two should be regular filters that get the value for guide from the contextual filter. When I set it up as I thought it should be, I got "No valid values found on filter: Field: Guide", and under Filter Criteria it showed "Field: Guide (in unknown)".

Even if I get this issue solved, I'm not sure how to make the contextual filter be included in the "or" condition. A guide will not be specified at the node level AND in one or both of the field_collections - but rather (usually) in only one of those three places.

Any help would be greatly appreciated.

172: views-357082-172-7.x-3.x-dev.patch applies successfully on current views 7.x-3.8 version without any warnings, all filter values in arguments works well on my site, but I don't understand why it not pass automated tests?

Had high hopes for this; sounded like a good option to having OR groups for contextual filters.

problem is though is that both of my filters are options lists and if i dont pick an option the view doesn't validate. Thinking i could just pick one to pass validation and the use global null would take precedence; but no. it uses the selected option.

+1 - verified basic behavior function as desired. Need more info on what is needed for full testing.

See https://www.drupal.org/project/views_evi for a different approach to this.

That's sort of the approach that I think we should take to properly merge filters and arguments for D9. Argument handlers should mostly just capture the data and validate it. Filter handlers would then have 3 possible sources: fixed input, exposed input, or input from a specific argument.

YEP joachim, dereine/dawehner confirmed that's a god idea when i talked with him in berlin.
I created that module to gain userland experience with that first, and i'd really appreciate your review.

Heh not to add too much fuel to this fire, but noticed the 'views_argument_substitutions' module does pretty much what this issue is describing?

https://www.drupal.org/project/views_argument_substitutions

For an example:

I have a view in ticket that shows the tickets that have been registered to you (user_uid) by someone else (author_uid).

The argument is the current user, and the filter checks to make sure the author uid doesn't equal the user_uid.

It'd be great to see how these patches and this additional module might be able to be merged into views.

Should we move this to a core issue and then consider backporting?

if first contextual filter value need to be accessed in second contextual filter's php code then is this the right issue? (will create a new issue otherwise)

I thought contextual filters are accessible by its subsequent filter just like how views fields are accessible in their subsequent fields, surprisingly it is not out of the box.
BTW I posted the scenario at https://www.drupal.org/node/1871388/discuss and attaching the same screenshot here for ref.

I have tested most of the available modules that try to accomplish this, the only one that actually worked for me (works for a views block, also works for numeric values) is:
https://www.drupal.org/project/views_argument_substitutions

Re-roll of #157 for current dev and 3.20. This at least allows those of us who did use this patch to upgrade.

#233:
> 'views_argument_substitutions' module does pretty much what this issue is describing?

This (and a lot of other token-based modules) work perfectly for text fields. But not at all for a lot of other fields (think: date, term, ...) that won't validate tokens or don't use textual widgets at all.

that's the reason i created views_evi, see #230.

Thanks @ChaseOnTheWeb -- we're still using this patch on a legacy site that we don't want to refactor to use views_argument_substitutions.