#Drupal Planet

Published in Drupal Core 11.3.0

Drupal 11.3 introduces a new capability for module developers: a method that lets you track changes to state values within the lifecycle of a single HTTP request. This enhancement brings better transparency, logging, and security to operations involving state storage.

In this article, we’ll explore what changed, why it matters, and how you can use it.

✅ What’s New

A new method has been added to the Drupal\Core\State\StateInterface:

Starting in Drupal 11.3.x, validation constraints (Constraint plugins) — which are wrappers around Symfony Validator — are transitioning to a new way of passing parameters: named arguments.
This is part of a broader effort to prepare for Symfony 8, which will be included in Drupal 12.

In this article, we’ll look at what is changing, why it matters, and how you can update your custom constraint plugins safely.

🚀 Introduction

Drupal 11.3.0 brings a powerful update for themers and front-end developers:
themes can now implement hooks using Object-Oriented Programming (OOP) with the #[Hook()] attribute — just like modules have been able to do since Drupal 11.

This means no more long procedural functions in template.php.
Instead, you can organize your logic cleanly in classes inside the theme’s src/Hook directory.

Introduced in Drupal 11.3.0, a new standardized in-memory cache bin called cache.memory replaces the old cache.static bin. This change modernizes how Drupal handles in-memory caching, improves performance, and clarifies the intended use of memory-based caches.

🚀 Overview

The new cache.memory bin is powered by the backend
Drupal\Core\Cache\MemoryCache\MemoryCache.

It provides a lightweight and efficient in-memory cache that:

Drupal 11.3 introduces an important shift for theme and module developers:
the long-standing automatic discovery of template_preprocess_HOOK() functions is now deprecated, along with the file and includes keys in hook_theme().

These patterns have been around since Drupal 7 and worked well in the procedural era. But with modern autoloading and class-based preprocessors, they’re no longer necessary — and now officially discouraged.

In this article, we’ll cover:

Drupal 11.3.0 introduced a long-awaited feature that brings AJAX behavior to a new level — the Views module can now update the browser URL without reloading the page. This is made possible thanks to the new AJAX command SetBrowserUrl.

Why This Matters

Previously, AJAX-powered Views had one major UX issue: after filtering, sorting, or pagination, the page URL remained unchanged. This led to several problems:

Drupal has always been flexible when it comes to plugins, but dependency injection in plugins has historically required boilerplate code. In Drupal 11.3, the PluginBase class introduces a game-changing feature: a generic create() factory method with autowired parameters. This update simplifies plugin development and reduces repetitive code.

Drupal 11.3 introduced a small but powerful enhancement for developers working with HTMX — a new trait called HtmxRequestInfoTrait. This addition dramatically simplifies how we detect and process HTMX requests inside controllers, forms, and services.

In this article, we’ll cover:

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: