LocalGov Drupal is a Drupal distribution that combines Drupal, some configuration, and a collection of modules with the aim of making it easier for councils to create websites. The functionality provided includes content pages, news pages, bus timetables, and waste collection systems. What's more, it's maintained by a vibrant community of people.
The LocalGov Drupal Waste Collection module is a module that allows local bin collection schedules to be displayed to users. This uses a combination of an address lookup and collection data to show users the bins collection schedule for that address for the next few months.
A plugin interface is used to allow different banks of data to be used in the bank end of the module, with CSV and Whitespace API integration coming with the module. Whitespace is a company used across the UK to manage waste collection systems and the Whitespace plugin interfaces with a SOAP API to pull bin collection data into the site.
I've been using the Waste Collection module for a little while now with a few different projects. Whilst the information that the module provides is good, I needed to alter this data in a recent project with Central Bedfordshire. This required the use of a hook to alter the Whitespace plugin class and output more customised waste collection schedules.
In this article I will go through the issue I needed to correct, and how I altered the data coming out of the Whitespace API without creating a new plugin.
The Problem
When you set up Whitespace integration using this module it pulls a set of service names, which is essentially a list of the types of collections that can happen. This will be things like "Refuse (black bin)" or "Recycling" and shows residents what sort of bin they need to put out for collection on that day.
I've read recently about making SDCs dependent on Drupal Canvas because of needing to reference Canvas in the definition of your prop, so the right media widget is used inside Canvas:
image:
$ref: json-schema-definitions://canvas.module/image
type: object
title: Image
description: >
Image of the singer
examples:
- src: 'micro.webp'
alt: 'Nice picture of the singer'
width: 200
height: 300
That was the case during the alphas. But was fixed long ago, even before the 1.0.0 release. See canvas#3515074.
image:
type: object
title: Image
required: [src]
properties:
src:
type: string
format: uri-reference
contentMediaType: "image/*"
x-allowed-schemes: [http, https] # this is image-uri, itself a nested $ref
alt: { type: string }
width: { type: integer }
height: { type: integer }
description: >
Image of the singer
examples:
- src: 'micro.webp'
alt: 'Nice picture of the singer'
width: 200
height: 300
That's more verbose, but would make your SDC Canvas-independent and re-usable, and it's 100% equivalent.
If we missed updating some docs, please create an issue on the Canvas issue queue.
At Josefinas, every pair of shoes is handmade in Portugal after the order is placed. There is no warehouse full of finished stock: a customer buys, and an atelier starts working. For years, the bridge between "order paid" and "order shipped" was a shared spreadsheet. It listed what had to be produced, who was making it, and when it might be ready. It also lived completely outside the store: no link to the actual orders, no states, no history, and no way to know where time was being lost.
We replaced that spreadsheet with a Drupal module. It has now been running Josefinas' production for months, and today we are releasing it to the community: Commerce Make-to-Order is available on drupal.org, with a stable 1.0.0 release.
What it does
Commerce Make-to-Order adds a production layer to Drupal Commerce. Make-to-order (also written made-to-order, or build-to-order) means producing items only after a customer order is received, instead of keeping pre-made inventory. When an order reaches a state you configure (for example, paid), the module creates one MTO order per order item: a production order the team tracks from queue to completion.
Each MTO order runs a State Machine workflow designed for real ateliers: Draft, Queued, Waiting for Materials, In Production, Quality Check, Rework, Completed, Canceled. QC failures do not silently loop back into production: they move to a dedicated Rework state and back through Quality Check, so first-pass rate and rework are measurable instead of invisible.
Around that core there is everything a production team needs day to day:
Production order numbers via Commerce Number Pattern (MTO-2026-00042)
Assignment to team members, priorities, and due dates with overdue highlighting
Estimated completion dates, calculated automatically from a per-type setting
Internal notes, transition notes, and team notes with optional email notification
An activity log timeline and a full state history with per-state timing
A production analytics dashboard: bottlenecks, team performance, materials wait analysis, QC metrics, on-time delivery
Closing the loop with the store
The interesting part is what happens when production finishes. The module offers two integration modes with the parent Commerce order:
State sync: when all MTO orders of a Commerce order complete, the order transitions directly (for example, Processing to Shipped).
Shipment integration: with Commerce Shipping, MTO orders link to the checkout shipment, and when the last one completes the order is promoted to a "ready to ship" state. The shipping team adds tracking, splits shipments if needed, and ships.
Automation has one important limit, learned in production: hold states. Some order states represent a deliberate human decision, like a customer asking not to ship yet. You can configure which states automatic promotion must never override; the module logs a note on the order instead and lets a person decide.
Battle-tested, then released
This is not a v1 built in the abstract. The module has managed hundreds of real production orders at Josefinas before its first public release. Publishing it meant generalizing what was site-specific (hold states became per-type configuration, integrations became optional), adding its own test coverage against Drupal Commerce's core workflows, and cleaning everything to drupal.org standards.
It also plays well with the rest of our contrib work: with Commerce Order Amend, amending a placed order keeps production orders in sync with the changed items.
Requires Drupal 10 or 11, Commerce 2.x or 3.x, and State Machine. Commerce Shipping is optional, for the shipment integration mode.
If you run a store where things are made after they are sold (furniture, fashion, print on demand, anything artisanal) we would love to hear how it fits your workflow. The issue queue is open.
All security issues have been migrated from the older security.drupal.org site to our GitLab instance at git.drupalcode.org. This is the latest in a series of steps to improve Drupal's coordinated vulnerability disclosure tools. We hope this will help in a few ways:
Merge requests for security issues will get automated testing to increase the quality of the releases. (Previously, tests for core security issues had to be triggered manually, and contrib testing was not available.)
GitLab has more automation to help with advisory creation, reducing manual work.
Powerful features like labels, commenting, and thread reviews on merge requests are now possible for security issues as well.
Here are some of the key steps we took:
We started by evaluating a few solutions. We decided to use the GitLab instance on drupalcode.org.
We planned how to remap and improve the current features from security.drupal.org and added some labels and automation to private issues on drupalcode.org.
We made new security issue reporting default to git.drupalcode.org for several months. This helped us could gain confidence in the system, fix bugs, and make improvements.
While that happened, Neil Drumm worked to create the migration process.
The migration finally ran from July 9th to July 12th.
This work is possible because of support from the Drupal Association and is very appreciated.
We suppressed most emails during the migration, but a small number of people did get extra notification emails about issues, including old issues. We apologize for any resulting confusion.
How do I use GitLab to submit and manage security issues?
As before, security reports should be submitted by clicking the "Report a security vulnerability" link on the project page. If a project has already migrated public issues to git.drupalcode.org, you may also mark an issue confidential as you open it. The Security Team triages confidential issues for all covered projects.
For more information about how Drupal.org's GitLab instance works, read our documentation.
Let us know your thoughts. If you have feedback about how to further improve the Security Team process, you can file them in the Security Team Queue. If you have issues to report about the GitLab tooling itself on git.drupalcode.org, you can file them in the Drupal.org queue.
The old site does a redirect to the new location for issues and members of the Security Team can get content out of it if anyone notices items missing from the migration.
Panel access simplifies procurement but does not authorise a deployment. Agencies still need to review the assessment scope, findings, and residual risk against their intended use.
The Drupal Association is changing CEOs, and the community reacted with the intensity it usually reserves for controversy. Jürgen, who sent the DA a formal four-page letter of concern in May, makes the case for constructive engagement over outrage. Leadership means disappointing half the room on almost every decision - disagree with choices without turning decision-makers into enemies. The practical call to action is the 2026 board election. Become a member now to earn the right to vote. If you are already a member, vote. Show up on the quiet days, not only when the alarm goes off. A transition is rare - a moment where the direction is genuinely open.
Official Drupal 7 support ended on January 5, 2025 - yet many organizations still run sites on it in 2026. The real question is no longer "should we update?" but what platform you want for the next 5-10 years.
A practical decision guide: rebuild on Drupal 11 or Drupal CMS, migrate content, switch CMS, go static, or buy time with extended support - plus a prep checklist for pricing and board-ready options.
For regulated Drupal projects, choosing a cloud region settles only the easiest part of the sovereignty question. Access, key custody, operations, recovery, and exit planning determine whether the hosting claim holds.
Darren Oh links his board candidacy to a question now facing Drupal: how the project can expand adoption without adding friction for maintainers, smaller projects, and new users.
On July 15, 2026, Drupal published several core security advisories. If an organisation's website, portal or service platform runs on Drupal, now is the time to check not only the version number, but the whole update process. Drupal core July security updates: what site owners should check now On July 15, 2026, Drupal published several core security advisories. According to Drupal.org, the issues include cross-site scripting, commonly known as XSS, and information disclosure risks. The relevant fixes point to Drupal 11.4.4, Drupal 11.3.14 and Drupal 10.6.13. This does not mean every Drupal site is automatically under attack. It does mean that Drupal cannot be treated as a platform to look at "later". For a school, municipality, public-sector body, university, NGO or larger…
New Docker Compose library → Improved UX during ddev start and ddev stop; the separate ~/.ddev/bin/docker-compose binary is no longer needed
Way Faster ddev start, ddev stop, and ddev restart → See below
MariaDB 12.3 LTS support
Podman and Docker rootless are no longer experimental → Both are now stable and ready for general use
Node.js improvements → nodejs_version is preserved in .ddev/config.yaml, and you can install several Node.js versions with n install <version> inside the web container
ddev start in v1.25.3 runs post-healthcheck tasks concurrently (thanks to @jonesrussell), and a fixed bug in the web server startup script removes a ~10-second delay from ddev stop. In our benchmarks, ddev start from a stopped state is about 28% faster on macOS and 21% faster on Linux.
Don't take our word for it - a new script lets you benchmark the difference on your own machine:
Organizations sponsoring at $100/month or more now receive additional partner perks. Become a sponsor↗ or contact us to learn more.
$100/month+ Partners get
Full unrestricted access for your whole organization to coder.ddev.com for every member of their organization.
One year of free diffy.website Visual Regression Testing.
What's New on the Blog: TYPO3 Screencasts and coder.ddev.com
A run of short screencasts landed on the blog this month, mostly using TYPO3 as the example project:
Sharing Your TYPO3 Project with ddev share → Exposing a local TYPO3 project on a public URL, including the base URL config quirk and the pre-share/post-share hooks that fix it.
Using git worktree with TYPO3 → How multiple git worktree checkouts interact with DDEV's per-directory naming, and how to fix TYPO3's absolute base URL so every worktree works out of the box.
DDEV Xdebug Quickstart with PhpStorm → A less-than-5-minute screencast: set a breakpoint, enable Xdebug with ddev xdebug on, and step through PHP code in PhpStorm.
New Usage Stats Page
The Usage Stats page replaces our old static usage-stats blog post with live charts pulled directly from Amplitude at build time. It's now the up-to-date place to see DDEV adoption and usage trends.
Community Highlights
Knecht.works Beta Testers Wanted: Dashboard for Agencies - The team at knecht.works is building a dashboard for agencies managing many DDEV projects. It automates tasks like security updates by booting projects with full database environments and generating pull requests with previews. They're looking for beta testers. Read the announcement↗ and see the LinkedIn post (German)↗ on why Dependabot can't update a CMS.
How a Broken Installer Reload Led to Two Patches - Michael Staatz debugged a TYPO3 installer issue, uncovered a SQLite PRAGMA ordering quirk, and ended up submitting patches to both TYPO3 Core and DDEV. A nice story about how one bug report can improve two projects. Read it↗
Community Tutorials from Around the Web
Switching from nvm to Node.js Versions in DDEV → John Henry covers moving from host-side nvm to DDEV's built-in Node.js version management. Read on johnhenry.ie↗
Setting Up DDEV for WordPress Development, Part One → Ryan Stubbs walks through DDEV project configuration, WordPress installation with WP-CLI, Mailpit, Adminer, and using bind mounts to keep plugins and themes organized outside the main WordPress installation. Read on ryanstubbs.co.uk↗. We're holding our breath for part 2!
Alias Your Local DDEV Commands → Martin Anderson-Clutz shares shell wrappers that let you type drush, composer, and friends without the ddev prefix - automatically detecting whether you're in a DDEV project and falling back to host execution when you're not. Read on mandclu.com↗
Porting a DDEV MySQL/MariaDB Database to PostgreSQL with pgloader → Erik Pöhler walks through migrating a DDEV project's database to PostgreSQL 17 using pgloader, then reconfiguring the project for PostgreSQL. Read on erikpoehler.com↗
What's New in DDEV for TYPO3 Folks, July 2026 → A TYPO3-focused wrap-up covering v1.25.3, Docker/Podman rootless stability, new diagnostic utilities, and DDEV Foundation governance milestones. Read on news.typo3.com↗
Governance
The DDEV Foundation Board is meeting quarterly, with formal governance and growing board authority as key strategies for the Foundation.
The board members are there to represent you and the project. If you have insights, thoughts, or direction about where DDEV should go, please contact them. If you see possibilities for them at your community events, invite them!
DDEV has a new Privacy Policy, part of the Foundation's ongoing work on formal governance.
The next DDEV advisory group meeting, open to everybody, is September 2, 2026 at 8:00 AM US Mountain / 10:00 AM US Eastern / 16:00 CEST. Add to Google Calendar • See the agenda. We love to hear from our community!
Sponsorship Update
Sponsorship dipped slightly this month, people on vacation! - thank you to everyone who has contributed!
June 2026: ~$10,075/month (84% of goal)
July 2026: ~$9,931/month (82.8% of goal).
If DDEV has helped your team, consider sponsoring. → Become a sponsor↗
Contact us to discuss sponsorship options that work for your organization.
Stay in the Loop-Follow Us and Join the Conversation
This article is cross-posted with permission from Dries Buytaert's blog.
The Drupal Association is entering a new chapter. Tim Doyle is stepping down as CEO, and the Board has appointed Tiffany Farriss as interim CEO.
I am grateful to Tim for his leadership and his impact on the Association. He built a strong leadership team that helped guide Drupal through an ambitious period of innovation. That team is well positioned to continue supporting Drupal and its community.
Tiffany brings continuity and deep expertise to the Drupal Association. She has contributed to Drupal for many years and served on the Drupal Association Board for more than a decade, including on its Finance Committee. She helped organize DrupalCon and built and ran a successful agency in the Drupal ecosystem. She understands our project, the Association's finances, and the realities our partners, contributors, and users face.
I have worked with Tiffany for many years. She is thoughtful, deeply committed to Drupal, and unafraid of hard questions. Although her title is interim CEO, she has the full authority and confidence of the Board, as well as my full support.
We expect Tiffany to serve for six to twelve months. During that time, she will focus on strengthening the Association's financial and operational foundation and preparing it for long-term leadership. Later in that period, the Board plans to launch a search for the next permanent CEO.
Turning innovation into momentum
Tiffany is stepping into the role at an important moment for Drupal.
Over the past few years, our community has done some of its most ambitious work. Contributors have continued to modernize Drupal Core. We launched Drupal CMS to make Drupal easier to adopt, introduced Drupal Canvas to rethink how people build, and rapidly advanced Drupal AI to change how people create and manage content.
We have also taken important steps toward marketing Drupal with the seriousness it deserves, so more organizations understand why it remains one of the most powerful and trusted platforms for building serious websites and applications.
This progress was made possible by our contributors and the organizations that invest in Drupal every day. The Drupal Association's role is to support that work and help turn it into wider adoption, a stronger ecosystem, and more opportunity for Drupal businesses.
Sustaining Drupal's essential work
The Drupal Association operates much of the infrastructure the project depends on, from Drupal.org and our collaboration tools to the services that help keep Drupal secure.
Drupal's infrastructure alone costs roughly $3 million each year. Today, it is funded through DrupalCon revenue, partnerships, sponsorships, donations, donated services, and volunteer contributions. That model has supported Drupal for many years, but it is not durable enough for the scale of the work ahead.
This is a challenge shared by open-source stewards everywhere. The software may be free to download, but the infrastructure and stewardship that make it dependable are not free to provide.
Building a stronger Drupal Association
Our commitment to Drupal's infrastructure and community will not change. Supporting them well requires a stronger Drupal Association, and that may mean exploring new approaches. We will weigh the options carefully, guided by what is best for Drupal and the people who depend on it.
This work will not be easy, but our ambition is clear: make the Association more sustainable, help Drupal innovate faster, strengthen how we bring it to market, and better support Certified Partners.
As this work takes shape, we will be transparent about what we are learning, the choices we are considering, and what they could mean for the Association and the community.
Tiffany understands what makes Drupal special and what the community values most. She also has the experience and mandate to shape what comes next.
Every new chapter depends on people willing to step forward. I am thankful to Tim for all he has done, to the Association's staff for their dedication, and to Tiffany for taking this on. With their commitment, I am confident in Drupal's direction and excited about the work ahead.
The Drupal Association is entering a new chapter. Tim Doyle is stepping down as CEO, and the Board has appointed Tiffany Farriss as interim CEO.
I am grateful to Tim for his leadership and his impact on the Association. He built a strong leadership team that helped guide Drupal through an ambitious period of innovation. That team is well positioned to continue supporting Drupal and its community.
Tiffany brings continuity and deep expertise to the Drupal Association. She has contributed to Drupal for many years and served on the Drupal Association Board for more than a decade, including on its Finance Committee. She helped organize DrupalCon and built and ran a successful agency in the Drupal ecosystem. She understands our project, the Association's finances, and the realities our partners, contributors, and users face.
I have worked with Tiffany for many years. She is thoughtful, deeply committed to Drupal, and unafraid of hard questions. Although her title is interim CEO, she has the full authority and confidence of the Board, as well as my full support.
We expect Tiffany to serve for six to twelve months. During that time, she will focus on strengthening the Association's financial and operational foundation and preparing it for long-term leadership. Later in that period, the Board plans to launch a search for the next permanent CEO.
Turning innovation into momentum
Tiffany is stepping into the role at an important moment for Drupal.
Over the past few years, our community has done some of its most ambitious work. Contributors have continued to modernize Drupal Core. We launched Drupal CMS to make Drupal easier to adopt, introduced Drupal Canvas to rethink how people build, and rapidly advanced Drupal AI to change how people create and manage content.
We have also taken important steps toward marketing Drupal with the seriousness it deserves, so more organizations understand why it remains one of the most powerful and trusted platforms for building serious websites and applications.
This progress was made possible by our contributors and the organizations that invest in Drupal every day. The Drupal Association's role is to support that work and help turn it into wider adoption, a stronger ecosystem, and more opportunity for Drupal businesses.
Sustaining Drupal's essential work
The Drupal Association operates much of the infrastructure the project depends on, from Drupal.org and our collaboration tools to the services that help keep Drupal secure.
Drupal's infrastructure alone costs roughly $3 million each year. Today, it is funded through DrupalCon revenue, partnerships, sponsorships, donations, donated services, and volunteer contributions. That model has supported Drupal for many years, but it is not durable enough for the scale of the work ahead.
This is a challenge shared by open-source stewards everywhere. The software may be free to download, but the infrastructure and stewardship that make it dependable are not free to provide.
Building a stronger Drupal Association
Our commitment to Drupal's infrastructure and community will not change. Supporting them well requires a stronger Drupal Association, and that may mean exploring new approaches. We will weigh the options carefully, guided by what is best for Drupal and the people who depend on it.
This work will not be easy, but our ambition is clear: make the Association more sustainable, help Drupal innovate faster, strengthen how we bring it to market, and better support Certified Partners.
As this work takes shape, we will be transparent about what we are learning, the choices we are considering, and what they could mean for the Association and the community.
Tiffany understands what makes Drupal special and what the community values most. She also has the experience and mandate to shape what comes next.
Every new chapter depends on people willing to step forward. I am thankful to Tim for all he has done, to the Association's staff for their dedication, and to Tiffany for taking this on. With their commitment, I am confident in Drupal's direction and excited about the work ahead.
Our CEO, Tim Doyle, has stepped down from his role. We are grateful to Tim for his leadership and impact on our organization. Tim has built a strong leadership team that is positioned to continue the mission and vision that he and the Board share for Drupal.
As part of this process, the Board has been working to identify Tim's successor. We anticipate that the important work and mission of our organization will continue under new leadership, building on the strategy and plans we led during Tim's time with Drupal.
Likewise, the Board has been working with the senior team to ensure that interim leadership will be in place to facilitate a smooth transition.
We are grateful to Tim for all of his contributions as the leader of Drupal, and we look forward to his continued success in his future endeavors.
The Drupal Association board has appointed Tiffany Farriss as the Interim CEO, who brings more than a decade of experience as a Drupal Association board member, to guide the organization and community through this transition period.
The Layout Builder module doesn't sufficiently sanitize block labels in certain scenarios, which can lead to a cross-site scripting (XSS) vulnerability.
This is mitigated by the fact that both the attacker and the targeted user need to be using the Layout Builder editing interface.
