I've been slowly chipping away at a side project that includes a set of related Drupal Recipes. Given the repeatable nature of recipes, I apply them after a clean install frequently, and have a shell script that automates this process.
After some recent changes I found that one of my recipes was not applying cleanly. In an effort to debug, I ran the drush recipe command with the -v flag to get verbose output. Debugging aside, I found the output to be really useful.
Here's what I'd see when applying the sanctuary_graphql recipe without the verbose flag:
ddev drush recipe recipes/sanctuary_graphql
12/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░]
Installed Simple OAuth & OpenID Connect module.
25/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓]
Applied Sanctuary GraphQL recipe.
[OK] Sanctuary GraphQL applied successfully
and this is the output with the -v flag:
ddev drush recipe recipes/sanctuary_graphql -v
[info] Drush bootstrap phase: bootstrapDrupalRoot()
[info] Change working directory to /var/www/html/web
[info] Initialized Drupal 10.4.1 root directory at /var/www/html/web
[info] Drush bootstrap phase: bootstrapDrupalSite()
[info] Initialized Drupal site sanctuary.ddev.site at sites/default
[info] Drush bootstrap phase: bootstrapDrupalConfiguration()
[info] Drush bootstrap phase: bootstrapDrupalDatabase()
[info] Successfully connected to the Drupal database.
[info] Drush bootstrap phase: bootstrapDrupalFull()
0/25 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
Applying recipe
[info] decoupled_preview_iframe module installed.
3/25 [▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░]
Installed Config Pages module.
5/25 [▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░]
Installed Paragraphs module.
[info] paragraphs_edit module installed.
8/25 [▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░]
Installed Sanctuary module.
10/25 [▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░]
Installed Iconify Icons module.
[info] menu_item_extras module installed.
[info] simple_oauth module installed.
13/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░]
15/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░]
Installed Typed Data module.
[info] graphql module installed.
18/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░]
Installed Sanctuary GraphQL module.
20/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░]
Installed GraphQL Compose: Routes module.
[info] graphql_compose_menus module installed.
25/25 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓]
Applied Sanctuary GraphQL recipe.
Modules installed
-----------------
* Config Pages
* Consumers
* Decoupled Preview Iframe
* Entity Reference Revisions
* Frontend Editing
* GraphQL
* GraphQL Compose
* GraphQL Compose: Edges
* GraphQL Compose: Menus
* GraphQL Compose: Preview
* GraphQL Compose: Routes
* Iconify Icons
* Menu Item Extras
* Paragraphs
* Paragraphs Edit
* Sanctuary
* Sanctuary GraphQL
* Serialization
* Simple OAuth & OpenID Connect
* Token
* Typed Data
Recipes applied
---------------
* Sanctuary Core
* Sanctuary GraphQL
[OK] Sanctuary GraphQL applied successfully
This is verbose (as advertised) but pretty essential information, especially if you're applying a recipe for the first time. Without -v all we really know is that the recipe was applied successfully. With -v we get a list of all of the modules installed, and also see that another recipe was applied as a dependency.
I'd often find myself either reviewing the source code of a recipe, or skimming the module page in the admin UI to understand what was actually included. This verbose output is a much quicker way to get that info.
From what I can tell, -v and -vv provide the same output. -vvv is more verbose, but I haven't found the extra info super useful as of yet. None of these options seem to provide debug output for config actions, which is the only thing I could see as a useful addition.
I realize that 'try running it with debug output' is hardly a groundbreaking tip, but in the case of recipes this additional info is really handy. Going forward, I'll be using -v by default when applying new recipes so that I can get a better sense of what's being added to my site.
In the above video, we’ll explore how to use Bootstrap for Drupal CMS.
If you’re looking for easier site-building and front-end theming, Bootstrap is a great tool.
We’ll cover everything from setting up your themes to using Bootstrap within Drupal’s Layout Builder and Views.
Bootstrap is well-supported within the Drupal community. It offers numerous modules and themes, as well as many pre-built components that help developers create attractive, responsive sites quickly.
We’ll specifically look at two themes: Bootstrap5 and Radix. We will also explore how to integrate Bootstrap with Drupal’s Layout Builder using Bootstrap Layout Builder and how to use Bootstrap grids within Drupal Views.
At Freelock, we're starting to use Nix to manage different PHP environments, and be able to incrementally update websites.
Dev Corner Read MoreMy name is David Bekker (a.k.a. daffie), and I’m a seasoned Drupal core contributor with over 600 commit credits. I maintain Drupal’s Database API and database driver modules. My passion lies in open-source development, driven by a desire to create maximum business value.
When I sought a high-impact project to work on, I chose to develop a MongoDB driver for Drupal. One that stores entity instances as JSON objects. This project addresses Drupal’s evolving needs in a meaningful way.
To understand why this shift is crucial, let's compare this transition to a challenge Drupal faced years ago: optimizing sites for mobile devices. Back then, significant changes were needed to enhance mobile usability. Now, we face a similar paradigm shift as the market evolves from sites for anonymous users to those centered on authenticated users. Drupal must adapt, and Drupal on MongoDB is the key to this transformation.
Beyond traditional use cases, Drupal on MongoDB is also ideal as a backend for iOS, Android, and JavaScript applications, providing personalized and scalable solutions.
Drupal on MongoDB is more than just a new database option. It enhances Drupal’s ability to compete in a changing digital landscape.
Drupal’s robust entity system provides a solid foundation where everything is structured as an entity. Traditionally, Drupal leverages relational databases like MySQL or MariaDB, efficiently managing data across multiple tables. This approach performs well for sites with a large number of anonymous users. However, for sites with many authenticated users, the complexity of retrieving entity data from multiple tables can introduce performance challenges. Optimizing data retrieval can significantly enhance the user experience, making Drupal even more powerful for dynamic, user-centric applications.
With MongoDB, every Drupal entity instance is stored as a single JSON object, including all revisions, translations, and field data. This streamlined data structure allows for significantly faster retrieval, making Drupal a stronger solution for personalized, user-focused experiences.
As the market shifts toward authentication-driven sites, supporting MongoDB ensures that Drupal remains a competitive and scalable option. Rather than replacing Drupal’s strengths, this integration enhances them, allowing Drupal to meet modern performance demands while maintaining its flexibility and power.
The scalability of NoSQL databases like MongoDB sets them apart from traditional relational databases such as MySQL or MariaDB. While relational databases typically rely on a single-server model, MongoDB supports horizontal scaling, enabling distributed setups with thousands of servers acting as a unified database. This architecture provides the performance needed for large-scale projects with millions of authenticated users.
As community-driven software, Drupal is built to support interactive, user-focused experiences, including forums, profiles, and content management. Traditionally, its relational model organizes data across multiple tables—similar to storing the chapters of a book separately in a library. This approach ensures data consistency and flexibility, making it highly effective for managing structured content.
However, as the demand for authentication-heavy sites grows, the way data is stored becomes a crucial factor in performance. MongoDB offers a more efficient alternative by storing entire entities as JSON objects—just like keeping an entire book intact rather than splitting it into separate chapters across different locations. This eliminates the need for complex table joins, significantly accelerating data retrieval and making MongoDB well suited for personalized dashboards and dynamic content feeds.
For small-scale sites, both relational and NoSQL approaches work. But when scalability, speed, and efficiency become priorities—particularly for sites with millions of authenticated users—MongoDB provides a natural and powerful solution for taking Drupal to the next level.
{
_id: ObjectId('664afdd4a3a001e71e0b49c7'),
uid: 1,
uuid: '841149cd-fe56-47c4-a112-6d23f561332f',
langcode: 'en',
user_translations: [ {
uid: 1,
uuid: '841149cd-fe56-47c4-a112-6d23f561332f',
langcode: 'en',
preferred_langcode: 'en',
name: 'root',
pass: '$2y$10$kjGuIsPOTDa2TseuWMFGS.veLzH/khl0SfsuZNAeRPRtABgfq5GSC',
mail: 'admin@example.com',
timezone: 'Europe/Amsterdam',
status: true,
created: ISODate('2024-05-20T07:37:54.000Z'),
changed: ISODate('2024-05-20T07:42:08.000Z'),
access: ISODate('2024-05-20T08:46:47.000Z'),
login: ISODate('2024-05-20T07:44:16.000Z'),
init: 'admin@example.com',
default_langcode: true,
user_translations__roles: [ {
bundle: 'user',
deleted: false,
langcode: 'en',
entity_id: 1,
revision_id: 1,
delta: 0,
roles_target_id: 'administrator'
} ]
} ],
login: ISODate('2024-05-20T07:44:16.000Z'),
access: ISODate('2024-05-20T08:46:47.000Z')
}Switching to MongoDB alone is not enough to make Drupal a top-tier solution for sites with a high number of authenticated users. Developers must rethink how data is stored.
In traditional Drupal setups optimized for anonymous users, caching mechanisms like Redis compensate for slow database queries. However, for authenticated users, where content is dynamic and personalized, this approach falls short. Drupal itself needs to be fast, not just its caching layer.
MongoDB enables developers to store data in the way the application uses it, reducing the need for complex queries that slow down performance. Instead of relying on costly operations like joins and subqueries, simple and efficient queries should be the norm. Tools like materialized views—precomputed query results stored as database tables—help achieve this, ensuring faster data retrieval while keeping the database structured for high performance.
While many databases support JSON storage, MongoDB is the only one that fully meets Drupal’s needs. Its capabilities extend beyond basic JSON support, making it the optimal choice for storing entity instances efficiently.
Additionally, MongoDB offers several key advantages that align with Drupal’s evolving requirements:
Performance tests comparing MariaDB and MongoDB for loading Drupal nodes show a significant advantage for MongoDB:
Tests were conducted on 50K nodes with identical field structures. Even without specific optimizations, MongoDB outperformed MariaDB, demonstrating its potential to enhance Drupal’s speed and scalability.
As the web moves toward more personalized, user-centric experiences, Drupal must evolve to remain competitive. MongoDB is a key enabler of this evolution, providing faster, more scalable solutions for authenticated user-heavy sites.
By embracing MongoDB, Drupal developers can unlock new performance possibilities, simplify infrastructure, and build future-ready web applications.
Want to get involved? Join the conversation in the Drupal community via Slack in the #mongodb and #contribute channels. Let’s shape the future of Drupal together! 🚀
With the release of Drupal 11.1, there’s a cool new feature for developers: Hooks can now be implemented as class methods using PHP attributes instead of functions. This change is a major step forward in modernizing Drupal’s codebase. While procedural function-based hooks are still supported (and will be for some time), developers writing new code should strongly consider using the object-oriented (OOP) approach introduced in Drupal 11.1.
One of our core commitments at Drupalize.Me is ensuring that our tutorials remain accurate and relevant as Drupal evolves. So we’re working on updating all of our tutorials to take into account the new OOP approach to adding hooks in a module. We’re also aware that procedural hooks have been around for 24 years, and aren’t going to disappear overnight. You’ll see them in example code and existing documentation for a long time to come. So for now we’ll be including both approaches in our content whenever doing so makes sense.
You should plan on learning both approaches, and then using the one that makes the most sense given your specific case.
Continue reading to learn a bit about the evolution of hooks in Drupal core and how to implement hooks as classes in Drupal 11 in this latest Drupalize.Me blog post by Joe Shindelar.
joe Fri, 01/31/2025 - 18:25After a 105-day hiatus — because I became a dad ☺️ — time to catch up! It’s the last day of January and I’m writing about week 22, while in week 34! I intend to catch up by the end of February and that of course happens to be week 42. 😜 🤓
Most of you will probably wonder why I’d even bother catching up. Well, many of you told me you’ve found these posts invaluable to have a sense of where Experience Builder (XB) is going, of the progress we’re making, and to know when we’re working on things where your expertise might be especially valuable. Plus, it’s helpful for me to have a complete overview as the XB tech lead of what everything is that happened (impossible to be fully caught up during paternity leave), and ensure loose ends are tied up. 1
The weeks further in the past I’ll make more summary-like with less detail. As I get closer to catching up to the present, I’ll bring back more detail, as I’ve done in the past. Here we go! 🚀
We all love a good Bálint “balintbrews” Kléri-made GIF, don’t we? 😁 See how he evolved the “add” menu in #3477372 based on the updated design:
Clicking the ‘add’ button now displays a popover listing available components. Much snazzier than 3 weeks prior!But by far most importantly, Harumi “hooromoo” Jang, Bálint and Jesse Baker landed a massive usability improvement for the so-called “Layers” dragging components around: dragging into empty slots was impossible before, some affordances were missing, and while it worked, it was a bit jumpy. Not anymore:
Making changes to the overall structure (hierarchy) is now more capable and easier to use. Harumi followed up on their prior “layers” panel work — note how while dragging-and-hoverin to pick a spot, the existing component instances don’t jump around anymore.Missed a prior week? See all posts tagged Experience Builder.
Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!
For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!
Not at all visual but nonetheless important:
Week 22 was October 7–October 13, 2024.
I was working at ~30% capacity for most of my paternity leave to not be fully out of the loop, and to make my paternity leave last longer. (Thanks, Acquia! 🙏😊) The intent was for me to keep up this blog post series during that time. But that didn’t work out: reviews required all of that time!
Upgrading Drupal to a newer version ensures your website remains modern, secure, and efficient. For Drupal 8 users, upgrading to a higher major version, such as Drupal 9 or 10, is significantly easier than for older versions, thanks to the improved upgrade process. However, an update isn’t just clicking a button – it requires proper preparation to avoid technical issues and ensure uninterrupted website operations. In this article, we explain the differences between an upgrade and a migration and highlight key points to consider when upgrading Drupal 8 to newer versions.