Views Filters
Filters are what are used to reduce the result set of a View to a manageable amount of data. They are a critical part of the foundation of this system.
The filtering system is a compromise between flexibility and ease of use. To be truly powerful, filters should provide the ability to do an OR, but as it stands, these filters are all ANDed together. That means that every filter is applied. While the ability to do an OR would be nice, unfortunately the level of complexity in the interface to do that is well beyond the benefit that would be given.
The order of filters is irrelevant, though they can be re-ordered as a convenience.
- Field
Exposed Filters
Exposed filters are shown to the user, so that the result set can be modified. The typical example of this is to expose taxonomy as a filter so that the user can select which taxonomy term to filter on.
The order of the exposed filters controls the order in which they are presented to the user.
- Field
What follows is a list of filters that Views provides by default. Like other systems in Views, modules can provide more of these.
- Node: Has New Content
- Including this filter will reduce the node set to nodes that have been updated or have new content since the user last read the node, as well as unread nodes.
- Node: Published
- Filter by whether or not the node is published. This is recommended for most Views!
- Node: Front Page
- Filter by whether or not the node has been promoted to Front Page.
- Node: Sticky
- Filter by whether or not the node is set sticky.
- Node: Moderated
- Filter by whether or not the node is moderated.
- Node: Type
- Include or exclude nodes of the selected types.
- Node: Author is Anonymous
- This allows you to filter by whether or not the node author is anonymous.
- Node: Author is Current User
- This allows you to filter by whether or not the node was authored by the logged in user of the view.
- Node: Current User Authored or Commented
- This allows you to filter by whether or not the logged in user authored or commented on the node.
- Node: Distinct
- This filter ensures that each node may only be listed once, even if it matches multiple criteria. Use this if multiple taxonomy matches return duplicated nodes.
- Node: Author Name
- This allows you to filter by a particular user. You might not find this useful if you have a lot of users.
- Role: Author Role
- Include the node only if the author is a member of the selected role.
- Taxonomy: Term
- When filtering by taxonomy term you may specify the "depth" as an option. Please see the taxonomy help for more information.
- Taxonomy: Terms for a specific vocabulary
- Only terms associated with the specified will appear in the select box for this filter. When filtering by taxonomy term you may specify the 'depth' as an option. Please see the taxonomy help for more information.
- Taxonomy: Vocabulary Name
- This will filter a view to only nodes that contain a term in the associated vocabulary.
Filter Tip: Greater Then or Equal to
I misunderstood the logic of "Greater Then or Equal to" and thought a quick note might save others a little time.
The set-up: a simple view of basic job descriptions, with two fields in the filter section: salary-start, and salary-end, representing the salary range of the job ("This job pays between $30,000 and $40,000"). Both fields are integer fields created in CCK.
The goal: Allow users to search for jobs above a certain salary. For example, if I entered $32,000 in the search field, I'd expect to find all the jobs greater then or equal to $32,000.
What I did wrong: I exposed the salary start field and selected the operator "greater then or equal to". I realized after a few searches that not all of the appropriate records where turning up in my search. For example, I searched on $32,000, and yet a job that started at $30,000 was not showing up. Why was this not working? Wasn't $32,000 larger then $30,000?
The problem was my logic. When I exposed the salary-start field, I thought I was asking "Is my search term ($32,000) greater then or equal to the salary-start field of the job record?" Remember our sample record has a salary-start value of $30,000.
The revelation: What was really being asked is "Is the salary-start field ($30,000) greater then or equal to my search term ($32,000)?" The answer is, of course, no. So the record wouldn't show up in the found set.
The fix: Change my logic. I un-exposed the salary-start field, and instead exposed the salary-end field. Our sample record has a salary-end value of $40,000. Now the logic is "Is the salary-end field ($40,000) greater then or equal to my search value ($32,000). Since the answer is yes, the record is included in the found set.
Exposed Filters rely on Filters
I was confused by the interworkings of Filters and Exposed Filters. When you Expose a filter, it appears in both lists. The choices you make on the non-exposed version apply to the exposed version as well, as defaults in some cases, as parameters in others. If you delete the non-exposed version then you lose control of the Operator and Options fields, and possibly others. Hope this helps someone else in the future.
How to use patterns
The documentation should have some comments on how to use the patterns. I eventually (trial and error) figured out something that works, but there may be more that can be said.
Select "matches pattern" and then put a SQL pattern in the value field without the LIKE or quotes. For example to match any text field that begins with W the SQL pattern would be LIKE 'W%' but for the value field in views all you put in is W%.
Exposed Filters - Select List for an CCK Integer Field
* Rewrite of my previous post... it was too long and obscure *
Is it possible to create a drop down list box/select list exposed filter for a CCK Integer field.
I need an exposed filter on an integer field where users will only enter values between 1 and 10, and I want to show an exposed filter greater than filter using select list ie Show results where "my integer field" is > 2 for example.
Any help very appreciated.
rob | www.beetleweb.com
Force to only show enabled filter options
I am not sure about 5.x, but in 4.7 the exposed filter shows all the filter optiosn, regardless wether or not you set it to a subset of all options. This form_alter snippet changes that behaviout, to the IMO more appropriate subset of filter options.
---
Professional | Personal
Valid values for Operator?
The manual says:
But what is supposed to be "human readable"? Examples:
* I'm trying to filter a date field; I want to display all records matching "today" or seven days earlier. Operator "greater than or equal to" with Value "now" outputs dates in the future; but neither an expression like "now-7" or "seven days before now" works.
* I want to filter all records matching "current month, from the beginning". Of course, this value isn't acceped, also
So which values are valid for the operator?? There's for sure a reference for this, right???
Thanks, -asb
If you want to show only
If you want to show only nodes that are not older than 7 days, you have to add:
- Filter: "Node: Created Time"
- Operator: Is Greater Than (or Is Greater Than Or Equals)
- Value: now
- Option: -604800 (time is calculated in seconds - 604800 means: 7 days * 24 hours * 60 minutes * 60 seconds)
It works perfectly for me.
Please consider issue "Missing terms in filters"
(EDIT) About filters, a patch exists for the views.module v.5.x-1.6: See "Missing taxonomy terms in filters": http://drupal.org/node/199675