Views

Views is a core module that builds lists from the data a Drupal site stores. You describe what to fetch, how to filter and sort it and which format to show, and Views runs the query and renders the result. Each saved list is called a view, and one view can feed a page, a block, a feed or a data export.

How Views works in Drupal 11

The module describes itself as a framework to fetch information from the database and to display it in different formats. A view is a configuration entity of type view. Its parts, from displays and formats to fields, filters, sorts and caching, are plugins, so a developer can add new kinds without changing the module.

The User Guide names the parts of a view. A display sets where the output appears. The format sets how rows look. Fields choose which values appear, filters limit the rows, sort criteria set the order, contextual filters take a value from the context such as the URL, and relationships connect another entity such as the author.

In the 11.4.10 source, the Views module has a hidden Default display that holds shared settings, plus the display plugins Page, Block, Feed, Attachment, Embed and Entity Reference. The row plugins include Fields and Entity, where Entity renders each item in a view mode. The style plugins include Unformatted list, Table, Grid, Responsive Grid and HTML List. The caching plugins are None, Tag based and Time-based. Tag based caching persists until related cache tags are invalidated; see cache.

Views can only list what a module has described to it. A module does that with hook_views_data(), and an entity type normally does it through a views_data handler in its entity class. That is why content, users and files appear in Views without extra work.

Core uses Views for its own admin lists. The Node module ships the content view for the content administration page, as well as frontpage, and the Taxonomy module ships the taxonomy_term view. The Standard profile enables both Views and Views UI.

Example

A newest-articles block follows the User Guide's block recipe. Go to Structure › Views and edit the view that lists your articles. Under Displays click Add and choose Block. Add the sort criterion Authored on and choose Sort descending. Set the pager to display a specified number of items, for example 5. Save the view, then open the block layout and place the new block in a region such as Sidebar second. The page list keeps its own settings, because in each dialog you choose the option that overrides only this block.

Common mistakes

• Building a second view for each variant. Add another display to the same view, or use a contextual filter, before copying the whole view.
• Leaving caching to chance. A view can use no caching, tag based or time-based caching. Pick one on purpose and test it with the content changes your editors really make.
• Expecting a field to appear that no module described. If custom data is missing in Views, the module that owns the data needs to provide it.

For marketing and content teams

A list of news, events, team members or resources is a typical job for a view. When you ask for a new list, name the content, the filters visitors should have, the sort order and where it appears. That gives the person building it everything they need. Ask whether the list should react to the page it sits on, as a related-content block does; that is a contextual filter. A change to a view is configuration, so it reaches other environments only after an export and import.

With DXPR

The DXPR Builder page says you can place existing blocks and Views in your layout, so a list built in Views can sit inside a visually edited page.

Sources

• Drupal User Guide: Concept of uses of Views
• Drupal User Guide: Concept of the parts of a view
• Drupal User Guide: Adding a block display to a view
• Views module, Drupal 11.4.10 source
• hook_views_data(), Drupal 11.4.10 source
• Standard installation profile, Drupal 11.4.10 source
• Content view configuration, Drupal 11.4.10 source