drupal

Join us THURSDAY, July 17 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 doc: 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. 

• Join the call: https://us02web.zoom.us/j/81817469653

  • Meeting ID: 818 1746 9653
    Passcode: 551681

  • One tap mobile:
    +16699006833,,81817469653# US (San Jose)
    +13462487799,,81817469653# US (Houston)

  • Dial by your location:
    +1 669 900 6833 US (San Jose)
    +1 346 248 7799 US (Houston)
    +1 253 215 8782 US (Tacoma)
    +1 929 205 6099 US (New York)
    +1 301 715 8592 US (Washington DC)
    +1 312 626 6799 US (Chicago)

  • Find your local number: https://us02web.zoom.us/u/kpV1o65N

• Follow along on Google Docs: https://nten.org/drupal/notes

View notes of previous months' calls.

We’re excited to invite training partners to submit proposals for DrupalCon Chicago 2026, taking place 23-26 March at the Hyatt Regency Chicago.

DrupalCon is the premier gathering for the global Drupal community, bringing together developers, designers, strategists, and business leaders for a week of collaboration and knowledge sharing. This year, DrupalCon will highlight major innovations in Drupal CMS, including the rollout of Drupal CMS 2.0, and growing momentum around Drupal-powered AI tools and integrations. It’s a pivotal time in the Drupal ecosystem—and your training can help prepare attendees to thrive in this next era.

Training Day Details

• Date: Monday, 23 March 2026
• Format: Full-day trainings, split into two 3-hour sessions with a break for lunch
• Time: 09:00 – 16:00
• Model: Profit-sharing. If selected, you’ll be asked to provide a W9, electronic fund disbursement form, and signed agreement.

How to Submit:

To be considered, please submit a proposal via email to Meghan Harrell, Director of Community Programs at the Drupal Association, at meghan@association.drupal.org. Your proposal should include:

• Title and description of your training
• Level of experience required (beginner, intermediate, advanced)
• Key takeaways: What participants will learn and be able to do after the training

Deadline & Next Steps

• Proposal Deadline: Friday, 1 August 2025 (EOD)
• Review & Notification: Proposals will be reviewed the following week, with all applicants notified of their status by Monday, 11 August 2025.

Our goal is to finalize the training lineup in time for our Early Bird ticket launch on 15 September.

If you have any questions, please don’t hesitate to reach out to meghan@association.drupal.org. We look forward to reviewing your proposal and potentially partnering with you at DrupalCon Chicago 2026!

Drupal 10 will be supported until December 2026

From Drupal 10 on, Drupal core has a new major release schedule with a long-term support phase, so that two major versions are supported at a time. We previously announced that Drupal 10 would be supported until mid- to late 2026, depending on when Drupal 12 was released.

We are updating the release schedule and have agreed that Drupal 10 will officially be supported until December 2026, regardless of whether Drupal 12 is released in June, August, or December. This fixed end-of-life date should provide more certainty for the ecosystem and make planning site upgrades easier.

Disruptive deprecations should now be scheduled for removal in Drupal 13.0.0

Drupal core uses a deprecation process to provide backwards compatibility and a continuous upgrade path between major versions. When new APIs are added, the old code is deprecated and scheduled for removal in a later major version. Under the continuous upgrade path, the new major version has the same API as the final minor version of the previous major, but with deprecated code removed.

Drupal 12 is scheduled for release in 2026, and its first possible release window is June 2026. This means that the next major version of core may have a stable version in less than a year, with its beta versions released as early as March. At the same time, the current maintenance minor version of Drupal 10 (10.5.x) will receive security coverage until June 2026.

As a result, contributed projects may add Drupal 12 support while Drupal 10.5 is still supported during early 2026, which means those core versions need to share the same important APIs. Therefore, disruptive deprecations in Drupal 11.3.x and higher should be scheduled for removal in 13.0.0 (rather than 12.0.0). This allows contributed modules to support both the next major release and the currently supported minors. This way, we will not break backwards compatibility with 10.5.x for important APIs.

Help us get ready for Drupal 12!

Core modules are actually not disruptive to deprecate, because we can create an equivalent package in contrib and provide sites a smooth upgrade path for these modules from Drupal 11 core to Drupal 12 contrib. Take a look at the list of modules and other dependencies planned for removal from Drupal 12, and consider helping move these issues forward.

The Domain module in Drupal enables enterprises to run multiple regional sites from one codebase—reducing duplication, slashing maintenance costs, and accelerating time-to-market. In this guide you’ll find:

