Advanced Views Configuration

Views fields

As soon as the filters are set, and sometimes even before that, you usually add your view fields (labelled fields in Views, but here called view fields to separate them from entity fields). View fields are the data fields that the view will display to end users. Even if the view has access to all data about (for example) a node, you can choose to only display title, author and the time when the node was updated.

Grouping view fields

The sub settings for view formats contains an optional grouping field. This allows you to select a view field used to group all results before they are sorted – all results with the same value in the view field will be grouped together, using the view field as header for the group. Grouping of view fields may for example be useful for displaying all comments on your site, grouped by the day they were written.

TIP: If you don't want the view field used for grouping to appear inside the actual list, you can use the exclude from display setting in the view field configuration.

 

Rewriting view fields

You sometimes find yourself in situations where view fields contain data that you want to show in the view, but it doesn't quite fit your needs. You have the author name, but you would like it to say written by James Joyce rather than just James Joyce. In these situations you can use the option rewrite the output of this field and also output this field as a link. Both of these options are revealed when clicking the rewrite results option when configuring view fields. The options allow you to take control of the text (or otherwise) shown in the view field and any link that Views creates from the view field.

An important feature is that you may use all view fields so far loaded by Views as variables when rewriting your field. For example, you could include a user ID when building a link, or a node title when setting a link tooltip. The rewrite settings in the view field configuration contain a list of available variables.

TIP: The option to output a field as a link only works for affecting links created by views (such as the link this field to the original piece of content setting) – not if the view field itself contains the link (such as image fields rendered as links to a node).

 

Exposed settings

Views can expose a number of settings to end users, allowing them to adjust settings as desired. The settings that can be exposed are filters, sorting, and pagers. For example, the settings can be used to build a comment list displaying only comments written by an entered user; a node list that lets users search for words in the node title; a list where users select the number of results to be displayed on each page; or a list that can be sorted either by most recent or by most popular content.

Filters are exposed by checking the option expose this filter to visitors, to allow them to change it, in the filter configuration dialogue. Sort criteria and pagers have similar options.

Settings for exposed filters

When exposing a filter, a number of new settings become available. The most important ones are:

• Label: This text will be shown at the input box for the exposed filter, prompting users to enter something.
• Expose operator: This option allows you to expose the operator for the filter, not only the filtering value.
• Remember the last selection: This setting allows storing the parameter values for the exposed settings in the user's session cookie for the site, instead of passing them in the URL.

If a filter value is entered into the filter configuration, it will be used as the default value in the exposed filter (unless other settings say otherwise).

TIP: With the Search module enabled (which is the case in a standard Backdrop installation), a filter option search: search terms is available. It can be used as an exposed filter to get the same search results as Backdrop's built-in search. Using Views to build search pages drastically increases the possibilities for customizing search filtering and display.

 

Settings for exposed sort criteria and pagers

When sort criteria are exposed, you may choose custom labels for the sort fields. For example, the data field user: name could have the label author or user when presented to the visitor. End users can choose which of the exposed sort criteria to use and can select either an ascending or descending sort order.

The exposed settings for pagers include how many results should be displayed per page, and, optionally, an offset. You may include or exclude the option to display all results on one page.

 

Exposed settings in blocks, and further settings

The Views main configuration panel contains two further settings for exposed settings, under the advanced section.

They allow the following options:

• Exposed form in block: This option moves the exposed settings from the view header to a completely separate block. Placing exposed search filters in a block on your site may serve as a customized search box. The block must be placed in a region to be visible.
• Exposed form style: This allows you to set whether end users are required to set exposed filter values, or if all fields may be empty. Sub settings allow you to set the text displayed to the end users on things such as the button to execute the settings.

TIP: Moving exposed settings to a block normally only works if the view has a page display. Otherwise Views doesn't know to which path end users should be redirected when using the exposed settings.

 

Contextual filters

Views is a highly flexible module to start with, but the contextual filters increase the use cases for the module by an order of magnitude. Contextual filters work similarly to regular filters, but there is one important difference. Instead of setting a filter value manually, the value is fetched from variables sent programmatically to the view. A regular filter could give you all nodes written by a specified user. A contextual filter for a node author would be able to display all nodes written by the currently viewed user, or the same user who wrote the currently viewed node. The concept is that contextual filters prepare a view for filtering, but the filter value is not yet determined. When the view is eventually called, it is also provided with data used to complete the contextual filters.

