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.
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
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.
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.
Beyond Table-Based Nightmares: A Technical Deep Dive into Drupal's MJML Render Engineadmin
The Legacy Email Problem: Broken Layouts and Fragile Twig Templates
Within modern web development, generating layouts has transitioned into an era of clean, semantic structures powered by CSS Grid and Flexbox. However, the world of HTML email design remains anchored to late-1990s markup methodologies. This structural regression is driven by the vast rendering discrepancies across various email clients.
While web browsers adhere closely to standardized layout engines, email clients parse markup through vastly different systems. For instance, desktop applications of Microsoft Outlook rely on the Microsoft Word rendering engine, which strips away essential styling rules, including margins, padding, flexbox properties, and media queries. Consequently, developers are forced to design emails using highly nested table structures, inline styles, and obscure conditional HTML elements to ensure layouts do not break upon delivery.
Somewhere out there a vanilla Ægir server is still quietly serving its Drupal sites, years after the person who set it up moved on. The aegir2boa toolset gives these classic estates a supported road into BOA: a read-only preflight which grades your box, an in-place Apache to Nginx flip proven on a scratch port before any handover, and a remote adoption which pauses, dumps, ships and registers each site while the old box becomes a small proxy where putting a site back is one file move. Every acting verb rehearses first, one clean rehearsal buys exactly one live run, and until DNS moves there is a drilled way back from every step; drilled meaning drilled: four full runs on throwaway boxes, an HTTPS estate with a composer platform, a mixed Drupal 6 and 7 estate, an Ubuntu source carried into Percona 8.4, then all of it again into both database generations, on the very tool bytes you would download. Free and open source, and it never asks for root database access on the box it is rescuing.
A weekend fix built for The DropTimes now supports sites its maintainer may never see, bringing the responsibilities of public module maintenance into focus.
A perfectly completed ticket can still solve the wrong problem. Tom Hollevoet argues that better Drupal delivery begins with understanding the need behind the request.
The Drupal Business Survey investigates the trends in the digital market, in particular from service providers involved with the open source Drupal CMS and enterprise platform. Digital agencies from all over the world participate in the yearly survey and the business insights on market share and growth opportunities gained are shared with those who've submitted responses.
Begun many years ago by Drupal Business Network with Janne Kalliola, Michel Van Velde, and Imre Gmelig Meijling, the survey is now administered by the Drupal Association to promote global reach and protect the confidentiality of the information. Moving forward, the Drupal Association will handle the analysis and reporting of the anonymised data from the survey. We're grateful to Janne, Michel, and Imre for their many years of work in shaping and running the survey.
Drupal's open source ecosystem is supported by a strong community of tens of thousands professionals worldwide, working together on the popular digital experience platform. Because Drupal is open source, anyone can work with Drupal or make changes to it. An important part of this community are the agencies that provide Drupal services to end users and drive Drupal's market. The Drupal Business Survey seeks the input from these agencies so that meaningful data for business owners and decision makers can be built into their business strategies.
The Drupal Business Survey has been a valuable guide for digital service providers, even to those working with other technologies than Drupal.
Drupal is the open source Digital Experience Platform used by many organisations worldwide including Nestlé, Lufthansa and World Wildlife Fund (WWF).
Participate and share your insights
Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.
DDEV v1.25.4 is here: 142 PRs from the entire DDEV community. Your suggestions, bug reports, code, and financial support made it possible.
The theme of this release is doing less by hand. A new project can start with a "seed" database you already have, and image and environment customizations can be set globally instead of in every project.
:::note[Linux and WSL2: new package repositories] DDEV's apt and rpm packages are now published to Cloudsmith at packages.ddev.com. Gemfury (pkg.ddev.com) keeps working, so switch over whenever it suits you by re-running the Linux installation steps.
Package repository hosting is graciously provided by Cloudsmith. :::
Table of Contents
Database Seeding and Reset
Until now, a fresh project always started with an empty database, and getting your data back in there meant importing a dump or snapshot every time. DDEV can now automatically use a snapshot, which is far quicker than importing a SQL file.
ddev start --seed-snapshot=<name-or-path> fills a brand-new database from a snapshot in .ddev/db_snapshots, or from a path to one anywhere else on your machine. It works with MariaDB, MySQL, and PostgreSQL.
seed is a reserved snapshot name. Run ddev snapshot --name=seed once, and from then on any ddev delete followed by ddev start brings that database back, with no flag to remember. You can even check .ddev/db_snapshots/seed* into Git if it's not annoyingly large.
ddev start --reset-database throws the current database away and starts over, taking a snapshot first. The flags can be combined (works with both ddev start and ddev restart): ddev start --reset-database --seed-snapshot=large-dataset --omit-snapshot.
Global env files~/.ddev/.env and ~/.ddev/.env.<service> set environment variables for every project. Before this, the only global option was web_environment in ~/.ddev/global_config.yaml, which reaches the web container and nothing else. Now you can do it for db, or any other service:
# Set API_URL for the web service of every project
ddev dotenv global set .ddev/.env.web --api-url=https://example.com
Project env files gained two pieces in their names, too. A trailing .local, as in .ddev/.env.local, tells DDEV to gitignore the file, which is where credentials belong. A label, as in .ddev/.env.web.myaddon, keeps files from different sources apart, so an add-on isn't editing the same file you are.
New Project Types and Shopware 6 Without an Add-on
ddev add-on update updates the installed add-ons that are behind their latest GitHub release, with --dry-run to preview.
ddev utility download-ddev fetches the ddev binaries for a PR, branch, commit, or tag without touching your installed DDEV, which is handy for testing a fix before it ships.
A wrong docroot used to produce a bare 404/403 page with no hints about why. Now ddev-webserver explains the 403s and 404s it generates itself, and ddev-router does the same for a hostname that doesn't match any project:
The page says where it came from, so you know it isn't your application's own 404, and it lists what to check. A 403 or 404 from your own application is passed through untouched.
It also replaces the old "docroot may be wrong" warning on ddev start, which you never saw in a browser and which sometimes fired when nothing was wrong.
Regressions from v1.25.3, Fixed
DDEV v1.25.3 introduced a few problems, and the ones you're most likely to have run into are resolved here:
Project image builds are fast again. Permissions on the Node.js directory were being changed recursively on every build, and are now set once.
Add-ons and applications that write log files straight into /var/log can do that again, after the directory was locked down to root only.
A site that generates its own /robots.txt works again. An Nginx rule was answering before your site could, and it's gone.
Other Fixes Worth Knowing About
ddev wp respects the path in your project's own wp-cli.yml again, falling back to the docroot only when that file doesn't set one. Since v1.24.5 it always added --path=$DDEV_DOCROOT, which broke Bedrock and any layout where WordPress isn't in the docroot.
Running ddev in a subdirectory with its own .ddev/config.yaml, such as a Drupal contrib module or a Git submodule, keeps using the outer project and tells you which one it picked, instead of switching silently and breaking the outer project's custom commands. ddev start there asks first.
Performance Is Measured Automatically Now
A nightly benchmark harness now times ddev start, ddev stop, Mutagen sync-settle, and a Drupal install across the platforms and Docker providers DDEV already tests on, and publishes the results to a performance history dashboard, so a regression shows up as a bend in a trend line instead of a bug report months later. A second dashboard tracks CI test runtime.
Everything Else
This release includes many more features and bugfixes. See the full release notes for the complete list.
From the entire team, thanks for using, promoting, contributing, and supporting DDEV!
If you have questions, reach out in any of the support channels.
If you're amazed by how much is in this release, we are too! If you wonder how all this could be done, it's because of generous sponsors who let two of us work on this every day. If you and your team aren't already financially supporting DDEV, consider joining our sponsors.
Missing image alt attributes cost accessibility and SEO points
Empty alt attributes are an accessibility and SEO killer, and the cost is measurable. Google Lighthouse flags the error on both of its audits: up to 6 points subtracted from the Accessibility score and 8 points from the SEO score.
The impact on real users is worse than the score. A screen reader completely ignores an image with no alt text, so blind users never know the image was there, which makes the experience disruptive and confusing. It also violates WCAG Success Criterion 1.1.1: Non-text Content, the baseline requirement for accessible non-text content.
That is why we had to act when a migration project resulted in thousands of images without an alt attribute.
A Drupal migration left 12,000 images without proper alt text
A Drupal 9 to Drupal 11 migration for a multilingual sports news project surfaced around 12,000 images with missing or incorrect alt attributes, found via Screaming Frog tool. Some images had no alt attribute at all, while others had alt text in the wrong language, with English alt text appearing on the /es version of the site.
The obvious next step was to look for a pattern. Was the issue tied to a specific content type, such as Articles? Was the wrong-language text caused by untranslated Media content? Answering these questions turned out to be surprisingly hard: Drupal provides no default mechanism, no view…
AI traffic is not one thing, and a policy which treats it as one thing gets the answer wrong in both directions. Here the decision is written down, class by class: the crawlers which harvest sites to train models are turned away at the edge before a single line of Drupal or Backdrop runs, while AI search indexers, and the fetch a real person triggers by asking an assistant, stay open and rate-limited per vendor, not per address, because one prompt fans out across dozens of addresses. Every layer ships with the platform and runs on your own server; nothing is rented, and no rule lives somewhere you have no login for. Changing it for one site is one line in a file you own, live in about two minutes, deleted to restore the defaults; and your own policy goes out at /llms.txt straight from the site's files folder. The honest part is the best part: a user-agent can be forged, the maps fail open on purpose, and the docs say where each shield stops and the next one begins.
Who Owns the Icon? Building Author-Friendly Icon Systems in DrupalJoel SteidlDrupal
Icons seem like a small implementation detail until a site has a large design system, multiple authoring workflows, and content that changes independently of the theme.
Then a basic question becomes important: who owns the icon?
For some parts of an interface, the answer is clearly the theme. Alert states, event metadata, and other stable UI patterns should remain predictable.
Other icons behave more like content. Authors may need to choose an icon for a navigation item, card, banner, or other component. In those cases, hardcoding the choice in the theme creates a dependency between content and code that becomes difficult to maintain.
The goal is not to move every icon into Drupal. It is to give the right people control over the right decisions.
Start with ownership
I generally think about icons in two groups: icons whose meaning belongs to a fixed interface pattern, and icons whose meaning belongs to authored content.
An alert is a good example of the first group. Drupal or an author might determine that an alert has a warning status, but the theme should decide which icon represents "warning."
Event metadata works the same way. Date, time, and location have stable meanings within an event teaser. Those icons belong to the component, not to an individual event.
Hardcoding those relationships protects consistency.
A site menu is different. Authors add, remove, rename, and reorder menu items. If an icon describes the purpose of a particular link, it should usually travel with that link rather than with its position in a template.
Component-based authoring introduces the same issue. An author might select an icon for a card or a decorative treatment for a banner. If that component moves or is reused, the visual choice should move with the content.
Most interfaces contain both models at once. A card might have an author-selected icon and a hardcoded arrow that communicates that the card is a link. A menu item might have an author-selected icon on the left and a fixed chevron on the right when it has children.The useful boundary is not Drupal versus the theme. It is which part of the system owns each decision.
When authored icons live in code, things get brittle
Menus make the problem especially visible.
A developer can attach an icon to the second menu item with CSS, but that relationship breaks as soon as an author inserts another link above it. Targeting a specific menu item identifier is more stable, but it still creates a developer-maintained connection between content and theme code.
A select list is another common approach:
For a small icon set, this can be perfectly reasonable.
The problem appears as the library grows. Authors are asked to understand the design system through filenames. The distinction between calendar, calendar-outline, and calendar-filled may be obvious to the developer who added them and much less obvious to someone building a page later.
Adding a new option may also require a theme change and deployment.
From the author's perspective, this is a content problem. From the developer's perspective, it is a theme problem.
Drupal already has a better interaction model for choosing visual assets.
Use Media when the icon is an authored choice
When authors choose an image, we do not normally give them a dropdown containing every filename on the site. Drupal's Media Library gives them visual previews, search, filtering, reuse, and asset management.
That interaction makes sense for icons too.
With SVG Image, SVG files can participate in Drupal's image field ecosystem and can be rendered as image elements or inline SVG markup.
Once icons become Media entities, they can also use Drupal's normal content model. They can have useful names, categories, permissions, and usage guidance. Views and reference configuration can limit which assets authors see in a particular context.
That matters because an icon library is rarely one undifferentiated collection.
Graphical UI icons used in menus or calls to action likely aren't used in the same way more decorative accents are. The overhead of deciding which icon type should be used in which context shouldn't be left to the author if we can provide clear guardrails.
This is where Media becomes more than a nicer picker. It provides a governance model.
Menus can gain Media reference fields through tools such as Menu Item Extras. Component systems based on Paragraphs can attach icon choices directly to the structured component. Style Options - Media Reference provides another way to expose Media selections in component configuration.
The exact implementation will vary by project. The important part is that once an icon becomes an entity, Drupal's existing fields, permissions, and filtering tools can manage it without requiring a custom icon picker.
Keep rendering predictable
Moving icons into Media improves the author experience, but the theme still needs a reliable rendering model.
The rule I use is simple:
HTML chooses the icon. CSS styles it.
Drupal or Twig should determine whether an icon exists and which icon it is. CSS should handle size, spacing, alignment, color, and interaction states.
That separation works particularly well with inline SVG. The SVG can inherit color from the component, respond to interaction states, and remain part of the markup rather than being hidden inside a stylesheet.
It also keeps accessibility decisions closer to the rendered interface. Decorative icons can be hidden from assistive technology, while meaningful controls can rely on appropriate accessible names rather than asking the icon itself to carry all of the meaning.
I previously built a small Twig helper in the Utility Belt module to make theme SVG rendering easier. It solved a practical problem, but Drupal's newer Icon API offers a more standardized direction.
Drupal 11.1 introduced an Icon API that allows themes and modules to expose icon packs through a common rendering system. Contributed projects such as Icon Media Pack are exploring how Media bundles can participate in that model.
That creates an interesting division of responsibility: Media can handle author-facing governance, while the Icon API can provide developers with a predictable rendering path.
There are still exceptions.
Native form controls sometimes need icons as CSS backgrounds or masks because their markup cannot easily contain rendered SVG children. In those cases, keeping a small set of duplicate assets in the theme can be a reasonable tradeoff.
The point is not to eliminate every exception. It is to make the boundary intentional.
Give each part of the system the control it needs
An author-friendly icon system is not one where authors can change every icon.
It is one where authored decisions are actually authorable.
If an icon belongs to a stable interface pattern, keep that relationship in the theme. If the icon represents something an author is creating or organizing, consider modeling that choice in Drupal.
Media can provide the visual browsing and governance authors need. The theme can continue to protect rendering and presentation.
That division is more maintainable than treating icons as entirely theme code or entirely content, and it better reflects how complex Drupal sites actually operate.
Rebuilding a data-driven Drupal site: Migrating page element configuration from Panels to Layout Builder
In the previous post in this series, I described how we rebuilt our ctools page elements as block plugins.
That gave us the new implementations, but not the pages that had already been assembled in Drupal 7. Recreating them manually would have taken a long time and risked losing existing configuration along the way.
We did not want to migrate complete Panels displays. The rebuilt site had its own Layout Builder sections and layouts. We wanted to preserve the page elements, their order and as much of their configuration as the new block plugins could still use.
Publishing one good page is a writing task. Keeping hundreds of pages accurate across products, markets and languages is a systems problem.
Drupal content operations at scale means treating each fact as structured data with relationships, permissions and history, then reusing it across templates, languages, JSON-LD and APIs. Here is how fields, taxonomy, Views and workflows keep large Drupal sites governable when AI-assisted research raises the bar.
This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.
Straight from Ryan's desk
To the Drupal community,
As northern hemisphere summer winds down, DrupalCon Rotterdam is rapidly approaching - and if you haven't booked yet, today is your last chance at Regular pricing. Late Rate kicks in at midnight CEST, so this is my friendly nudge to save yourself €270 and register now.
Rotterdam isn't the only Con on the horizon. DrupalCon Orlando Early Bird registration opens 14 September, and paid Early Bird tickets come with a limited-edition DrupalCon elePHPant - once they're gone, they're gone.
Elsewhere in this edition: the 2026 Drupal Business Survey is open until 7 September (your answers shape where we focus next), the engineering teamhas completed the migration of Drupal's security issue tracking to GitLab, and we're delighted to welcome Janna Malikova to the Drupal Association Board.
As always, thanks for being part of it. See you in Rotterdam!
Ryan Witcombe, Director, Product Marketing
The 2026 Drupal Business Survey Is Open
Your input shapes an anonymized report that helps the whole community. You'll see how your pipelines, win rates, and revenues compare to global peer data, share what's actually working, and directly influence where the Drupal Association focuses next.
Take the surveyby 7 September 2026 at 23:59 UTC. Responses are strictly confidential and fully anonymized. Everyone who completes the survey receives the full report by email.
DrupalCon Rotterdam is almost here
Join Drupal experts and community members to discover what's next for Drupal and the open web, exchange ideas, and build connections across the ecosystem in Rotterdam from 28 September to 1 October.
The regular rate is now closed, but registration for DrupalCon Rotterdam 2026 is still open. Register here.
All You Need To Know About DrupalCon Orlando
Early Bird Registration Opens September 14
The Early Bird registration for DrupalCon Orlando 2027 opens Monday, 14 September 2026 at 8:00 am EST, with tickets available for $650. And Early Bird comes with a special perk. Paid Early Bird DrupalCon tickets include a limited-edition DrupalCon PHP elePHPant named Drupy (Elephpas hypertextus drupalensis primus in Latin), available exclusively during the Early Bird registration period.
Free tickets do not include an elePHPant, but you'll have the option to purchase one during registration while supplies are available.
Choose from six summits tailored to your interests: AI · Government · Higher Education · Nonprofit · Healthcare · Community.
Two summits with special pricing: the Community Summit is free for all DrupalCon registrants, and the Nonprofit Summit is free for Nonprofit ticket holders.
Full-Day Training (Add-on $550)
One focused training on offer: AI Inside Drupal: From Smart Editorial Workflows to Canvas Agents That Build Pages, presented by DrupalEasy.
Community Party + The First-Ever DrupalCon Talent Show
Save the Tuesday night, 23 March 2027, for the DrupalCon Community Party, featuring something brand new for Orlando: the first-ever DrupalCon Talent Show!
It's FREE, and opting in helps us plan for everyone who wants to join us Tuesday night.
More details are coming soon.
Call for Speakers Is Still Open
There's still time to help shape the DrupalCon Orlando 2027 program! We're accepting speaker submissions through 20 October 2026.
Bytes the Gator is making his way around the Drupal community and you can join the fun for a chance to win a free registration to DrupalCon Orlando 2027. Can't attend a Drupal event or find Bytes? Another alligator works too, preferably not a live one!
This month the team completed the migration of Drupal's security issue tracking to git.drupalcode.org, making the volunteer Security Team faster and easier to grow.
The broader issue migration now covers 90,000+ issues across 7,200+ projects. Release packages were re-signed for 3,200+ projects through Rugged, our new package signing pipeline.
localize.drupal.org and jobs.drupal.org have moved to modern cloud infrastructure, and the Drupal 11 upgrade of the new Drupal.org platform is underway.
Next up: porting community events to new.drupal.org so we can retire groups.drupal.org.
The Drupal Association At-Large Board Election Winner Is Announced
We are excited to announce the winner of 2026 Community At-Large Board Elections. We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat.
Somewhere out there a vanilla Ægir server is still quietly serving its Drupal sites, years after the person who set it up moved on. The aegir2boa toolset gives these classic estates a supported road into BOA: a read-only preflight which grades your box, an in-place Apache to Nginx flip proven on a scratch port before any handover, and a remote adoption which pauses, dumps, ships and registers each site while the old box becomes a small proxy where putting a site back is one file move. Every acting verb rehearses first, one clean rehearsal buys exactly one live run, and until DNS moves there is a drilled way back from every step; drilled meaning drilled: four full runs on throwaway boxes, an HTTPS estate with a composer platform, a mixed Drupal 6 and 7 estate, an Ubuntu source carried into Percona 8.4, then all of it again into both database generations, on the very tool bytes you would download. Free and open source, and it never asks for root database access on the box it is rescuing.
AI traffic is not one thing, and a policy which treats it as one thing gets the answer wrong in both directions. Here the decision is written down, class by class: the crawlers which harvest sites to train models are turned away at the edge before a single line of Drupal or Backdrop runs, while AI search indexers, and the fetch a real person triggers by asking an assistant, stay open and rate-limited per vendor, not per address, because one prompt fans out across dozens of addresses. Every layer ships with the platform and runs on your own server; nothing is rented, and no rule lives somewhere you have no login for. Changing it for one site is one line in a file you own, live in about two minutes, deleted to restore the defaults; and your own policy goes out at /llms.txt straight from the site's files folder. The honest part is the best part: a user-agent can be forged, the maps fail open on purpose, and the docs say where each shield stops and the next one begins.
