Drupal Views Module: A Beginner's Guide

Views is the query-builder that generates most of the listing pages, blocks, and feeds on a typical Drupal site — the article listing at /blog, an admin content table, a "related products" block are all, more often than not, Views under the hood rather than custom code.

What Views Actually Does

Views lets you build a database query — which content, filtered how, sorted how, displayed how — entirely through a UI, generating the equivalent of custom SQL and a render template without writing either by hand. It ships in Drupal core as of Drupal 8+ (it was a contrib module in Drupal 7), and most of Drupal's own admin pages (the content overview, the users list) are themselves Views.

Core Concepts

Display — how the view's results are exposed: a full Page (with its own URL), a Block (placeable in any region), a Feed (RSS/Atom), or an attachment to another display. One view can have multiple displays sharing the same base query with different presentation.
Fields / Content — what data each result row shows: specific fields, whole rendered entities, or a mix.
Filter criteria — conditions narrowing which rows appear (published status, content type, a taxonomy term, a date range).
Sort criteria — the order results appear in (newest first, alphabetical, a custom field value).
Contextual filters — filters whose value comes from the current page context (a URL argument, the logged-in user's ID) rather than being fixed — this is what makes one view definition reusable across many contexts, like "articles by this author" working for whichever author's page it's placed on.

Building a Simple View: Recent Articles Block

Structure → Views → Add view.
Set "Show" to Content, "of type" to Article, and check "Create a block" instead of (or alongside) a page.
Under Sort criteria, add "Authored on" descending, so newest articles appear first.
Under Filter criteria, add "Published = Yes" — without this, unpublished draft content would appear to every visitor, not just editors.
Set "Items to display" to a sensible number (5, for a sidebar block) and save.

Place the resulting block via Structure → Block layout like any other block — no custom code involved for what would otherwise be a hand-written query plus a template.

Contextual Filters in Practice

Add a contextual filter on "Content: Author" (taking the argument from the current page's user) to turn a generic "articles" view into "articles by whichever author's profile page this block appears on" — the same view definition serving every author without a separate view per person. Set a sensible "no results behavior" for contextual filters (e.g. "hide the view" rather than showing an empty block) since an author with zero articles is a normal case, not an error state.

Relationships: Pulling in Related Entity Data

A view based on Article content can't directly filter or sort by a field on a referenced entity (e.g. the author's department, stored on the User entity, not the article) without a Relationship. Adding a relationship to "Content: Author" makes the referenced user's fields available to add as Views fields, filters, or sorts — without one, only the raw reference ID is available. This is the single concept that trips up more Views beginners than anything else, since the need for it is invisible until you try to filter/sort by something on the "other side" of a reference and find it isn't in the field list at all.

Exposed Filters: Letting Visitors Control the Query

Marking a filter "Expose this filter to visitors" turns it into a form control on the page — a dropdown, search box, or date picker that lets visitors narrow results themselves (filter a product listing by category, search articles by keyword) without a developer writing a custom search form.

Performance: Views' Own Query Cache

Under a view's Advanced settings, "Caching" controls how long Views caches its query results and rendered output independently of Drupal's broader page/render cache. For a view whose underlying content doesn't change every few seconds, enabling this (e.g. "Time-based" caching) meaningfully reduces database load on high-traffic listing pages. Leave it off while actively building/debugging a view, since a stale cached result during development looks exactly like a bug in the view configuration itself.

Exporting a View as Configuration

Views built through the UI are configuration entities, which means they export cleanly to YAML via Drupal's configuration management system (drush config:export) and can be version-controlled and deployed across environments just like any other config — there's no need to manually rebuild a view by hand on every environment.

Common Issues

A field from a referenced entity isn't in the "Add field" list — missing the relationship to that entity; add it first, then the field becomes available.
Unpublished content visible to anonymous visitors — missing the "Published = Yes" filter criterion; Views does not apply this automatically.
A contextual filter shows every result instead of filtering — the context isn't actually being passed in (check the display's path/block context configuration), so Views falls back to its "no value" behavior, which defaults to showing everything unless explicitly configured otherwise.
Changes to a view don't appear after deploy — the view exists as active configuration in the database that wasn't updated by the config export/import step; confirm drush config:import actually ran and picked up the change.

Need a complex Views-based listing, dashboard, or feed built out? Get in touch — I work as a freelance Drupal developer.