Documentation Level: 
Advanced
Documentation Status: 
No known problems

Deep Dive: Example Views

Example implementation of basic Views configuration

This section contains examples of how the concepts and functionalities in this chapter may be used. You can find more examples in the exercises.

 

A block with a random image

As a visitor on a photo site I want a random photo uploaded in the recent week to be displayed in the sidebar. This is important since it helps me find photos I otherwise would have missed.

The functionality above can be achieved by the following steps:

  1. A node type for photos, containing images (such as the article node type).
  2. A new node view, with the name random image. In the quick-wizard, the block is checked (while page is left unchecked), and the block is set to display one result only.
  3. In the main configuration panel, a filter fields: field_image – fid ("file ID") is added to filter out nodes where the relevant image field is empty.
  4. Another filter content: post date is added, configured to only display nodes posted the most recent week.
  5. A new view field fields: field_image is added, displaying the content of the relevant image field in a style that fits the websites sidebar. The view field for node title, automatically added by the quick-wizard, is removed.
  6. The use pager is inspected, to assure that only one result is displayed, without any pager.
  7. A new sort criteria global: random replaces the one added by default, to allow selecting a random image.
  8. The view is saved, and the site's block settings are updated to display the new block in a suitable region.

 

Page, block and RSS feed with the latest articles

As a visitor at a news site I want to always be able to see the three most recent headlines. Along with the headlines I want a link to a page displaying more news, and there should also be an RSS feed for the news. This is important since it makes it easier for me to follow the recent news.

The functionality above can be achieved by the following steps:

  1. A new view, with the name recent articles. The quick-wizard is set to list nodes of the type articles, sorted with newest on top.
  2. In the quick-wizard, the option for creating a block is also checked, the option for adding an RSS feed to the page display is checked, and both displays are set to display an appropriate number of results.
  3. In the main configuration panel, the block display's setting more link is overridden and enabled.
  4. The view is saved and then placed in a suitable region from the block administration page.

 

Recently updated documentation pages

As a site member I want a list of documentation pages that were updated recently. This is important since it helps me keep track of updates in the documentation on the site.

  1. The site should have a documentation page content type.
  2. Go to the views overview page and add a new view. (See views overview.)
  3. In the quick-wizard, give the view a name and a description explaining what it does – such as recently updated documentation pages and a table of most recently updated documentation pages on the site. (See creating new views.)
  4. In the quick-wizard, also select that you want to display content of type documentation page. Check that you want a page, and that it should display a table of fields, 25 results at a time, using a pager. Also check the option for creating a menu item, adding it to the navigation menu with the link text recently updated documentation. (See creating new views.)
  5. Click continue & edit to enter Views' main configuration panel.
  6. Add a new view field content: all taxonomy terms, and at the more settings, limit the terms to the topic vocabulary only. (See configuring view fields.)
  7. Add a new view field content: updated date, and set the format to time ago with “ago” appended. (See configuring view fields.)
  8. Add view fields content: comment count, and the content: has new content fields. (See configuring view fields.)
  9. Edit the title field added by Views by default. Add a label title, to provide the related table column with a header. (See configuring view fields.)
  10. Remove any existing sort criteria and add a new, content: updated date, with sort order descending. (See configuring sorting.)
  11. Save the view.

 

Example implementations of advanced Views configuration

 

List articles, grouped by month

As visitor on a blog site I want a list of old blog posts grouped by month, such as February 2011, January 2011, December 2010, and so on. This is important since it helps me find old blog posts I want to read again.

The functionality above can be achieved by the following steps:

  1. A new node view with the name blog archive.
  2. The quick-wizard is configured to display only blog post nodes, sorted with newest on top, and a page with the path blog/archive is created.
  3. In the main configuration panel, a number of view fields interesting to end users are added (such as content: title and content: body).
  4. A new view field content: post date is added, gets marked with exclude from display, has no label, and is outputted in the custom format ”F Y” (which is the PHP date expression yielding ”August 2011”, assuming that is the present year and month).
  5. The format settings are changed to group the view on the excluded date field.
  6. The view's header is set to Blog archive.
  7. A menu link is added for the page display, to be placed in a suitable menu.

 

Tabs with the editor's own posts

As editor on the site for my association I would like each editor's user page to have a tab listing all nodes created by this editor. The list should be accessible only on user pages for editors, and only by editors. This is important since it makes it easier to find your own content.

The functionality above can be achieved by the following steps:

  1. A new role editor.
  2. A new view with the name Editor's list, listing nodes without any particular limitation. The quick-wizard is set to create a page display.
  3. The access settings for the view is changed, allowing editors only.
  4. The filter for displaying only published content is removed.
  5. A number of view fields are added, depending on the information editors want to access (for example content: title, content: post date, content: comment count and content: new comments).
  6. The view format is changed to a table, for example, and all columns are made sortable, for example, with the default sorting providing the newest content on top.
  7. The path to the page display is set to user/%/list.
  8. The page display gets a menu item of the type menu tab and the title posts.
  9. A new contextual filter is added: user: uid.
  10. The contextual filter settings for title is set to Content created by %1.
  11. The validation of the contextual filter value is configured to only allow user IDs belonging to editors.

 

Customized search page

As a site visitor I want to be able to search documentation pages based on when they were updated, topics, title, and free text search. I also want to be able to sort the results by relevance, updated time or number of comments. This is important because it helps me find the documentation I am looking for.

The site should have a documentation content type, as provided by the first exercise in this suite, as well as the topic tags provided by the exercise in the taxonomy chapter.

  1. Ensure that all users have the permission to use search and advanced search.
  2. Add a new view. Give it the name extended search, and have it list content of type documentation page. Check here
  3. In the quick-wizard, also add a page display, showing 25 results with a pager, in a table of fields. Finally also add a menu link in the navigation menu.
  4. In the main configuration panel, add view fields that seem reasonable to display with search results – see the recently updated documentation pages exercise in the previous chapter for suggestions. Make sure to include page title, linked to the documentation page. Check here
  5. Add three new filters, and mark all three as exposed – content: has taxonomy terms (limit to topic vocabulary), content: title (operator contains), and search: search terms. Provide them all with labels that makes it clear to end users that they are search fields. Check here
  6. Add yet another filter, content: updated date and set the operator to greater than or equal to, in order to display pages updated at the given date or later. Make the filter exposed.
  7. Remove the existing sort criteria. Add three new criteria, all exposed – search: score, content: updated date, and content: comment count. Set the default sorting to descending in each case, and change their labels to make it clear to end users what each sorting represent. Check here

The exposed filter for topics could use the reduce duplicate setting, preventing content from appearing more than once. This could be the case if you search for two topics and a documentation page has both of them. Another option would be to enable the distinct setting, which would provide the same effect for the view as a whole. This is found under the query settings in the advanced section.

Usually, search pages result is something similar to a teaser list, which could be implemented in this case too. However, when doing advanced searches it makes sense to present a lot of information condensed into a table.

Users who are not logged in have no use of the column marking if content has been updated since last viewed. Backdrop doesn't keep track of anonymous visitors' page views in the same way as logged in users.

All the search forms and sorting settings make the extended search page appear quite messy. In a real project, this would most likely lead to a new user story with the objective of making it easier to overview all the options.

The initial version of this section of the Community Documentation came from the book Drupal 7: The Essentials, courtesy of NodeOne and Johan Falk.