Published in Drupal 11.3.x

Drupal 11.3 introduces a significant change in how preprocess functions for Views plugins are handled.
Previously, Drupal would implicitly discover functions like template_preprocess_HOOK() and apply them automatically to corresponding templates. This implicit behavior is now deprecated.

Introduced in Drupal 11.3.0

Drupal core continues its modernization journey, and one of the latest updates affects how Views plugins define their template preprocess functions.
If your Views plugin currently uses the theme_file key in its plugin definition — it’s time to update your code.

🔍 What Has Changed

In previous Drupal versions, Views plugins could include a key like this in their plugin annotation:

Drupal is a powerful content management system that separates data from presentation. Two key concepts that make this possible are render arrays and theme hooks. Understanding these is essential for writing clean, maintainable Drupal code.

1. What is a Render Array?

A render array is a structured PHP array that tells Drupal how to render a piece of content. It is processed recursively by the Renderer service (RendererInterface).

Modern web applications are built on the principle of separating business logic (data processing, site rules) from presentation logic (how content is displayed to the user). Drupal strictly follows this principle, while WordPress often mixes these layers. Here are five reasons with concrete examples.

1. Functionality Tied to the Theme

WordPress:

🔹 How to Create a Custom Decorator for Token in Drupal

In Drupal, tokens allow dynamic values to be substituted into text, email templates, fields, and more. There are two main Token classes:

In Drupal 11.3.0, a change landed that modernizes how Views plugins handle their preprocess callbacks. If you are maintaining custom Views plugins or themes, this is important to know.

Background: How It Worked Before

Traditionally, Drupal discovered preprocess functions implicitly.
For example, if you had a Views display plugin with a theme hook called views_display_example, Drupal would look for this function automatically:

In Drupal 11.3.x, the block_content module has dropped the automatic creation of the default Body field (field.storage.block_content.body.yml). This is part of an ongoing effort to reduce assumptions in core and give site builders more control over content architecture.

With the release of Drupal 11.3, a long-standing optimization has been removed from core: the path alias preload cache. This mechanism, introduced in Drupal 6, has officially been deprecated and replaced with a more modern approach.

In this article, we'll explore why the preload cache was removed, what replaced it, and what—if anything—you need to change in your custom or contrib modules.

Drupal 11.3 brings several performance improvements, and one of the most impactful changes is in the Page Cache Middleware. In this article, we’ll explore what has changed, why it matters, and how to update your custom modules and middleware for optimal caching.

What’s Changed?

Previously, whenever a request was processed in Drupal, all middleware and services were constructed, even if the page was already cached. This unnecessary overhead slowed down cached page delivery.

Ah… we all got used to it: opening a view, clicking Advanced, and suddenly diving into a whole world of relationships, contextual filters, and other “special” settings.
For some, it was a ritual — like opening an old book to a favorite page. For others — a minor annoyance, an extra click every time.

With Drupal 11, that little movement is now a thing of the past.