The classic example of how contextual filter values are provided to views is by the view path. If a view has the path example.com/my-view, the URL example.com/my-view/story/22 will call the view along with two values for contextual filters (in this case story and 22). But there are more ways of providing contextual filter values.

The difference between standard filters and contextual filters may seem trivial, but in practice it is huge. Contextual filters allow you to reuse views in many different situations and allow Views to interact with other parts of the website. One could write an entire book about how to use contextual filters in Views.

Configuring contextual filters

Contextual filters are added and managed in the advanced section in the Views main configuration panel. They generally follow the same patterns as filters, but have a number of settings that normal filters lack. Take a deep breath:

• When the filter value is not in the URL: This setting determines the view behavior, if there is no value for the contextual filter. This is an essential setting when using contextual filters in block displays.
• Override title: This setting is used to alter the view's title, if there is a contextual filter value present. You may use variables in the form %1, %2, and so on, to include the first, or second filter values in the title (and so on). If there is any title element associated with the filter value, such as a node title for node IDs or user names for user IDs, the title element will be used - but only if the contextual filter is validated (see "Specify validation criteria" below). A typical use case is the title articles written by %1.
• Override breadcrumb: This setting allows you to set the breadcrumb to use when a filter value is present – or default to using the view title. The breadcrumb will lead to the view without this contextual filter value and the view must have a valid response to this.
• Specify validation criteria: Since you cannot limit what users may input as contextual filter values in the path, there may be reasons to verify that the filter value corresponds to what you expect. This setting allows you to validate the filter value in a number of ways. It also determines the view behavior if the validation fails. A typical example is to only allow filter values that are node IDs for selected node types.
• More/allow multiple values: This setting allows several values for the contextual filter. Values separated by commas are interpreted by Views as AND conditions. Values separated by plus signs are interpreted as OR conditions. A typical example is allowing several taxonomy term IDs to display all content marked with any of the terms.
• More/exclude: This setting inverts the filtering. The rows matching the filter criteria will be excluded rather than included. A typical example is applying this to a node ID filter to exclude the node currently viewed from a list of similar content.
• Reduce duplicates: When filtering on several criteria, Views may end up repeating some of the results (if they meet more than one condition). This option reduces any duplicates, but makes the database query heavier. A typical example is reducing duplicates occurring when filtering on multiple taxonomy terms.

It is worth pointing out that contextual filters lack some of the settings available for normal filters:

There is no functionality for grouping contextual filters in OR or AND groups.

There are no options for selecting which operator should be used with contextual filters (save the exclude option). All default to is equal to.

TIP: There is a data field unique to contextual filters – global: null. It is used to have the view accept filter values without altering the database question created by Views. The null contextual filter may still alter the title or breadcrumb of a view and validate the input.

 

Managing missing filter values

It often happens, even deliberately, that views with contextual filters are called without the data to set the contextual filter values. This is particularly true for block displays, which without any paths don't have a natural way of receiving contextual filter values.

You can configure each contextual filter to set how the view should react if the filter value is missing.. The options are:

• Display all results for the specified field: This will ignore the contextual filter all together.
• Provide default value: This is used to fetch/create an artificial filter value, should a real one be missing.
• Show ”Page not found”: This hides the view.
• Display a summary: This alters the view, having it display a list of all filter values that would lead to results in the view, linked to the view with each contextual filter value present. The list may be configured in a number of ways, for example to display the number of results for each filter value or displaying a jump menu rather than an HTML list.
• Display content of ”No results found”: This gives the same result as when the view has no results to display.

The functions for creating or fetching default values for contextual filters are used rather frequently, especially for block displays, and there are a numbers of options available to do this. These options may vary between different data fields, but the most common ones are:

• Fixed value: This gives a static value, provided by you when the view is built.
• Content ID from URL: This is used to fetch a node ID from the current path, assuming it contains a node ID.
• PHP code: This allows a manually entered PHP script, with access to local data, to build a default filter value. Having PHP code in the configuration is bad for a number of reasons (such as security and performance), but it may be useful during prototyping.
• Taxonomy Term ID from URL: This is used to fetch a term ID from the current path. You may optionally fetch term IDs from a currently viewed node and limit the terms to selected vocabularies.
• User ID from URL: This is used to fetch a user ID from the current path and, optionally, the user ID for the author of the currently viewed node.
• User ID from logged in user: This fetches the user ID from the active user.

