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.
Drupal core is built with performance and scalability in mind. It is Fast by Default. But performance is often a by-product of your specific application, and depending on how you're using Drupal, you can further optimize your site using contributed modules. These modules range from debugging utilities to cache-related modules.
It's worthwhile to have a general idea of what's available in the contributed module space. And, when you need to address your site's unique performance needs, it helps if you already know about existing solutions.
In this tutorial we'll:
- Look at a few popular contributed modules that improve Drupal's performance
- Learn about the benefits these modules may provide to your site
- Provide tips on how to configure these modules
By the end of this tutorial you should be able to list some popular performance related Drupal modules and describe their use case.
The performance optimization settings and modules provided by Drupal core are intended to work for the broadest possible set of use cases. From an administrator's perspective they provide minimal configuration options, and are designed to just work by being enabled. But behind that simplicity are some powerful features that will help speed up any Drupal-powered application.
The core Dynamic Page Cache and Internal Page Cache modules are designed to provide a base cache setup for any site. These modules are responsible for the static page cache, dynamic page cache, and lazy loading optimizations.
For developers, Drupal provides a complete and well-designed Cache API. You can, and should, integrate it into your custom code. This integration includes defining the cacheability of any content your module outputs so that Drupal can be smart about how that affects how and when a page that incorporates the output can be cached -- as well as storing and retrieving the results of complex or long-running operations. The API also helps with setting appropriate HTTP headers for the responses Drupal generates for each request so that the user's browser and other layers in the stack can appropriately cache the output.
The entire system is flexible, and there are many contributed modules that can aid in making the default caching system even faster for specific use cases.
In this tutorial, we'll:
- Learn about the caching-related modules in Drupal core
- Review the Drupal core performance settings and recommended values
By the end of this tutorial you should be familiar with the Drupal core modules responsible for caching, their settings, and recommended values.
There's no magical set of right tools to use to monitor a Drupal site's performance and health. While thinking about performance monitoring, you need to optimize your approach depending on the number of applications you manage, their complexity, business needs, and the skill-set of your team. Based on these factors, you may choose to use one of the core or contributed modules, go with third-party solutions and services, or some combination of both.
Drupal core comes with a couple of modules that allow you to monitor the health and performance of the site including Syslog, Database Logging, and the status reports provided by the System module. There are also numerous community-contributed modules, a sampling of which we'll cover here.
In this tutorial, we'll:
- List some contributed modules that are commonly used for monitoring a Drupal site
- Provide an overview of what each module does
By the end of this tutorial you should be able to list a few contributed modules that might be useful for monitoring your Drupal application and define what each one does.
No one likes to wait for a slow site to load. Not me, not you, and definitely not search engines. And the effect of site load times on things like SEO, user bounce rates, purchase intent, and overall satisfaction are only going to become more pronounced over time.
Drupal is a modern web framework that is capable of serving millions of users. But every site is unique, and while Drupal tries hard to be fast out of the box, you'll need to develop a performance profile, caching strategy, and scaling plan that are specific to your use case in order to be truly blazing fast.
Drupal site performance depends on multiple components, from hardware setup and caching system configuration to contributed modules, front-end page weight, and CDNs. Experienced Drupal developers looking to optimize their applications know where to start looking for potential savings. They can manipulate settings and combinations of these components to achieve the desired results. Our goal with this set of tutorials is to help explain the process and provide you with the insight that comes with experience.
In this tutorial we'll:
- Introduce high-level performance concepts for Drupal that we'll then cover in more detail elsewhere
- Provide an overview of the main Drupal performance components.
By the end of this tutorial, you should understand what components around your Drupal application are responsible for site performance.
Drupal recipes provide a new way to package and share reusable features across Drupal sites. Unlike traditional install profiles or distributions, recipes are applied once to add functionality and then step out of the way, leaving you with a standard Drupal site that you can customize freely.
In this tutorial, we will:
- Understand what Drupal recipes are and how they differ from install profiles and distributions
- Learn the four core properties that make recipes powerful: applied (not installed), shareable, non-locking, and composable
- Explore real-world scenarios where recipes solve common platform and agency challenges
By the end of this tutorial you'll be able to explain what Drupal recipes are, identify features in your projects that are good candidates for recipes, and articulate the value of recipes to stakeholders.
Recipes transform your Drupal site by adding features and configuration. After downloading (or authoring) a recipe it needs to be applied to your Drupal project. This is analogous to following the step-by-step instructions in a recipe to make a dish. Only, we're not performing the steps on our own, but instead we're using Drupal's tools to apply the recipe. Applying the recipe adds its features to your Drupal project. This requires establishing safe workflows to apply recipes, verify their effects, and roll back changes if needed.
In this tutorial, we will:
- Apply a recipe in a non-production environment using a feature branch workflow.
- Review configuration changes using Git and verify functionality in the UI.
- Understand how to roll back recipe changes if needed.
- Learn safe workflows for both developers and non-developers.
By the end of this tutorial, you'll be able to safely apply recipes to your projects, review their impact, and decide whether to keep or roll back the changes.
The built-in config actions in Drupal core cover most common scenarios. But sometimes you need custom operations specific to your feature or the configuration your module relies on. You can create custom config actions by defining them as plugins or by adding PHP attributes to a configuration entity class's methods. Let's implement a custom config action to toggle an SEO strict mode setting to learn how to extend recipes with domain-specific configuration operations and make them reusable across your projects.
In this tutorial, we will:
- Identify scenarios where custom config actions are warranted.
- Understand the two implementation patterns: plugins and attributed methods.
- Implement a custom config action in a module.
By the end of this tutorial, you'll be able to implement custom config actions that extend the configuration API provided to your recipes, making platform-specific operations reusable and declarative.
The Configuration Actions API lets recipes modify existing configuration rather than just adding new configuration. By extending the SEO Article recipe created in a previous tutorial with config actions, you'll learn how to manipulate existing configuration objects in order to do things like grant permissions and modify entity display modes. This is necessary because sometimes a recipe needs to modify configuration that already exists on the site, not just add new configuration.
In this tutorial, we will:
- Add config actions to grant permissions to existing roles
- Modify entity displays using config actions
- Reapply recipes and observe idempotent behavior
- Experiment with new content types to understand recipe limitations
By the end of this tutorial, you'll be able to use common config actions in your recipes and understand how recipes behave when reapplied.
The Configuration Actions API is a powerful feature of Drupal recipes that allows you to modify existing configuration without replacing it entirely. While configuration exports let you add new configuration, config actions let you update what's already there—like granting permissions to an existing role or adjusting display settings. Effectively, config actions are a way for a recipe to declare a PHP method to run on a configuration object during recipe application and any arguments that method needs to run.
In this tutorial, we will:
- Understand what config actions are
- Learn how to read and write config actions in a recipe's YAML file
- Explore common patterns like granting permissions and modifying displays
- Understand the difference between generic and type-specific actions
By the end of this tutorial, you'll be able to read config actions in recipes, understand when to use them versus configuration exports, and recognize common config action patterns.
Creating your own recipes lets you package and reuse features across your projects. By building a simple SEO-focused recipe from scratch, you'll learn what goes into a recipe, how to declare dependencies, and how to test your work.
In this tutorial, we will:
- Understand what belongs in a recipe versus what belongs in modules
- Create a recipe structure with proper metadata and dependencies
- Export and package configuration into a recipe
- Test the recipe by applying it to a second site
By the end of this tutorial, you'll be able to create your own recipes, package them properly with dependencies, and apply them to other Drupal sites.