• Core concepts and business benefits
• Step-by-step configuration with context-sensitive tips
• Advanced edge cases and real troubleshooting
• Best practices, architecture notes, and next steps

Overview & Business Benefits

At its core, the Domain module injects a context layer into Drupal’s node-access system. Administrators define “domains” (e.g., “US Site”, “EU Site”) and then scope content, blocks, menus, and themes accordingly.

Key business wins:

• 75% reduction in redundant content across regions
• 40% faster editorial workflow with shared assets
• Single-point security patching and updates
• Consistent UX with local language, GDPR, and currency compliance

Architecture & Prerequisites

1. DNS & SSL: Point all domains/subdomains to the same server. Use wildcard or SAN certificates.
2. Webserver vhosts: Configure Apache/Nginx “Host” headers, all pointing at one codebase.
3. Composer install: composer require drupal/domain
4. Enable module: drush en domain -y
5. Permissions: Grant administer domains to your site-builder role

Then navigate to Configuration → Domains → Manage Domains to begin.

1. Create New Domains

Within Manage Domains, click Add Domain and fill out:

• Label: (e.g., “EU Market”)
• Domain Name: eu.example.com
• Theme Override: Optional per-domain branding
• Default Language: For localized fields
• Redirect Settings: HTTPS enforcement or 301 rules

Tip: Use consistent naming (Region-Code) for automation and reporting.

2. Assign Content to Domains

Every node has a Domain Settings tab:

1. Select one or more domains.
2. Optionally “inherit from parent” for taxonomy scoping.
3. Save and clear caches (drush cr).

Edge Case: If using Views, add a filter on Domain Access: Domain ID to prevent cross-domain leaks.

3. Domain-Specific Blocks & Layouts

1. Structure → Block Layout → Place block → Configure
2. Under Visibility Conditions, add Domain is, select domains
3. Save block

Performance Note: Too many visibility checks adds cache contexts. Where possible, group domains.

4. Navigation Menus per Domain

1. Structure → Menus → Add Menu → Name it (e.g., “EU Footer Nav”)
2. Add Links → Save → Place as block
3. Set Domain is visibility → Save block

Tip: For shared items, use hook_menu_links_discovered_alter().

5. Theme & Branding Overrides

1. Configuration → Domains → Manage Domains → Edit domain
2. Select Theme override → Save

Edge Case: If your theme uses asset libraries, ensure URLs are relative or wrapped in base_path().

Advanced Use Cases & Integrations

• domain_roles: Domain-specific editorial permissions
• content_moderation: Stage content by region
• Views Reporting: Expose Domain ID filter
• GDPR Compliance: Trigger consent banners on EU domains
• CDN & Cache: Vary by host or cookie for domain scope

Troubleshooting & Debugging

• Verify Domain Settings on the node
• Inspect domain_access tables in your database
• Run drush cr and drush domain:debug

• Check visibility conditions in Block config
• Ensure your theme region is active
• Confirm webserver vhost Host header

• Ensure the override theme is enabled in Appearance
• Clear Twig cache: drush config:import --partial
• Look for registry overrides in custom modules

Best Practices

• Share a base theme, layer domain-specific subthemes
• Limit domain assignments per content type
• Document naming conventions for domains, menus, and roles
• Use automated tests (Behat) to validate visibility
• Monitor performance impact via New Relic or Blackfire

References & Resources

• Domain Module on Drupal.org
• Mastering Multi-Site Configurations in Drupal

Share this

Add new comment

Today we are talking about The UI Suite Module, It’s module eco-system, and what’s new in the 2.0 release with guest Pierre Dureau. We’ll also cover Field Formatter Range as our module of the week.

For show notes visit: https://www.talkingDrupal.com/511

• What is UI Suite?
• UI Suite 2.0: Major Updates and Features
• Introduction to UI Suite Recipes
• Challenges with Drupal Themes
• Site Templates and UI Suite
• Component Compatibility and Community Education
• Design System Modules and Best Practices
• Experience Builder and UI Suite Integration
• Modernizing Display Tools
• Introducing the Distributor Tool
• Future of UI Suite and Core Integration
• Getting Involved with UI Suite

