03 Sep 2026
Drupal.org aggregator
Talking Drupal: Talking Drupal #568 - Off The Cuff #12
Today we are talking about Drupal Performance, Rapid Development, and Drupal Canvas Maturity with our hosts. We'll also cover Microsoft 365 FullCalendar as our module of the week.
For show notes visit: https://www.talkingDrupal.com/568
Topics
- Deprecating Module Theme Files
- Migrating Hooks to Classes
- Why This Change Matters
- Drupal Performance Gains
- Performance Audits and Lighthouse
- Automating Checks and Spreadsheet Rant
- AI Spreadsheet Cautionary Tale
- Privacy Concerns with AI
- Freelancer Pressure
- Rapid Change Reality
- Canvas Release Risks
- Community Support Needed
- AI For Documentation
- Canvas Production Readiness
- Canvas Architecture Debate
- AI For Voting Research
- LLM Bias And Sources
Resources
Guests
Martin Anderson-Clutz - mandclu.com mandclu
Hosts
Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)
MOTW Correspondent
Martin Anderson-Clutz - mandclu.com mandclu
- Brief description:
- Have you ever wanted your users' own Outlook calendars to show up right alongside your Drupal content in a calendar view? There's a module for that.
- Module name/project name:
- Brief history
- How old: created just last month, August 19 2026, by fabianderijk of Finalist
- Versions available: 1.0.0, which works with Drupal 11
- Maintainership
- Brand new - the first and only release is from last month, and the whole commit history is basically launch day
- Security coverage: brand new, so not yet
- Test coverage: yes, both unit tests and kernel tests
- Documentation: a genuinely thorough README - it walks through privacy, the config guard rails, and three different ways to customize event output
- Open issues: none yet, it's less than two weeks old
- Usage stats:
- Too new for a site count
- Module features and usage
- With this installed, it adds the signed-in user's Microsoft 365, or Outlook, calendar as an extra event source on a FullCalendar view - so their personal appointments sit right next to the Drupal content the view already renders
- It leans on the Microsoft 365 Connector module and its SSO submodule, plus the FullCalendar module. Each user must have signed in through Microsoft 365 SSO: anyone who hasn't just sees no events, which is a clean fallback
- It uses lazy loading, so it only fetches events in the date range the calendar is currently showing, not your whole calendar
- Privacy is baked in: anything marked private or confidential in Outlook is masked, so it shows up as just "Busy", with no title, location, or meeting link, unless the site builder deliberately turns masking off
- The response itself is per-user and marked private, no-store, so it never lands in a shared or CDN cache
- There's a clever server-side cache too: it stores the raw Graph response before masking, so a single fetch can serve several displays that each have different masking settings
- You get guard rails you can tune with Drush or an admin form: max events, max date range, cache lifetime, and a separate, shorter failure cache
- That failure cache is a nice touch - if there's no active Microsoft session, or Graph errors out, it caches the empty result briefly so a broken connection doesn't get re-polled on every single calendar click
- Under the hood it calls Graph's calendarView endpoint rather than /me/events, which means recurring meetings get expanded into their individual occurrences - exactly what a calendar grid needs
- Every event carries CSS classes for its status - busy, free, tentative, out-of-office, working elsewhere, cancelled - so you can style them however you want
- And if CSS isn't enough, there's a server-side alter hook and a JavaScript pre-build event for fully custom rendering. Nice detail: the hook is explicitly guarded so you can't use it to put back a title or location that masking just stripped out
- Clearly this will be more useful for edge cases, for example an intranet, but I think this is a really interesting example of the power of Drupal as an integration layer, or as some like to put it, the "glass" through which a user can interact with multiple systems
03 Sep 2026 6:00pm GMT
Matt Glaman: Making the phpstan-drupal playground work for agents
The phpstan-drupal playground exists to reproduce bugs. You paste PHP, run PHPStan with phpstan-drupal against a real Drupal core install, and share the result link in an issue.
It never quite worked right, and I never got around to fixing it. The bugs were small, individually boring, and always someone else's turn on my list. What finally cleared them was working through them with an agent, which is also how the rest of this post happened. The workflow still assumed a person in a browser. Now it works for an agent too.
Two things I wanted:
03 Sep 2026 6:00pm GMT
Drupal AI Initiative: Two Keynotes, One Question: Building Through Disruption at Drupal GovCon
Author: Martin Anderson-Clutz. Originally posted on The Acquia Blog.
Two GovCon keynotes came at disruption from opposite ends. Read them together and you get a map of the moment Drupal is in.
Earlier this month, I spent some time at Drupal GovCon, and a striking element was how well the two keynotes fit together. They were pitched under the same banner - "Building Through Disruption" - but they came at it from opposite ends. Mike Madison talked about how disruption can be something you do, on purpose, to make your team better. Kerry Greer reminded us that disruption is also something that happens to people, and that holding a team together through it is real work that rarely shows up on a ticket. Put those two talks side by side and you get something close to a complete picture: the courage to lead change, and the care to make sure nobody gets left behind while you do it.
I want to walk through both, because I think the Drupal community needs both right now.
Mike Madison: disruption is a verb
Mike (a former Acquian, now Senior Director of Global Web at Zscaler) has spent much of his career being paid, in his words, to "professionally disrupt organizations." His whole framing was a permission slip. When we talk about disruption in business we tend to reach for the giants: Netflix, Airbnb, Uber. And that framing is paralyzing, because none of us is going to reinvent a multibillion-dollar industry over lunch. So Mike flipped it. Think small. Disruption, boiled down, is just "replacing an old way of doing something," and every person in the room already has the standing to do that on their own team.
Every person in this room has the ability to go and disrupt your team or your organization in a meaningful way - and you can do that without pissing everybody on your team off, if you do it right.
His recipe was almost aggressively simple. Four steps: have an idea, figure out how you will change it, convince somebody it is a good idea, and then (the hard part) actually go do the thing. He was honest that the last step is where most of us fail. Ideas are cheap; we all have the brilliant one at breakfast that is gone by bedtime. Doing the work is what separates change from complaint.
A few of his points stuck with me. One was where to find your ideas: "channel your inner hate." The stuff that drives you nuts at work, the things that keep you up at night: that is the gold mine, because you already care enough to push. Another was a caution from science-fiction writer Isaac Asimov: it is easy to predict the car, but hard to predict the traffic jam. Even a great change has unintended consequences, and that is fine, as long as you are watching for the traffic jams.
The part most relevant to us as a technology community was his argument against standing still. He put up the most popular programming languages from 2005, when he started, with PHP sitting proudly near the top - and then watched it slide down the list decade by decade, ceding ground the whole time. His point was not that PHP is doomed; it was that the teams with the most experience are too often the ones least willing to change, and that "what goes too long unchanged destroys itself," as Ursula K. Le Guin put it. The antidote is deliberate: budget time for continuous improvement, kaizen, the way you would budget for meetings or security work. Do not wait for permission to get better.
And crucially, he was clear that driving change is a social act, not a heroic one. The story he told to prove it was about being an intern at a national lab, convinced they were using the wrong tool for the job, and knowing that the intern standing alone in front of a room of senior engineers was going to lose. So he spent a year finding allies - people with the tenure and technical credibility he did not have yet - and when the real decision came, it was not him making the pitch. It was a room full of respected voices backing the idea. That lab runs on Drupal today. His takeaway: right idea, wrong timing or wrong messenger, and nothing happens. Change is something you build with other people or not at all.
Kerry Greer: the invisible work
Kerry has been in the Drupal community for around two decades - a lineage that runs back to the early federal adopters - and she is now an account director at Forum One. Where Mike talked about disruption you choose, Kerry talked about the disruption that arrived uninvited. Over the past couple of years, the ground shifted for a lot of people who build for government: a new administration, workforce reductions, changing contracts and priorities, and AI landing on top of all of it at once. For many of her colleagues and friends, that was not theoretical. People lost jobs. Teams reshaped overnight.
Her question was different from Mike's. Not "how do I change things?" but "how do I keep creating when everything around me keeps changing?" And her answer was that the thing that carries a team through disruption is not another tool, methodology, or roadmap. It is what she called the invisible work, or the human architecture - the layer that never gets a Jira ticket.
When disruption hits, you don't have time to build the relationship. You only have time to trust what's already built.
She named five load-bearing principles, and they resonated because she illustrated them with two real projects from the past year, one that went well and one that very much did not. The difference between them, she argued, was not talent. Both teams were made of capable people doing their best in an uncertain moment. The difference was the human architecture that had - or had not - been built before the pressure hit.
Build trust before you need it, because when disruption lands you do not have time to build the relationship; you only get to spend the trust you already have. Create clarity when you cannot create certainty - when a meeting stops making sense, be the person who says so out loud, whether or not that is your job. Do not let the org chart define the team; on her successful project, the person bringing the most clarity was the most junior UX designer on it. Share what you know instead of gatekeeping, because a community that hoards knowledge does not survive disruption. And remember what you are here for: purpose is the thing that does not move when people, roadmaps, and org charts do.
She grounded all of it in who the work is actually for - the single parent trying to renew a license at the DMV with sick kids in the back seat, the family that needs to know there is a bear in their Yellowstone campground. Government does not get to stop building. When someone asked her about AI displacing the human connection, her answer was steady: AI is another tool, like Google or Word or Excel before it, and it will change some jobs - but humans have to stay in the loop, "especially in government," because the public still needs accurate information from something they can trust.
Why this is the conversation the Drupal community needs
Together these two talks are more useful than either alone. Mike hands us the agency to lead change; Kerry reminds us that leading change without tending to people is how projects quietly fall apart. And this is exactly the moment the Drupal community is in. Every team I talk to is being asked to meet familiar challenges - and some new ones - with fewer resources and, in some cases, unfamiliar tools. That is Kerry's disruption and Mike's opportunity at the same time.
Here is the optimistic part, and I do not think it is wishful. On the technical level, Drupal is unusually ready for this moment. Many of the decisions this community made years ago - treating structured content, configuration, permissions, and workflow as first-class, exportable things rather than logic buried in code - turn out to be exactly what makes a system legible to AI agents. We have been doing the unglamorous governance work for a decade, and it is about to pay off.
We are also finding new ways to embrace change as a project, not just as individuals - which is really Mike's "do the thing" and Kerry's structured collaboration operating at community scale. The Drupal AI Initiative is the clearest example. Rather than letting work this important languish or fall victim to bikeshedding, it is structured as a funded initiative with dedicated contributors, and it keeps adapting its own shape to match what the market actually needs. That recently meant splitting into two complementary tracks. Inside AI is building what partners literally ranked as their priorities - AI search first, then content review, translation, and chat-driven editing - all working together on one real, multilingual site rather than a scatter of demos. Outside AI is tackling agent experience: making Drupal "legible, callable, safe, and verifiable" for the agents that will increasingly build on our behalf, so that our decades-old advantage in governance-as-data is something agents can actually reach and trust. Both are aiming to prove the path - not just claim it - at DrupalCon Rotterdam, including at the AI Dev Summit and Enterprise AI Summit.
Notice how neatly that maps to what Mike and Kerry each described. The initiative is a room full of people choosing to disrupt an old way of doing things and then doing the hard, unglamorous work of shipping it. And it is doing so through exactly the human architecture Kerry championed: shared knowledge instead of gatekeeping, clarity of purpose, and a structure that lets contributors lead regardless of where they sit on any org chart.
So here is where their insights brought me, and it is the note I want to end on. Disruption is not something happening to the Drupal community. It is something we are equipped to lead - technically, because of choices we made years ago, and culturally, because we know how to build with each other. Mike is right that we are all more capable of driving meaningful change than we think we are. Kerry is right that the most important thing we build is not software; it is the trust and the people that make the software possible. Hold both, and this is a moment to be excited about. We get to help write what comes next, and we get to make sure that as it changes, nobody gets left behind.
03 Sep 2026 5:02pm GMT