Instead of providing multiple views with different filter criteria, consider empowering your users by exposing filter criteria as an interactive form. You can even configure the forms to use AJAX to refresh results. In this tutorial, we'll walk through the process of adding and configuring exposed filter or sort criteria in a view.

Like exposed filters, we can expose sort criteria to the site visitor. Exposing sort criteria gives the visitor more control over the list of content they are viewing. In this tutorial, we'll configure our view of baseball players to allow visitors to sort the list in different ways by adding several exposed sort criteria.

Contextual filters are a Views mechanism for dynamically refining the contents of a view. It might be helpful to think of them as "dynamic filters". In this tutorial, we'll discuss the concept of context, look at how to add contextual filters in the Views UI, and review the Taxonomy term view that comes with Drupal and how it uses a contextual filter.

Exposing filter criteria allows the users of your site to choose how to filter a content list created in Views. When rendered on the page, the exposed filters will be displayed to the user as interactive form components.

By the end of this tutorial you will:

• Understand what it means to expose filter criteria and when it might be useful.
• Be able to identify when a view has exposed filters and which filters are exposed.

Exposing sort criteria allows the users of your site to sort a view using an interactive form.

By the end of this tutorial you will:

• Understand what it means to expose sort criteria and when it might be useful.
• Be able to identify a view's exposed sort criteria.

With filters, we can define query conditions and refine the results of a view. But what is a filter and how do filters work in Views? In this tutorial, you'll learn:

• How to add and configure filter criteria to a view to refine results
• What configuration options are available for filter criteria operators
• How filter groups allow you to group and order filter criteria to achieve desired results

