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.

As Drupal continues its evolution toward a cleaner, service-oriented architecture, developers must adapt to API changes that improve flexibility and maintainability. One such change in Drupal 11.3.0 is the deprecation of node_type_get_names(), a function long used to retrieve node type labels.

This article walks you through:

With the release of Drupal 11.2.5, a subtle but important change has landed that affects how sites interact with Composer and rsync via the Package Manager. If you’ve been relying on configuration to define executable paths, it’s time to refactor.

🚫 What Changed?

For security reasons, Drupal core has removed the ability to configure paths to Composer and rsync via configuration files. This means: