Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Views is the right tool for most listings; custom queries are for genuine aggregation.
- Read the generated SQL — the preview tells you what the page will really cost.
- Use tag-based caching so listings invalidate on content change, not on a timer.
- Move to a search index once you need facets or relevance ranking.
What Views is good at
Views turns a listing requirement into configuration rather than code, which means it deploys with your configuration and can be adjusted without a release. For the large majority of listings — news, team members, filtered catalogues — it is the correct tool.
The cases where it is not are complex aggregations across many entity types, or listings that need to combine Drupal data with an external source. Those are better served by a custom controller with an explicit query.
Where the performance goes
- Rendering entities in full when a teaser or a set of fields would do.
- No pager, or a pager with an unbounded item count.
- Filters on unindexed fields, which turn into slow table scans.
- Relationships stacked several deep, producing large joins.
Use the Views SQL preview to read the generated query. If it looks alarming, it is.
Caching a view properly
Views has its own cache settings, and tag-based caching is almost always the right choice: the view invalidates when the underlying content changes rather than on a timer. Time-based caching is a blunt instrument that produces either stale listings or no benefit.
If a view includes user-specific elements, split it so the cacheable part stays cacheable rather than making the whole listing uncacheable.
When to reach for a search index
Once a listing needs faceted filtering, relevance ranking or full-text search across many fields, the database stops being the right engine. Search API with a dedicated backend handles this properly and keeps the site responsive as content grows.
Making views maintainable
Views are configuration, which means they deploy and they can be reviewed. That advantage disappears when a site accumulates forty views with names like content_2 and no indication of where each is used.
Name views for their purpose and record the placement in the description field. When a view is superseded, delete it rather than disabling it — a disabled view is an invitation for someone to re-enable it in two years without understanding why it was turned off.
Where several views differ only by a filter value, use a contextual filter and one view instead. This is the single most effective way to stop the view count growing without limit, and it keeps display changes in one place.
Frequently asked questions
For a typical listing, no the query Views generates is usually reasonable, and the flexibility is worth a great deal. It becomes slower when it is asked to do something it is not suited to, such as deep multi-entity aggregation, which is where a purpose-built query belongs.
Fields are cheaper when you need a handful of values, because Drupal does not have to build a full render array per item. Entity rendering in teaser mode is more maintainable when the display is genuinely a card that should follow the display settings.
Use a standard pager with a sensible page size and ensure the sort field is indexed. Very large offsets are expensive in any database, so for archives running to many thousands of items, filtering by date or category is a better pattern than deep pagination.
