I have been at this for two decades now, yet I still don't identify as a blogger. It feels awkward to say the words: I am a blogger.
Probably because I started writing to think out loud. I never set out to be a blogger. And honestly, I still feel like I'm figuring the whole thing out.
My history with blogging actually goes back 25 years. Before this site, I started Drop.org, where I shared ideas and experimented with emerging web technologies. Drop.org eventually led me to create Drupal. Drupal 1.0 even included a feature called "public diaries". We didn't call it "blogging" back then, but that is what it was.
The irony was that Drupal was powering personal blogs around the world, while my own site was still a few static HTML files.
At DrupalCon Amsterdam in 2005, Steven Wittens called me out on it. Steven was the number two in Drupal at the time. He proposed a bet: if I did not launch a Drupal-powered site before January 1, 2006, I would owe him a Duvel. If I did, he would owe me one.
I wrote my first post on December 31, 2005 with less than a day to spare. I don't remember if I ever collected that Duvel, but I haven't stopped writing.
In the early years, I would post short thoughts on a whim. Social media did not exist yet, so there was almost nothing between a thought and my Publish button. Today, those quick thoughts often end up on social media instead, although I have mostly stepped away from it. More people read what I write now, so a new post can take me hours instead of minutes.
I removed analytics from my site long ago. I do not want to write for page views, nor do I want to invade your privacy. My site aspires to the privacy of a physical book.
I write to discover and connect with people. But one thing has never changed: I am a terrible judge of what will connect. The posts I polish the longest often get little attention, while the ones I nearly talk myself out of publishing are the ones people share. I have stopped trying to explain this, but it reminds me that I do not get to decide what matters to others. Maybe the polishing takes something away. Maybe the risky ones carry an honesty that others can feel.
I love that writing in public has a way of keeping you honest. Ideas that seem solid in my head can fall apart the moment I try to explain them. I have changed my mind more than once simply by trying to put my thoughts into words.
But the writing is only half of it. The best part happens after you press publish.
Blogging starts conversations with people I have never met. Blog posts become invitations that never expire. They wait patiently for the right moment to be found. Someone reads an old post, reaches out, and suddenly we are talking. Even in person, conversations start more easily because people already have a sense of who I am or what I care about.
My attention to this blog has gone up and down over the years. Work pulled me away. Travel pulled me away. But I always come back. Writing in public gives me something I do not get anywhere else.
It is strange to think this all traces back to that Duvel bet. My site still runs Drupal of course, which must make it one of the oldest Drupal-powered sites.
Some of you have been reading since the beginning. Many found your way here much later. I am grateful for all of you. Thank you for making this feel like a conversation instead of a monologue.
I plan to keep writing here as long as I can. If you have been reading for a while, I would love to hear from you. Even a simple hello means a lot.
Vivint uses Salesforce's Agentforce to send satisfaction surveys after customer service calls. Recently they discovered surveys were randomly not being sent and no one noticed for weeks.
When Salesforce investigated this problem, they found the root cause: their AI agents were skipping steps. A sobering discovery for a company betting its future on those agents.
What is most telling is how Salesforce is responding. They are not rushing to build smarter AI models. They added more structure and guardrails around the agents. More workflow, not more magic.
And that is the right answer. I actually wrote about this months ago in The Orchestration Shift:
The future will likely require both: deterministic workflows for reliability and consistency, combined with AI-driven decision-making for flexibility and intelligence.
Salesforce learned it the hard way.
This is exactly why I've been paying attention to external workflow automation platforms like n8n and Activepieces. They let you control which steps are deterministic and which steps use AI. Internal automation solutions like Drupal's Event-Condition-Action module work on similar principles.
Using Activepieces or n8n, the Vivint workflow would look like this: the customer service call ends, AI analyzes the transcript and personalizes the survey message, then the automation platform sends the email. The AI does what it is good at and the automation platform ensures the send happens every time.
Which brings us to the first big question: is AI's reliability problem temporary or permanent? If it is only temporary, orchestration tools may be a bridge solution. But if reliability limits are inherent, workflows become essential infrastructure. I believe the latter.
LLMs are probabilistic by design, which means everything that can be deterministic probably should be.
Two architectural approaches are emerging for solving this problem.
The first is outside in. Workflow platforms like n8n or Activepieces put a deterministic process in control and use AI for specific steps within it. The workflow decides when to invoke the AI, what to do with its output, and what happens if it fails. Outside in is more reliable and auditable. If the AI fails or returns something unexpected, the workflow catches it. You can see exactly what happened and why. But it is less flexible because you are limited to what the workflow designer anticipated.
The second approach is inside out. AI agents call deterministic tools as part of their operation. The AI is in control, but when it needs to do something that requires precision, it hands that task to a tool that executes reliably. This is what Anthropic's Claude Code does, for example. When Claude Code needs to verify that code compiles, it does not guess. It calls an actual compiler. Inside out is more adaptive. You describe what you want and the AI figures out how. But it is harder to audit and debug, harder to explain to regulators, and more expensive at scale since the AI is invoked at every step.
It feels intuitive that both approaches will coexist. They are nested. Picture three layers. The outer layer is the enterprise workflow. It decides what happens and in what order. The middle layer is an AI step. It makes judgment calls within each step. The inner layer is deterministic tools. They execute precisely when the AI calls them.
Not everyone needs all three layers. For certain tasks, like writing software, inside out is enough. But for complex enterprise workflows with many steps, integrations, business rules, and audit requirements, you need the outer layer.
That is where workflow automation platforms come in. They do not need to power every AI use case. They need to win the complex workflows where enterprises need visibility and control. That is also where a lot of commercial value will accrue. Enterprises pay for reliability and accountability.
We are still early in the age of AI agents. The temptation is to believe that intelligence alone will replace structure. But enterprises cannot gamble processes that touch customers, revenue, or compliance. They need systems where every step is accountable. That is why non-deterministic workflows matter. It is where reliability and intelligence meet and where the next generation of enterprise platforms will be built.
And when infrastructure becomes essential, organizations want to own it, not rent it. That is why Linux won servers and PostgreSQL won databases. If the orchestration layer becomes essential to enterprise AI, open source will be the natural choice. Activepieces is open source and n8n is "source available" (the code can be inspected but has commercial restrictions). Either way, I would love to see them succeed.
Indexing document content in Drupal enables users to search within PDF and Word files, making document libraries more accessible and discoverable. Search API Attachments combined with Apache Solr provides a powerful solution for extracting and indexing text from uploaded documents.
In the video above, you'll learn how to set up document thumbnails for PDFs and Word files, install and configure Search API with Search API Attachments, set up Apache Solr locally using DDEV, configure Solr's built-in extractor for document content, and create search views with faceted filtering.
Want to see your web page content in rich results? Read this blog to learn all you need to know about applying Schema Markup or structured data. Additionally, find out how it can affect your SEO during a migration.
Today we are talking about Webhaven.io, What it is, and How it helps build Drupal faster with guest Fons Vandamme. We'll also cover Metatag Simple Widget as our module of the week.
How old: created in Jul 2025 by Jim Vomero (njim) of Four Kitchens
Versions available: 1.0.0 and 1.1.0, the latter of which works with Drupal core 10 and 11
Maintainership
Actively maintained
Security coverage
No open issues
Usage stats:
1 site
Module features and usage
With this module installed, in the form configuration for your content types, you'll see a new "Simplified meta tags form" widget for metatag fields
It's designed to provide a dramatically streamlined input for metatags, focused on only exposing the most commonly used tags, the title and description
As a configuration option, you can have the widget hide default values, which for metatag fields often contain tokens, which could be confusing for Drupal neophytes
The module was nominated by Dave Hansen-Lange (dalin), also of Four Kitchens, and a co-maintainer, as well as a fellow Canadian
I also wanted to give a shout out to the Drupal.org Infrastructure Working Group. In the lead-up to this recording there was a media server failure that brought down the entire site. They worked as furiously as Santa's elves and were able to quickly get the site back up. It was a reminder for me of how much we all (and this segment in particular) depend on the tireless work they do. In this season of giving please consider supporting the Drupal Association, and if you already do, maybe see if you could give a little more.
This issue marks the conclusion of Volume 3 of Editor's Pick and the final newsletter of the year. As we close 2025, we would like to express our sincere appreciation to everyone who has followed The DropTimes, engaged with our work, and trusted us as a source of record for the Drupal ecosystem.
Over the past year, The DropTimes has continued its effort to document Drupal as more than a technology. Through news, interviews, events, case studies, and curated updates, we have focused on capturing the people, contributions, and decisions that collectively shape the community. Our work is guided by the belief that visibility, continuity, and context are essential for any open-source ecosystem to remain healthy and sustainable.
As a not-for-profit, community-driven initiative, our responsibility goes beyond publishing content. We see The DropTimes as part of the ecosystem it covers, with a duty to support makers, amplify meaningful work, and encourage shared responsibility. This perspective informs our editorial choices and reinforces our commitment to independence, fairness, and long-term relevance.
In 2026, we will continue to build on this foundation with sharper editorial focus, improved processes, and deeper engagement with the community we serve. Your feedback plays an important role in shaping this work, and we welcome your thoughts at editor@thedroptimes.com
Thank you for being part of this journey, and we look forward to continuing it with renewed purpose in the year ahead. With that, for one last time in 2025, let's spotlight the key stories form last week.
We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now. To get timely updates, follow us on LinkedIn, Twitter, Bluesky, and Facebook. You can also join us on Drupal Slack at #thedroptimes.
We've developed a huge platform for over half a decade to host the official sites of the United Nations' member countries, and we've never really posted about it. It's 170 Microsites, built on top of a single code base and database. Having the word "Micro" before Microsites is really stretching the definition. There's nothing micro about them. Head over to your favorite UN member country to see it in action. Here are a few completely random ones:
Democratic People's Republic of Korea
People's Democratic Republic of Algeria
Republic of the Congo (Not to be confused with "Democratic Republic of the Congo").
This post is a reflection of why we always try to avoid such architecture, and why we almost always still end up going with that level of effort; how much it should cost (less than having 140 independent sites); the common pitfalls we've gathered over the years (many).
What are Microsites
Microsites are sites that share the same structure and purpose, usually under one organization, but are meant to serve different branches, offices, or audiences. They can have their own content, languages, and editors, and sometimes even a different look. In a setup like the UN's, each country office site is technically similar, but each is managed by a different local team, with its own priorities and style. They're independent enough to feel separate, yet still connected through a shared foundation.
The term "microsite" is misleading. Once you have hundreds of them, each with custom permissions, content, and translations, there's nothing "micro" left about it. It's a big system pretending to be many small ones.
The Options - From Worse To Bad
None of these options are easy. Microsites are the kind of problem where every path feels wrong; you just choose which pain you can live with.
On October 5, 2023, the W3C published WCAG 2.2 as an official web standard. While WCAG 2.1 remains valid and widely referenced, WCAG 2.2 introduces nine new success criteria and removes one obsolete requirement. These changes reflect a deeper understanding of mobile accessibility, cognitive disabilities, and focus management.
Drupal-blue LEDs, controllable through a REST API and a Drupal website. Photo by Phil Norton.
It's Christmas Eve, and Phil Norton is controlling his Christmas lights with Drupal. You can visit his site, pick a color, and across the room, a strip of LEDs changes to match. That feels extra magical on Christmas Eve.
I like how straightforward his implementation is. A Drupal form stores the color value using the State API, a REST endpoint exposes that data as JSON, and MicroPython running on a Pimoroni Plasma board polls the endpoint and updates the LEDs.
I also didn't realize you could buy light strips where each LED can be controlled individually. That alone makes me want to up my Christmas game next year.
But addressable LEDs are useful for more than holiday decorations. You could show how many people are on your site, light up a build as it moves through your CI/CD pipeline, flash on failed logins, or visualize the number of warnings in your Drupal logs. This quickly stops being a holiday decoration and starts looking like a tax-deductible business expense.
Beyond the fun factor, Phil's tutorial does real teaching. It uses Drupal features many of us barely think about anymore: the State API, REST resources, flood protection, even the built-in HTML color field. It's not just a clever demo, but also a solid tutorial.
The Drupal community gets stronger when people share work this clearly and generously. If you've been curious about IoT, this is a great entry point.
Merry Christmas to those celebrating. Go build something that blinks. May your deployments be smooth and your Drupal-powered Christmas lights shine bright.
Advent Calendar day 24 - Listening Like a Dungeon Guidejames
It's Christmas eve, and time to open our final Advent Calendar door. What better way to relax before the holiday festivities than by playing some tabletop games for all the family? Maybe a role playing game like Dungeons and Dragons as suggested by AmyJune!
Listening Like a Dungeon Guide
RPG Skills for Stakeholder Work
At DrupalCamp Colorado 2025, I caught a session by Eric Davila titled Listening Like a Dungeon Master: Leveraging RPG Skills for Stakeholder Magic. The talk explored an idea that feels especially relevant to Drupal projects of all sizes: successful collaboration depends far more on…
You're tabbing through a form, reading field labels before you decide what to enter. You tab into a dropdown menu just to see what options are available. The instant it receives focus - before you've even opened it - the page suddenly redirects to a completely different page. You didn't select anything, didn't press Enter, just tabbed through. Now you're disoriented and have to navigate back to find your place.
Lee Robinson, who works at Vercel, spent $260 in AI coding agent fees to migrate Cursor's marketing site away from Sanity, their headless CMS, to Markdown files. That number should unsettle anyone who builds or sells content management systems for a living. His reasoning: "With AI and coding agents, the cost of an abstraction has never been higher". He argued that a CMS gets in the way of AI coding agents.
Knut Melvær, who works at Sanity, the very CMS Lee abandoned, wrote a rebuttal worth reading. He pointed out that Lee hadn't actually escaped the complexity of a CMS. Lee still ended up with content models, version control, and user permissions. He just moved them out of the CMS and distributed them across GitHub, Vercel, and custom scripts. That reframing is hard to unsee.
Meanwhile, the broader momentum is undeniable. Lovable, the AI-first website builder, went from zero to $200 million in annual recurring revenue in twelve months. Users prompt what they want and Lovable generates complete, production-ready applications.
Ask me again in two years, but today's Lovable is not a CMS replacement. So the real question isn't whether CMSes are becoming obsolete. It's who they're for.
Historically, the visible layer of a CMS, the page builders and content creation workflows, is where most people spend their time. But the invisible layer is what makes organizations trust the system: structured content models, permission systems, audit trails, web service APIs, caching layers, translation workflows, design systems, component libraries, regulatory compliance and more. A useful way to think about a CMS is that roughly 30 percent is visible layer and 70 percent is invisible layer.
For more than twenty years, the visible layer was where the work started. You started from a blank state - a page builder or a content form - then wrote the headline, picked an image, and arranged the layout. The visible layer was like the production floor.
AI changes this dynamic fundamentally. You can now prompt a landing page into existence in under a minute, or generate ten variations and pick the best one. The heavy lifting of content creation is moving to AI.
But AI gets you most of the way, not all the way. The headline is close but not quite right, or there is a claim buried in paragraph three that is technically wrong. Someone still needs to review, adjust, and approve the result.
So the visible layer still matters, but it serves a different purpose. It's where humans set direction at the start and refine the result at the end. AI handles everything in between.
A page builder becomes a refinement tool rather than a production tool. You still need the full UI because someone has to review, adjust, and approve what AI generates. You can try to prompt all the way to the finish line, but for the last mile, many people will still prefer a UI.
What happens to the invisible layer? Its job shifts from "content management" to "context management". It provides what AI needs to do the job right: brand rules, compliance constraints, content relationships, approval workflows. The system becomes more powerful while requiring less manual configuration.
So my base case for the future of CMS is simple: AI handles eighty percent of the work. Humans handle the remaining twenty by setting direction at the start, and refining, approving, and taking responsibility at the end.
This is why Drupal is not standing still. We recently launched Drupal Canvas 1.0 and one of its top priorities for 2026 is maturing AI-driven page generation. As that work progresses, Canvas could become AI-first by default. Watching it come together has been one of the most exciting things I've worked on in years. We're far from done, but the direction feels right.
Lee proved that a skilled developer with AI coding agents can rebuild a marketing site in a weekend for $260. That is genuinely remarkable. But it doesn't prove that every organization will abandon their CMS.
CMSes have to evolve. They have to become a reliable foundation that both humans and AI agents can build on together. The visible layer shifts from where you create to where you refine. The invisible layer does more work but doesn't disappear. Someone still has to direct the system and answer for it when things go wrong.
Drupal's Views module is wonderful for listing content, but what should you show when you have nothing to list? Everybody loses if a journey ends there: your visitor has to start again, and you've missed an opportunity to help them. The likes of Amazon and eBay show alternative results after more precise matches for a search, even if there are some results. Limited results mean a limited chance for your visitor to find what they want, so providing alternative suggestions increases your chance to convert them to satisfied guests.
When search terms on eBay don't produce many exact matches, partial matches are shown to entice users towards relevant products.
Out of the box, you can configure what to show when Drupal can't find any results (sometimes known as the 'empty text') :
Even more usefully, you can include a views listing in this - perhaps to list alternative results with fewer active filters, to maximise the chances of showing visitors something relevant to them:
So far, so good
But I wanted to take this an extra step, to show this alternative set of results, even when the initial view has results, but not enough of them. This required two key changes with custom code, because Drupal will only build and print whatever is configured for the 'No results behaviour' when there really are no results. (Thanks, Captain Obvious! 🫡)
Override the views-view.html.twig template to replace an elseif with distinct if blocks as follows:
Before the change, this has an elseif so when there are any results, the empty text can never show:
After - with two distinct simple if blocks, so both can be output together:
{% if rows -%}
{{ rows }}
{% endif %}
{% if empty -%}
{{ empty }}
{% endif %}
A post-render hook to build the output of that 'No results behaviour' when there are results, but fewer than a desired amount:
/**
* Implements hook_views_post_render().
*/
function MYMODULE_views_post_render(\Drupal\views\ViewExecutableViewExecutable $view, array &$output, \Drupal\views\Plugin\views\cache\CachePluginBase $cache) {
// Add a pre-render that will render the empty area if there are 1-3 results.
if (
$view->id() === 'MY_VIEW_ID' // e.g. 'products'
&& $view->current_display === 'MY_DISPLAY' // e.g. 'page_1'
&& !empty($view->result)
&& count($view->result) <= 6 // Threshold below which to show empty text.
) {
$output['#pre_render'][] = function ($element) {
/** @var \Drupal\views\ViewExecutable $view */
$view = $element['#view'];
// Store this instance, so that the fallback display's equivalent will be
// able to get at what was in the results, to avoid duplicating them.
// @see MYMODULE_views_pre_view()
views_set_current_view($view);
// Build the configured 'No results behaviour'.
$element['#empty'] = $view->display_handler->renderArea('empty', FALSE);
return $element;
};
}
}
This could be in a custom module or theme. I went for building the configured 'No results behaviour', but you could embed something different if, for example, you wanted to show different text for whether there were only a few results, or none at all.
Techy aside: The call toviews_set_current_view()in the code above follows a similar approach to how Attachment displays are aware of their parent display. When views begins executing the display of alternative results, the statically-stored 'current view' is added to an array stack at$view->old_view. We'll make use of that below in the 'Going further' section.
Now when a visitor makes a search on your site but doesn't get anything they like the look of, you present them with potential alternatives. I suggest including some simple text above the alternative suggestions to explain what they are (rather than exact matches for the original search), as demonstrated in the eBay screenshot above. This could just be the first thing set in the 'No results behaviour' of the view, before adding the alternative views display:
Show the right things, and everybody wins! 🏆
We used this idea on a learning platform where users can find content relevant to them. There are only so many lessons available, so to keep visitors engaged it's important to show useful suggestions that didn't match their keywords. The explanatory text in the 'No results behaviour' clarifies which items directly fit the search, and which are extras:
Going further
An optional extension to this idea is to deliberately exclude any results that did come back in the original set. Use a contextual filter (argument) on your view for excluding IDs and a hook_views_pre_view() to act on the alternative results views display. The contextual filter needs to be for the content IDs (or IDs of whatever kind of entity your original list is for), and have both checkboxes in the 'More' section ticked so that it excludes results.
Then the hook_views_pre_view() takes the results from the original ('parent') view and populates that contextual filter with them, so that they can't show up twice. Note that this can only go in a module, not your theme:
/**
* Implements hook_views_pre_view().
*/
function MYMODULE_views_pre_view(\Drupal\views\ViewExecutable $view, $display_id, array &$args) {
if (
$view->id() === 'MY_VIEW_ID'
&& $display_id === 'MY_ALTERNATIVE_DISPLAY' // e.g. 'embed_1'
) {
// Parent view was set by MYMODULE_views_post_render() so that we can
// ensure to exclude any results in the original set, from this fallback.
$parent = end($view->old_view);
if (
$parent
&& $parent->id() === 'MY_VIEW_ID' // e.g. 'products'
&& $parent->current_display === 'MY_DISPLAY' // e.g. 'page_1'
&& !empty($parent->result)
) {
$view->setArguments([
// The 'nid' key should be whatever property identifies results uniquely.
implode('+', array_column($parent->result, 'nid'))
]);
}
}
}
Finally, you might want to check that your alternative display won't just inherit the same exposed filters as your parent display. Tinker with what fits your scenario: perhaps remove some filters entirely, or change their filter identifiers so that they don't get populated from the query string parameters used by the parent display?
This idea probably fits into Dries Buytaert's recently-suggested category of 'Adaptable modules' as it isn't easily generalized. What makes for good alternatives to suggest, and the right empty text configuration, is unique to your situation. But consider this idea a starting point!
Implementing powerful search functionality in Drupal requires more than the default search module. Search API provides flexible search capabilities with support for multiple backends, faceted filtering, and advanced content indexing.
In the video above, you'll learn how to install and configure Search API, create search indexes with custom processors, display search results using Views, implement faceted filtering, and integrate Apache Solr using DDEV for enhanced search.
Advent Calendar day 23 - No more steep learning curve!james
It's the penultimate door of our Advent Calendar, and today we are looking at efforts to make Drupal easier and more intuitive for new users. Emma Horrell - who in addition to her User Experience Manager role the University of Edinburgh, is also UX manager for Drupal Core, and UX research lead for Drupal CMS - explains how UX research is central to Drupal CMS's mission of flattening Drupal's traditionally steep learning curve.
No more steep learning curve! How UX research is making a more user-centric Drupal CMS
Emma outlines how UX in Drupal has evolved from ad-hoc contributions to formalized…
Curious about what makes a CMS migration successful? No, it isn't limited to the transition. Read this blog to learn about ongoing support post-migration.
At DrupalCamp Colorado 2025, I caught a session by Eric Davila titled Listening Like a Dungeon Master: Leveraging RPG Skills for Stakeholder Magic. The talk explored an idea that feels especially relevant to Drupal projects of all sizes: successful collaboration depends far more on…
Emma outlines how 