For contextual filters for date and time fields there are some settings available to fetch current date and time, or time values from a currently viewed node.

The normal way a view gets values for contextual filters is by the view path. The easiest way of doing this is to append filter values to the path, separated by slashes. It is also possible to have contextual filter values within a path. This is done by using a percent sign where the view expects a contextual filter value in the path of the view (for example user/%/comments).

Having contextual filter values inside paths is particularly useful when creating menu tabs, which is the subject of the next section.

Creating menu tabs

Page displays have settings for creating menu items, found in the group page settings. The options no menu entry and normal menu entry are rather self-explanatory, but there are two more options that require some explanation.

 

Menu tab

The first of the more obscure options is menu tab. Menu items of this kind will be visible as tabs on a given path, here called the tab's main page, rather than being displayed as normal menu items. Two requirements must be met to use menu tabs:

The path to the menu tab must be the same as the tab's main page, but one step deeper. If you want a tab to show up on example.com/main-page, the path to the menu tab could be example.com/main-page/my-tab.

There must be at least two (accessible) tabs on the main page. If there is only one tab present, it will be hidden by Backdrop to avoid displaying tabs unnecessarily.

TIP: Menu tabs are efficient ways of extending existing pages on your Backdrop site. A view with the path node/%/related could be added as a tab to all node pages with a few clicks.

 

Default menu tab

The second somewhat mysterious option is default menu tab. Creating default menu tabs is similar to creating regular menu tabs, but at the same time you are creating the main page for the tab. (This should only be used if there is not already a main page available.)

If the path to a page display is example.com/my-view/default-tab, a default menu tab will make the view accessible from both example.com/my-view/default-tab (the tab page) and example.com/my-view (the main page).

When configuring a default menu tab, you are also prompted to set which kind of menu item the main page should use.

Note: This section should be complemented with descriptions of the new fancy menu option "contextual link".

 

Relationships

The last group of Views settings presented in this book is relationships. Relationships are used to allow Views to bring in data that is associated with the data already available in the view. A comment view could, for example, use the relationship comment: content to tap into data about the node for each comment. A term view could use the relationship taxonomy: parent term to tap into data from the parent term of each listed term.

TIP: People comfortable with writing SQL queries will recognize the relationships as joins.

 

Adding relationships

You add, edit and delete relationships in the same way as filter, view fields and sort criteria by using the add button and its related menu. (See figures 10.10 and 10.11) The settings for relationships are:

• Identifier: This is the name that will be used for the relationship within the Views administration interface.
• Require this relationship: Checking this option will make the view exclude items where this relationships cannot be fulfilled. For the relationship taxonomy: parent term, for example, it would mean that terms without parent terms would be excluded.

TIP: Relationships are powerful tools, but if used carelessly they may slow your site.

 

Utilizing relationships in configuration

A view with relationships will, for each result in the view, not only have data for the base object of the view, but also for the objects described by the relationships. When editing the configuration of data fields there is (where applicable) an option relationships in the fieldset more. This setting can be used to select which object should be used for this data field. This means that in a comment view utilizing the comment: content relationship, you can choose to filter on node type. If you are including the relationship comment: user you could sort the results by the name of the user writing the comment.

TIP: When creating a view you select the base table for the view, comments, users, nodes, etc, to decide what will be the view's base objects. Some functionality in Views always acts on the base object, ignoring all relationships. An example of this is the distinct option, hidden under query settings in the advanced section.

 

Other Views settings

This is the longest chapter in the book, and it was preceded by another whole chapter about Views. Despite this, there are some more aspects of Views that a well-trained Backdrop developer should know.

This section should be updated with a description of the aggregation settings.

There is some new functionality in Views allowing grouping directly in the database query generated by Views. The settings are enabled by the option use grouping in the advanced section. Once enabled, a number of data fields may be used for grouping operations. The functionality is not fully developed, and it is not clear how it will work. But it will make it possible to sort nodes by the number of comments, or taxonomy terms by how many nodes are marked with each term.

At the toolbar, Structure, Views is a settings tab revealing a number of global Views settings. The two sub tabs basic and advanced contain options that are useful to see how different views affect your site's performance, or if you discover that the string <Any> can't be translated with Backdrop's normal translation tools.