By the end of this lesson, you should understand how to use and configure filter criteria in Views to refine the results of your view. (Note: We'll cover exposed filters in Overview: Exposed Filter Criteria in Views)

In order to display values for referenced entities in views, you need to add a relationship. What is a relationship, how do they work, and what does it mean to require this relationship? What are some common use cases for adding a relationship to a view? By the end of this tutorial you should be able to:

• Explain some common use cases for adding a relationship to a view.
• Understand the concept of entity references and how those field values can be displayed in a view.

With sort criteria, we can specify how to order our list. We can specify sort criteria using any field on or related to our view's base entity, and then specify in which order to sort, e.g. ascending or descending. If you are familiar with MySQL, it may be helpful to know that sort criteria are the ORDER BY clause of the query that Views builds. In this tutorial, you'll learn:

• How to add and configure sort criteria to a view to sort the list in various ways
• What configuration options are available

By the end of this lesson, you should understand how to use and configure sort criteria in Views. (Note: We'll cover exposed sort criteria in Overview: Exposed Sort Criteria in Views)

Like most output in Drupal, Views relies on Twig templates for a significant amount of its rendering. In this tutorial we'll identify where you can find the default Views templates within your file system, what the common templates are for, and how to name your templates so that they are applied to specific views.

By the end of this tutorial, you should be able to:

• Identify where to find default views templates
• Understand which templates apply to what part of a view
• Get a sense of the template suggestions and how to use them to limit where your custom templates are applied
• Identify a view's machine name
• Identify a display's machine name
• Identify a field's machine name

Now that you understand the purpose of relationships in Views, let's add a relationship to a view so that we can access and display a field value from a related entity.

In this tutorial, we'll modify the Player Awards view to add a relationship to the player that received the award. Then we will add a field that belongs to the player content that would normally not be available to the view without our new relationship.

Now that we understand what templates are and how we can use them, let's override some templates! In this tutorial we'll copy the views wrapper template to our theme and override it so that we can customize the markup for the Baseball Players view. Then we'll modify the template so that our view's pager appears both above and below our table of players.

To follow along with our Drupal Views tutorials, set up a Drupal site loaded with our 4 custom views and baseball stats content that will make querying in Views a bit more interesting and meaningful.

By the end of this tutorial, you should choose a solution and follow the instructions for creating a Drupal site loaded with our starting point content and views.

When a user creates a view, they can set access rules, and restrict who can see the view. The core Views module allows you to limit access by a user's permissions, or roles. If your project requires custom access rules you can define a custom Views access plugin. This will allow you to determine a user's access based on any custom logic you might have.

In this tutorial we'll:

• Define a custom Views access plugin that determines access based on data stored in a field on the user entity type.
• Learn the difference between access checks for routes and access checks for Views displays, and how to use each of them.
• Use our new custom access handler when defining a view.

By the end of this tutorial you should know how to define a custom Views access plugin and use it to grant access to a view.

Area handler plugins are used to determine what is displayed in areas such as the header, footer, and empty text sections of a view. The handlers provided by core cover displaying result summaries, and allowing users to enter in HTML to display. They are already pretty versatile. However, they may require code knowledge to accomplish some specific tasks. If you'd like to have a more specialized area handler that can be reused across multiple views, you may want to look into defining a custom area handler plugin.

In this tutorial we'll:

• Create a custom area handler plugin with settings that can be updated through the Views UI.
• Use the new area handler plugin in a view.

By the end of this tutorial you should know how to define a custom area handler with settings and use it in Views.

In Expose a Custom Database Table to Views we learned how to let Views know about custom tables created by a Drupal module. In that example, the custom table was a stand-alone one, without any connections to the other tables in the database. However, it's common for data in one table to relate to data in another.

For example, you might have TableA with the columns first_name, last_name, email and TableB with the columns email, score. TableA.email and TableB.email can be used to join the two tables together.

It's useful to define these relationships for Views so that when TableA is used as the base table the fields from TableB are also available in the view. When the fields from a related table are automatically loaded, this is known as an implicit relationship. Our earlier example could benefit from the relationship with the users_field_data. This relationship will allow us to associate First Name and Last Name fields from the subscriptions table with the users on the site.

In this tutorial we'll:

• Define the difference between implicit and explicit relationships in Views.
• Learn how to create an implicit relationship between 2 tables using hook_views_data.

By the end of this tutorial you should know how to describe custom implicit relationships in a view, making data from one or more secondary tables available to the Views query builder.

Any Drupal module that provides custom database tables should implement hook_views_data() to describe the schema of those tables to Views. This hook is used to provide information to Views about the fields in a table, their human-readable names, and the types of data (string, integer, date, etc.) stored in each column. You can also tell Views how it should handle sorting, filtering, and formatting the data. Implementations of hook_views_data() can also be used to describe relationships between tables.

If you're creating a module that implements hook_schema() and adds new tables to the database it's a good idea to also add support for Views. Among other things, it'll allow administrators to create any user-facing displays of data from your table using Views. Then, they can be edited without having to write code. Once you've described your table to Views via hook_views_data() Views will be able to provide a way for administrators to construct queries against your data via the UI.

In this tutorial we'll:

• Use hook_views_data() to expose a custom table defined in a Drupal module to Views.
• Learn how to describe different types of data to Views.
• Demonstrate the relationship between hook_views_data() and what a site administrator has access to in the Views UI.

By the end of this tutorial you should know how to describe custom database tables and their fields to the Views module.

Using hook_views_post_render() Drupal module developers can change the render array representation of a View before it gets displayed. You can use this to modify the computed HTML of a view just before it gets printed. This hook is similar to using a preprocess function for a template file, but in this case you have access to the whole render tree, not just the specific leaf covered by the template file you're preprocessing.

This hooks gets called after the Views object has been through the render process, and all the different configured displays and formatters have been applied, producing a render array representation of the results of the view. This hook receives an $output parameter which contains the render array, and only changes made directly to the $ouput variable will have any effect. This hook is the last chance to make changes to the render array before it is converted to markup.

You can use hook_views_post_render() to change #cache properties for the View, and to do things like add CSS classes to rows, and change the page title.

In this tutorial we'll:

• Learn how to alter a view's rendered output right after the Views object completes the render phase of the build cycle.
• Use hook_views_post_render() to change the title of the view's display

By the end of this tutorial you should know how to alter the render array generated by a View prior to it being passed to the theme layer and converted to HTML.

Developers can implement hook_views_pre_render() to make changes to a ViewsExecutable object and change the render array that gets generated by the render phase of a view. By the time hook_views_pre_render() gets invoked, the data to display has already been collected, and things like field formatter configuration have been loaded. This hook gives you the opportunity to dynamically alter that configuration before it's passed to field handlers that will ultimately calculate and return a render array by combining the field configuration with the query results.

You might, for example, dynamically change the label used in a table depending on context that doesn't exist in the view itself. Another example, and the one we'll use here, is transforming a view's rows into a slider (or tabs, or an accordion). That requires that you alter the views object before rendering and attach a custom JavaScript library.

If the thing you want to change is the configuration of the display or any fields, or the contents of the results (versus the presentation of the results) of a view, than hook_views_pre_render() is the right place to do that. If you're looking to alter the generated render array than you'll likely want to use hook_views_post_render().

In this tutorial we'll:

• Alter a ViewsExecutable object using hook_views_pre_render() before the view is rendered.
• Attach custom JavaScript (or CSS) to a view.
• Transform a view of article nodes into an interactive slider using the Slick Slider JavaScript library and some custom JavaScript code.

By the end of this tutorial, you should know how to alter the render array of a view and attach custom and third-party asset libraries in a Drupal site.

At its core, Views is a query generator. It provides a way for site builders and developers to construct queries for Drupal content using an intuitive user interface. The UI allows you to configure the fields, filters, sorting, and relationships in the generated query using common conditions. In most cases, this is sufficient. However, there are situations where you need to dynamically alter the constructed query using hook_views_query_alter() prior to its execution.

One example use case is adding sort parameters to a search view if no search terms have been entered. You can use hook_views_query_alter() to check if a search term was entered. If so, sort the result by relevance; and if there are no search terms, sort the results by date. Or maybe you need to dynamically set the value of a filter condition based on a calculation performed by your custom code.

Using hook_views_query_alter() in a custom module, you can alter the query that is generated by a view before the query is performed. In most cases this alters the SQL query used. This same technique will work regardless of the storage system Views is querying.

In this tutorial we'll:

• Learn how to alter a view's query using the hook_views_query_alter() hook in Drupal
• Use hook_views_query_alter() to dynamically add a new sort condition that could not be achieved using the UI

By the end of this tutorial you should know how to alter the database query used to retrieve the results for a view.

The Views module is a query generator and render engine in Drupal core. It's typically used to create and output collections of items such as Drupal content entities. But it can also aggregate users, blocks, log records, and more. The output can be rendered many ways, including as a list, a grid, or an RSS feed. Views is commonly used in Drupal to create pages, blocks and other types of displays.

Through the Views API developers can expose new data to Views, add new configuration options, create new output plugins, field formatters, sort handlers, filter handlers, and more. By creating these customizations as extensions of Views instead of as stand alone queries, or hard-coded lists, you can empower site administrators to mix and match your customizations with the existing feature set in any way they might need.

In this tutorial we'll:

• Get a high level overview of the Views API.
• Discuss the functional parts of the Views API such as hooks, plugins, and data types.
• Learn how to use the Views API in your project.

By the end of this tutorial you'll have a solid understanding of the parts of the Views API and some guidance on which to use for your goals.