Today we are talking about the open data platform DKAN, what it's used for, and how it applies to Drupal with guests Liz Tupper & Dan Feder. We'll also cover Modern Drupal Dashboard as our module of the week.
Have you ever wanted to have your Drupal site admins start with a fast, widget-based interface that surfaces key site metrics, system health, and operational insights? There's a module for that.
How old: created in Feb 2026 by Gaurav Kapoor (gaurav.kapoor) of werk21 in Berlin
Versions available: 1.0.5, which works with Drupal core 10.3 and 11
Maintainership
Actively maintained
Security coverage
Number of open issues: no open issues
Usage stats:
4 sites
Module features and usage
With the module installed, site visitors with the new "Access modern dashboard" permission can access a React-based dashboard with widgets to provide insights on topics like:
Content overview: total content count, published vs unpublished, and per content type breakdown.
Users overview: user count per role (users with multiple roles are counted in each role), plus pie chart visualization.
Additional Content (Entity overview): lists all entity types (content + configuration), shows counts, and provides direct "Manage" links.
Modules overview: installed modules summary, including enabled/disabled and core/contrib breakdown.
System & status: key environment details such as Drupal core version, PHP version, and database information.
Health checks: displays Drupal requirement checks grouped by status (pass/warning/error) with a dedicated detail view.
Each widget can be clicked to open a detail view of the extended data, making it easy for admins to dig into any area
The widget-based architecture should also help to pull in data from other sources, potentially including things like analytics
The latest update to the CKEditor contributed modules brings AI writing and editing directly into Drupal. Premium Features module 1.8.0 introduces CKEditor AI, adding AI Chat, AI Review, AI Translate, and AI Quick Actions inside the rich text editor. Authors can write, review, and translate content without the back and forth of third-party tools.
Our release schedule includes three potential release dates for Drupal 12.0.0, depending on when critical requirements are completed:
Week of June 15, 2026, if beta requirements are completed by March 27
Week of August 10, 2026, if beta requirements are completed by May 15
Week of December 07, 2026, if beta requirements are completed by September 11
Our new target release date for Drupal 12.0.0 is the week of August 10, 2026
Many great improvements landed recently. The main branch is on Symfony 8 and most deprecated modules are removed already. With only a few days remaining until the March deadline of the first release option though, we are confident that not all critical requirements will be completed by March 27. Therefore, we are officially announcing that our new target release date for Drupal 12.0.0 is August 10, 2026, and the beta deadline for critical requirements is May 15, 2026.
We need your help to complete requirements by May 15!
While there are other pending improvements that are not hard requirements for Drupal 12's release, these are the most urgent needs:
PHPUnit 12 support
While our ultimate goal is to support PHPUnit 13 in Drupal 12, there are significant API changes in PHPUnit 12 that we first need to adopt. See #3527936: Introduce support for PHPUnit 12
To reduce the size of core, we are excluding tests from core release packages, and offering them via a different namespace. This is a disruptive change and should only be done in a major release.
See #3067979: Exclude test files from release packages.
Deprecate and remove libraries, modules, themes and dependencies
The above list are the current highest priorities. We'll keep identifying and tagging Drupal 12 release priority issues. The up to date list can be found using the Drupal 12.0.0 release priority tag.
DrupalCon Chicago 2026 has begun, bringing together the global Drupal community from March 23 to 26 at the Hilton Chicago. As the event kicks off, attention is turning to the sessions scheduled over the coming days, many of which focus on accessibility, inclusion, and how Drupal teams are responding to evolving real-world requirements.
In the lead-up to the event, The DropTimes published a series of articles previewing selected sessions from the program. These included Palak Agarwal's coverage of accessibility audits on Drupal websites, highlighting recurring issues such as missing alt text, poor contrast, and structural inconsistencies that continue to affect many Drupal projects.
As DrupalCon Chicago gets underway, these sessions point to the conversations that will shape the week ahead. The focus is not only on what Drupal can do, but how it can be built and used in ways that are more accessible, inclusive, and effective in practice.
Additional developments from across the Drupal ecosystem were published during the week. Readers may follow The DropTimes on LinkedIn, Twitter, Bluesky, and Facebook for continuing updates. The publication also maintains a presence on Drupal Slack in the #thedroptimes channel.
A DrupalCon Chicago session will outline the next phase of the ECA module, focusing on making workflow automation accessible to a wider range of users. Despite adoption across more than 16,000 sites, ECA is estimated to be used by only a small portion of the Drupal ecosystem. The presentation will explore how usability, onboarding, and guided workflows are being reworked based on community feedback.
Come Monday, March 23rd, for a day devoted to Drupal in healthcare- a relaxed and friendly opening to DrupalCon with information-packed presentations plus two "table talk" sessions which will give everybody a chance to dive deeply into key topics, including privacy and overall takeaways. Whether you are in a state department of health, a non-profit hospital, a public health organization, or anyplace else in the broad healthcare space, there are unique needs in ensuring security, accessibility, compliance, and availability of important information and tools.
Online communication and emerging technologies promise improved access and capabilities for patients and professionals. Useful and inspiring digital experiences, however, must be built on a foundation of privacy, accessibility, and legal compliance. Come listen to healthcare technology practitioners share their experience solving these and more challenges in healthcare.
Ticket includes lunch, and we will be all wrapped up by 4pm.
Who Should Attend
Everybody interested in hearing and discussing how companies and the community are creating rich digital experiences in the healthcare space. All levels of colleagues in the pharma, medical, clinical, hospital, payers, caregivers, advocates, and healthcare professional space should go to DrupalCon and the Healthcare Summit!
Bring your needs to the table talks and we will embark on facilitated peer-to-peer problem solving with others who are affected and tech and healthcare industry experts.
COVID-19/DrupalFlu Safer Space
We will have a sensor in the room to monitor CO₂ levels and if they remain between at 800-1000 ppm.
Agaric will also have high-quality N95 masks available to anyone who wants them, and may bring our own MERV-13 Corsi-Rosenthal box fan filter, which provides appropriate filtration for reducing the spread COVID-19.
More about the Healthcare Industry Summit
The Healthcare Industry Summit brings together professionals and innovators to explore how Drupal can drive impact in healthcare. Through expert-led sessions, you'll gain insights into topics such as the responsible use of AI, personalization, content marketing, and streamlining migrations.
In addition to presentations, roundtable discussions will provide opportunities to share experiences, exchange ideas, and build connections with peers tackling similar challenges. Join us to discover innovative approaches and collaborative strategies that are shaping the future of healthcare with Drupal.
I'm setting up my Drupal Playground to experiment with AI coding agents. My previous post was about using Claude Code to establish a Drupal environment, and it felt a bit like crawling, but now I am ready to pick up the pace.
I've experimented and found that, in addition to sending effective code-generation prompts to an AI, providing metadata about the targeted codebase is equally important. The standard way to give this context is AGENTS.md. My initial experiments with Amazee.io's AGENTS.md produced much better results with PHPStorm's Junie. I'm inclined to think that Drupal core should include an AGENTS.md file or template.
Meanwhile, I've been experimenting with Claude's Chat UI without any context beyond knowing I am a Drupal developer. Despite this, Claude, with no background information, shows an impressive understanding of Drupal's API and developer workflow. For example, Claude can plan and develop an entire module, including automated tests. I look forward to seeing Claude attempt to build a Telephone Filter module, based on the one I created with ChatGPT a year ago. For now, I plan to continue setting up my environment to give Claude Code the necessary context to produce the most reliable results.
A recap shared by DevBranch outlines the 30th Drupal Cafe Lutsk meetup, marking an anniversary gathering with three talks and community participation. The event combined technical discussion, personal narratives, and organiser insights, while retaining its informal structure with food, certificates, and an afterparty. The summary reflects the continuing role of local meetups in sustaining Drupal community engagement.
If you study computer science or web development, you'll take an introductory JavaScript course. Everyone starts in a similar place: variables, let and const (or var if you're old enough), maybe even a conversation about the difference. You write a few functions, do some math, and concatenate some strings. It feels like learning a language in the abstract - technically correct, but removed from real work.
Before long, you are manipulating a web page. You grab an element, change its content, add a class, and attach a click handler. The browser responds. The page changes. It finally feels tangible.
But even then, JavaScript can feel like a layer you add on top rather than the foundation of the experience itself. And almost inevitably, you move to a library or framework. For many of us, that once meant jQuery.
Abstraction solved real problems
jQuery did not become dominant because developers were lazy. It solved real problems. Browsers were fragmented. There was no consistent way to select elements from the DOM. Event handling varied. AJAX required wrestling with verbose XMLHttpRequest code and awkward callback patterns. jQuery unified those concerns behind a clean, approachable interface: the dollar sign selector, the on method, simple get and post helpers, animations like fadeIn and slideUp.
It was a necessary abstraction at the time.
Over the years, though, the platform evolved. Browsers standardized. APIs matured. ES6 modernized the language. CSS grew far more capable. Many of the problems jQuery once addressed were absorbed directly into the browser.
The platform changed.
When thoughtful choices become defaults
We may be living through a similar moment with modern frameworks. React and other tools solve meaningful problems. They help teams move quickly and provide structure, especially for developers early in their careers. In many cases, they are exactly the right choice.
But over time, thoughtful decisions can quietly become defaults. A subtle assumption can creep in: if something feels modern or interactive, it probably requires a framework.
The shift is not dramatic. It is behavioral. Instead of beginning with the problem, we sometimes begin with the stack. If an interaction feels dynamic or app-like, we assume it needs something larger.
Frameworks offer guardrails and shared patterns, and that consistency is valuable. But when the tool becomes the starting point for every conversation, it can narrow the range of options we consider. We stop asking what the browser already provides. We begin to treat complexity as the baseline for modern work.
This is not bad architecture.It is often just unexamined architecture.
It shows up in small ways: adding a dependency before exploring a native API, reaching for a heavy client-side solution when progressive enhancement might be enough, and introducing new tooling because that is what modern projects tend to do. Each decision is understandable on its own. Over time, though, they expand the surface area of a project: more dependencies, more upgrades, more maintenance. Fewer dependencies can mean fewer upgrades to manage, fewer compatibility conflicts, and a smaller maintenance surface over time.
The foundation is stronger than we remember
While we have been refining our build pipelines and debating frameworks, the browser has continued to evolve. Quietly and steadily. Modern JavaScript is not what it was 10 or even five years ago. Today's browsers ship with stable, well-documented APIs that address many of the use cases we once handled with libraries.
Need to know when something enters the viewport? There is Intersection Observer.
Need to react to changes in the DOM without polling? Mutation Observer is built in.
Need to respond to screen size changes? MatchMedia handles that cleanly.
Need to persist data between sessions? Local storage is there.
Need to integrate with a device's native share dialog? There is an API for that.
CSS has evolved as well. Layout systems, transitions, scroll behaviors, and positioning features eliminate entire categories of JavaScript we once considered unavoidable.
And the language itself has matured. Modules, promises, async and await, richer array methods, cleaner syntax. These are no longer experimental features. They are part of the platform.
None of this is particularly flashy. It is simply what the browser now provides.
The hard part is not writing JavaScript. It is knowing what exists.
The important point is not that every project should avoid frameworks. It is that many of the problems we once solved with external libraries now have first-class support in the browser itself. So, what does that mean in practice?
Add one small pause to your workflow. Before installing a dependency, check the platform. Search MDN. Look up "browser API for…" and see what comes back. You might discover that Intersection Observer replaces the scroll library you were about to add. Or that CSS handles the animation without JavaScript at all.
It means reframing how you evaluate tradeoffs. When a feature request comes in, write down the requirement in plain language before you write down the stack. What actually needs to happen? A modal opens. Content animates on scroll. State persists between visits. Once the behavior is clear, ask whether the browser can already do it.
It means keeping a short list of native capabilities in your mental toolkit: MatchMedia. Local storage. Native form validation. ResizeObserver. The goal is not to memorize every API. It is important to remember that vanilla JavaScript is an option.
It also means normalizing this conversation on your team. When someone suggests a new library, ask a simple question: is there a native way to do this? Not as a challenge. As due diligence.
None of this requires abandoning modern tooling. It simply widens your decision tree. And it costs almost nothing but attention.
Join us at DrupalCon Chicago
In our session, "Elevating Drupal Experiences with Vanilla JavaScript," we'll share how we've used modern browser capabilities to build rich, interactive experiences within Drupal - not by rejecting frameworks, but by pairing Drupal's strengths with what the browser already does well.
We'll walk through:
Where native APIs replaced heavier dependencies
Where progressive enhancement simplified complexity
Where we had to rethink our own assumptions
More than anything, we hope it sparks a conversation.
If you go
If you're going to DrupalCon Chicago 2026, please make sure to attend the session with Mari and Andrés.
Where: Hilton Chicago, 720 S. Michigan Ave., Chicago, IL 60605, Salon A-2 (LL)
Three complete rewrites with three AI coding tools over 14 months. Each rewrite passed the same test suite. The spec and the tests are not interchangeable. The AI tool is.
This covers the many options it offers developers for fine-tuning their module code, from dependency injection to plugin inheritance, entity base fields, form elements, permissions, library asset files, and more.
Meanwhile, the latest release of Module Builder adds a feature I've wanted to implement for a very long time: when a new form section is added to add a new component (such as a plugin, hook class, or entity type), the form scrolls up to the new section that's just been added with AJAX. This makes it much clearer to understand what's just been changed, and helps with navigating around Module Builder's forms.
Undocumented trick to make Composer copy a local package repository
I needed to test a Drupal module I was working on in a Docker container. The code was not in a location accessible to Docker. I tried to use Composer to copy it over. This would have worked if the code contained a composer.json file. I could have used a Composer path repository with symlink set to false. But it did not contain a composer.json file, so I had to use a Composer package repository. Composer kept symlinking instead of copying.
As accessibility deadlines approach, a DrupalCon Chicago 2026 session examines how government and university teams can move beyond compliance-driven approaches and integrate accessibility into design, development, and content workflows. Drawing on real project experience, the session positions accessibility as an ongoing practice shaped by systems, not a final checkpoint.
Matthew Saunders will present a talk on neuro-inclusive system design at DrupalCon Chicago 2026, focusing on how organisational structures create friction for neurodivergent individuals. The presentation outlines practical changes to hiring, team operations, and leadership practices, positioning neuroinclusion as a systems-level design problem rather than a policy concern.
Join us THURSDAY, March 19 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
The latest update to the CKEditor contributed modules brings AI writing and editing directly into Drupal. Premium Features module 1.8.0 introduces CKEditor AI, adding AI Chat, AI Review, AI Translate, and AI Quick Actions inside the rich text editor. Authors can write, review, and translate content without the back and forth of third-party tools.