• UI Suite
• [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems
• sdc_devel
• Do’s Don’ts For SDC
  • use all the props & slots in templates
  • use the automatically defined attributes property
  • do not define any props or slots that are unused
  • define in the YAML all the props & slots you use in templates
  • props schema must be understandable by the display builder: no empty objects, empty arrays, arrays of empty objects, bag of props…
  • Example Fix
• Display Builder
• Adopt UI Patterns 2 to prepare developers and users for Experience Builder
• Getting started

Pierre Dureau - drupal.org/project/ui_suite pdureau

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi JD Leonard - jdleonard

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to show only a subset of field values on your Drupal entity displays? There’s a module for that.
• Module name/project name:
  • Field Formatter Range
• Brief history
  • How old: created in Jan 2024 by Florent Torregrosa (Grimreaper), but today’s guest Pierre is also a maintainer
  • Versions available: 8.x-1.6
• Maintainership
  • Minimally maintained & Maintenance fixes only
  • Security coverage
  • NO open issues
• Usage stats:
  • 1,362 sites
• Module features and usage
  • Unlike some competing solutions, this module uses third party settings to work on virtually any formatter for a multivalued field
  • As part of the configuration, a site builder can specify the offset (where to start), the number of field values to show, and the order in which to show them.
  • The order can be standard or reverse, or it can list them in a random order
  • The module page gives the example of an entity with 15 images attached, and being able to show only the first 5. Or maybe only the 5 most recent?
  • I think if you combined this module with the Custom Field module module we talked about in episode #505, you could achieve some interesting things with simple configuration. For example, you could have an FAQ page and have the teaser for it show three random answers for it.

LocalGov Drupal Camp 2025 was held in The Abbey Community Centre (near Westminster Abbey in London) on July 3rd 2025. I travelled down (despite the English rail network's attempts to the contrary) for the day as an attendee.

It was a hot day in London on the 3rd July, and thankfully the Abbey Community Centre had lots of doors and windows that we could open to let some air through. Including a few fans dotted around to try and keep the rooms cool.

After a small icebreaker, where people stood up if this was their first LocalGov Camp or what sort of role they have, we started the camp with an introductory session.

LocalGov Drupal is currently being used by 57 councils currently and has around 59 council websites (including a bunch of smaller council websites) being powered by the system. It's good to see the year on year increase in coverage of this project, which has reached a decent critical mass of interest and funding.

Lots of things have happened in the year since LocalGov Drupal Camp 2024 in Birmingham.

The Drupal 11 upgrade is nearly ready and lots of effort has been done on this recently. Technically, Drupal 10 is still supported until December 2026, when Drupal 12 is released, but we still want to keep things up to date as much as possible.

Read more

Dear readers,

The web is having an accessibility moment, and it's about time. While major platforms scramble to meet compliance deadlines, something more fundamental is happening in our corner of the internet. Our journey from default theme fonts (Thunder backend + EM Magazine frontend) to IBM Plex and Atkinson Hyperlegible revealed something telling: the same attention to detail that makes us distinguish between a zero and an uppercase O is the same mindset driving accessibility improvements across open source communities. This isn't a coincidence.

There's a philosophical shift happening where accessibility is becoming a natural extension of the open source ethos rather than a checkbox to tick. When we chose fonts explicitly designed for visually impaired readers or questioned why we looked identical to every other community site, we joined a larger movement. Developers are choosing semantic markup not because they have to, but because it's right. Designers are prioritising keyboard navigation from day one. Communities are recognising that technology's true purpose is serving people, all people.

What's encouraging is how this mindset is spreading beyond obvious accessibility wins. We're seeing it in performance optimisation for slower connections, content strategy that prioritises clarity over cleverness, and design decisions that favour inclusion over aesthetics. Whether through better typography, cleaner code, or thoughtful user experiences, communities aren't just talking about accessibility anymore. They're living it.

OPEN

• The Letters That Changed Everything: How The DropTimes Discovered Its Voice Through Typography

INTERVIEW

• Nineteen Years in a Twenty-Four-Year-Old Drupal

DISCOVER DRUPAL

• Advanced Features of the Automated Testing Kit - Part 3
• Drupal Frontend Editing 2.0.0-beta2 Offers Sidebar WYSIWYG Editor
• Velir Announces Search API Solr Dense Vector Module for Drupal 11
• DrupalX AI Integrates Official Drupal AI Module with New Groq API Sub-Module
• Drupal Core Single Directory Components Introduce Component Variants
• Beta Versions of ECA 3, Modeler API 1, and BPMN.iO 3 Released for Drupal
• Rajeev Kumar Develops Open-Source Instant Search for Drupal with Typesense
• daisyUI and Tailwind CSS Integration Streamlines Drupal Theming

EVENTS

• DrupalCamp Asheville 2025: The People, Purpose, and Ideas Shaping This Year’s Event
• DrupalCon Chicago 2026 Cuts Ticket Prices and Expands Summits & Trainings
• DrupalCamp Colorado 2025: Free and Open to All

ORGANIZATION NEWS

• Debug Academy Drupal 11 Course Begins September 8, 2025
• New RECOFTC.org Launches on Drupal to Support Community Forestry in Asia-Pacific
• IT Care LLC Releases YMCA Website Services Distribution on Drupal 10.5
   

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 and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you, 
Sincerely 
Alka Elizabeth 
Sub-editor, The DropTimes.

Visualizing Event-Condition-Action (or ECA) models is perfect choice to ease modern business processes and software development. ECA models transform complex sets of rules and relationships into understandable diagrams that can be easily interpreted by all project stakeholders. It helps to understand the business logic, helps identify problems in the development process and improves communication between technical and non-technical professionals. 
Visual parts of ECA models also push decision-making efficiency. They are capturing the entire process structure and understanding how different events can affect the system. In addition, it serve as excellent documentation that remains relevant throughout the project lifecycle. With tools like BPMN.io, teams can create, edit, and share ECA models. Keep reading to learn more about BPMN.io for ECA from the Golems Drupal development team.

This article was originally published on the BackUpScale blog.

Background

Our customer dashboard, which will soon be used for managing subscriptions to our backup service (and not just newsletters and our contact form, as we’re doing now), is built on the Drupal data management framework. Until now, we’ve been hosting it with a company that specializes in hosting very specific types of applications, like Drupal. This wasn’t working for us because our service is running in our Kubernetes cluster at a cloud service provider that specializes in managed Kubernetes hosting, which let’s us run whatever applications we want, and configure them however we need. The challenge was getting the dashboard to communicate securely with our other applications.

It needs to communicate with our back-end systems in the Kubernetes cluster to:

1. send requests from customers to provision services,
2. configure customer accounts, and
3. receive status information from back-end services to create log entries that users can see in their accounts.

Why the old approach broke down

In order for things to work with the old set up, we’d have to:

• expose internal applications to the Internet (so the dashboard site could access them), and
• add additional layers of security to the communications to ensure privacy.

We didn’t feel as confident with this set-up as moving everything into our private Kubernetes network, which protects all of our services with a single firewall. Keeping non-public facing services within that network ensures that they’re not accessible by anyone on the greater Internet (except our staff using the company VPN), which ensures greater security and privacy for our users.

In order to make the change, we needed to be able to run a Drupal site within Kubernetes. Given that Drupal is a popular framework, and Kubernetes is a popular container orchestration system, we assumed that there would be good options for putting them together using open-source infrastructure as code (IaC) to handle the automated provisioning (we automate everything here). However, we weren’t able to find anything that could help us.

Evaluated options

We explored the following options:

• Bitnami’s Helm chart (no longer supported as of 2021)
• Jeff Geerling’s Drupal Operator (no longer supported as of early 2025)

The Bitnami Helm chart did at least one very strange thing: It was placing the Drupal code files on the persistent volume instead of placing them in the container image. We wanted the Drupal code (or at least the Composer files that build it along with any custom code) to be version controlled with Git. When we tried to work around this, they made it very difficult to make these changes.

Jeff Geerling simply stopped recommending his earlier approach (except for potentially hosting many sites on a hosting platform), and said that he currently uses his own Kubernetes primitives. So we took that idea, and expanded on it to build a fairly complete solution. Once we had something that worked for us, we believed we could make it generic enough to make it available to everyone else. So that’s what we did.

This move eliminated two Internet-facing endpoints and let us apply a single network-policy layer to all microservices. Additionally, running inside the cluster removes a public load balancer, and shrinks latency.

Meet “Drubernetes”

Because we automate all of our infrastructure with Terraform, we just released Drubernetes, a new module in the Terraform Registry, which provisions Drupal onto a generic Kubernetes cluster. It shouldn’t matter where your cluster is, who’s managing it for you, or if you’re managing it yourself on your own hardware. We wanted to provide something standardized that everyone can use and build from.

Contribute

Contributions are welcome! Please try it, and provide any feedback that you may have. The project is hosted on Gitlab.com, and any issues can be opened from the board.

As always, if you have questions or feedback, feel free to reach out. We appreciate your support and can’t wait to bring you the next chapter of BackupScale.