29 May 2026

feedDrupal.org aggregator

mark.ie: My LocalGov Drupal contributions for May 2026

My LocalGov Drupal contributions for May 2026 markconroy

29 May 2026 11:50am GMT

28 May 2026

feedDrupal.org aggregator

A Drupal Couple: Why I Believe in Agentic Recipes

Image
Imagen
A hand draws a glowing warm-gold path through layered teal digital wireframes, illustrating an orchestration plan threading through complex AI tooling.
Article body

I built my AI tooling first to help me work on Drupal projects and sites, and on the Claude Code plugins I develop. My wife uses the same tooling in her job now, which is the part that turned a personal hack into something I had to actually maintain.

I built it because two things were unreliable. The AI was not always following instructions in CLAUDE.md, and I was cutting steps. Anthropic's own docs are honest about this. They call CLAUDE.md instructions advisory, and hooks deterministic. That is the precise version of what I was feeling. Reading a rule and following a rule are not the same thing, for an AI or for a tired human. So I built tooling around the places where the gap mattered most, one piece at a time, because each piece came from something that had just broken.

Scope, eventually

Scope is the first step in my workflow now, but it was not the first step I added. It became the first step after I watched the AI solve a different goal than the one I had asked for, over-engineer changes that did not need engineering, and reach for the wrong abstraction often enough that I needed a step that just stopped the work and named what we were actually doing.

Scope is not necessarily specs. Specs are how. Scope is what we are even doing here, and what we are not doing, and what counts as done. Now it runs before anything else, and short alignment checks ride along through the later stages so the agent does not drift back into its own version of the goal.

I was surprised by how often the first sentence I wrote into scope made me realize I had been about to build the wrong thing.

Research, and the guides

Research came next. I started with local frameworks for the Drupal work I do a lot of. ECA module workflows. AI module pipelines. Each framework grew the way these things grow, full of decisions I had made and forgotten and made again differently. Eventually the frameworks got too big to share with my wife. She would not have read them, and I could not have pointed her at one piece without dragging in twenty others.

So I broke them apart. One decision per file. One question, one answer. Published online so we could both reach them from any project, and so the agent could fetch only what the current task needed. That is the atomic guides. Around 1,600 of them now, across 88 topics, with routing metadata that lets the agent decide which one to read for which question.

That worked, until I noticed the AI was missing pieces. Not in the small guides. In the structured ones, the ones with sequences and decisions. When you ask the AI to read a guide via WebFetch, the content gets summarized on the way in. Some steps survive. Some get described in vaguer language. Some get dropped. The agent does not know which is which.

So I forced curl. Bytes in, bytes read. No summarization layer between the agent and the content. The skill that fetches my guides is built around this rule, and three different places in its prose remind the agent why curl is mandatory. The rule is enforced by the skill, not by a hook, but the skill is invoked on every fetch, so in practice it holds.

Design, implementation, and a lot of review

After scope and research came design and implementation. The patterns here are well-trodden. Phase the work. Set acceptance criteria before writing. Test first when the test is cheaper than the code it is checking. Ask the human at each step that is hard to reverse. Nothing original. The win is consistency. The AI does not do this on its own unless I make the workflow visible, so I made it visible.

Then I added review. Seven validators, each running against the diff and writing an audit. TDD checks tests came first. SOLID and DRY catch the structural drift. Security scans for the mistake classes the AI is good at making and humans are good at missing. The guides validator checks the work against the atomic guides cited in design. Visual regression and visual parity catch the rendered-output drift the other gates would miss. I added them because passing tests and good code are not the same thing, and I have shipped enough clean-looking diffs with hidden problems to know the difference.

Opinions, and the playbook

Then I realized I needed opinions in a form the framework could carry. Some opinions are rules. Use drush commands, not raw PHP, when you need to do something to Drupal from the command line. Use Composer in the right order when you remove a module. Mobile-first breakpoints with sizes-based responsive images for content body, breakpoint-based for art-directed hero. Rules. One rule, applied across many contexts.

I called this layer the playbook, at the project level. Local rules always win on conflict. Published sets you can subscribe to for the patterns you keep using across projects. That worked. The agent stopped reaching for raw PHP when drush was the right tool, and stopped picking breakpoint-based responsive images for body content where sizes-based was the cleaner answer.

The wall

Working on the biggest tool I am still building, the one that takes a brand definition and walks all the way to an implemented app, I hit a wall I had to name.

Use drush is a playbook instruction. It is a rule about how to do a class of things in this project when I am using Drupal. That shape is fine. The playbook holds it well.

But how to wire responsive images is not a rule. It is directing the orchestration of a specific goal in Drupal with AI. The first is a single instruction, applied widely. The second is a plan for a named capability, applied once, end to end, with project-specific choices baked into the middle of it. Both are opinions. They are not the same shape.

I had no artifact for the second one. The playbook covers pieces. There is even an entry called responsive-image-sizing-per-context, which is a real rule that applies in a real way. But the end-to-end orchestration of wire-responsive-images-for-this-project lives in chat threads, where I walk the agent through the project's image strategy by hand. 16:9 at full width for a hero. 16:9 in a card, same ratio but a different image style because the rendered size is different. 4:3 portrait somewhere else. Every project has its own strategy, and the agent has to translate it into image styles, breakpoints, and field display assignments per view mode per content type. I keep saying roughly the same sequence with slightly different wording, and the agent keeps doing roughly the same thing with slightly different quality.

The same gap shows up in other places. Drupal has a declarative SEO recipe that installs the modules and sets reasonable defaults, which works well on projects where the defaults match what you need. But on a project where the team wants separate fields for metatag, Open Graph, and Twitter cards per content type, the declarative recipe cannot make that decision for you. Something has to direct the orchestration for that project's specific shape. A Next.js front-end wired to a Drupal back-end is the same story. Atomic guides cover JSON:API, decoupled menus, content routing, and the end-to-end procedure with this project's choices has no artifact home. The wall is not specific to images. It is the orchestration shape itself.

Recipes

Hence recipes. Not a guide, because guides are atomic and a recipe carries orchestration over multiple atoms. Not a playbook entry, because that is a single rule, and an orchestration is by definition more than one decision. Not a skill, because a skill is something the AI installs, sitting in the agent's front-matter for every session, whether this project needs responsive image wiring or not. A recipe is something the agent reads when this project needs this capability, and skips otherwise.

The mental model is straight. The first ten lines describe the feature, like a skill's frontmatter, so the agent can read just that and decide whether to keep going. Roughly:

---

recipe: responsive_image_wiring

describes: Wire Drupal responsive image styles, breakpoints, and field display modes from declared image use-cases per content type.

applies_when: project has image fields rendered across multiple breakpoints, art direction or resolution switching, or both.

requires: image, responsive_image, breakpoint

produces: image styles, responsive image styles, field display config per view mode per content type

---

Below that header, the body. The opinion (how we do it, what we refuse to do). The sequence of steps, each citing its atomic source so the agent fetches the decision rather than guessing it. The data flow from the declared inputs to the applied Drupal state. The repetition pattern (once, per content type, per view mode). The contract for what state the recipe reads before it acts. References, with the curl rule honored, so the agent reads bytes and not summaries.

Load on demand. Not installed. Updated when the modules and core the recipe sits on move, because I have been refining my atomic guides by hand long enough to know the same maintenance applies one layer up. I am wiring the update automation into my own setup right now, but the format is what matters. The format has to allow that automation for anyone who wants to build it, not depend on any one person owning it.

I do this in Drupal because Drupal is my community. The pattern is the same anywhere there is a stable capability layer above atomic APIs. Next.js. Rails. Design systems. Anywhere the orchestration of a named feature is repeatable but the choices inside it are project-specific.

I am sharing this to see if it resonates. I built each layer of my tooling because something was breaking when I did not have it, and recipes are the latest piece in that sequence. Orchestration plans for named capabilities. Loaded on demand. Not installed. I would like to know whether other people running AI on real projects are hitting the same wall, the one where you can feel the difference between a rule and an orchestration but you have no artifact to hold the second one. If you are hitting it, I would like to hear from you.

Author
Abstract
I built my AI tooling one layer at a time, each piece added because something was breaking when I did not have it: scope, atomic guides, the curl rule, validators, the playbook. Working on the biggest tool I am still building, I hit a wall I had to name. Use drush is a rule. Wire responsive images for this project is an orchestration. Both are opinions, but they are not the same artifact shape. This post walks that journey to the layer I think is missing, and asks whether other people building AI tooling on real projects feel the same gap.
Rating
No votes yet

Add new comment

28 May 2026 5:22pm GMT

Smartbees: Custom Autenti Integration for WooCommerce

See how we seamlessly integrated WooCommerce with the Autenti system without affecting the checkout process.

28 May 2026 12:04pm GMT

27 May 2026

feedDrupal.org aggregator

Evolving Web: Bringing climate data to life through data exploration

Climate data are shaping decisions everywhere, from infrastructure and public health to agriculture, insurance, emergency preparedness, and urban planning. Yet despite the growing importance of this information, climate data can still be surprisingly difficult to use.

The challenge is not a lack of science. In many cases, the problem is the opposite: there are an overwhelming amount of data available. What's often missing is an experience that helps people explore and understand complex information in ways that feel approachable, intuitive, and useful.

Together with Luqia, we redesigned the ClimateData.ca platform around a simple but important idea: climate data become more accessible when people can explore them for themselves. Rather than treating information as something users simply download or read through, the new platform encourages interaction and discovery through maps, filtering tools, and guided exploration.

The goal was never to simplify science. It was to make navigating climate data feel clearer, more intuitive, and more connected to the real-world questions people are trying to answer.

What is ClimateData.ca?

ClimateData.ca is a free, bilingual platform that gives Canadians access to climate projections and historical data to support real-world decision-making.

At its core, it is a data visualization and download platform. You can browse interactive high-resolution maps, filter by sector or variable, explore graphs, and download raw datasets for your own analysis. The platform also includes educational materials and guidance on how to use climate information in decision-making.

Screenshots from the Climate Data website
A collection of ClimateData.ca interfaces highlighting interactive climate maps, dataset selection tools, and educational resources for exploring climate projections across Canada.


Why it matters: Canada is warming fast

Canada is warming, on average, twice as much and twice as fast as the rest of the world. In Northern Canada, it's happening even faster (Canada's Changing Climate Report, ECCC, 2019). Across the country, the effects are already measurable: more extreme heat, shorter snow and ice seasons, earlier spring peak streamflow, thinning glaciers, thawing permafrost, and rising sea levels. All sectors of society and the economy are at risk, and further warming is described as effectively irreversible. The case for better data infrastructure is built into the science itself.

Feature focus #1: The Learning Zone

The Learning Zone on the Climate Data website
The Learning Zone offers accessible educational content that helps users understand climate science and climate change concepts.

A key feature on the Climate Data platform is its Learning Zone, a filterable library of resources designed for users at every level and across sectors. A planner, engineer, health professional, educator, or community organization may come to the platform with very different questions, levels of technical knowledge, and regional concerns. The redesigned Learning Zone gives users a more accessible entry point into the science before they move into maps, datasets, or projections.

Content types include videos, podcasts, interactive tools, articles, case studies, sector overviews, and regional profiles. Resources can be filtered by region (Atlantic, North, Ontario, Pacific, Prairies, Québec) and technical level.

Feature focus #2: Seasonal to Decadal forecasting

Climate data are most useful when they help people understand patterns rather than react to isolated events. Conditions naturally shift from season to season, year to year, and decade to decade, shaped by factors like ocean-atmosphere cycles, volcanic activity, and broader climate trends. El Niño and La Niña are familiar examples: these recurring patterns can influence temperature and precipitation in a given season or year, including during El Niño conditions like those forecast this year. That variability is part of what makes climate information complex: a single warm season or cool year can stand out, but it does not always tell the full story.

Historical reference periods give users a more stable baseline for interpreting what they are seeing, whether they are looking at recent conditions, short-term forecasts, or longer-term projections. In the Seasonal to Decadal (S2D) tool, forecasts are shown against the 1991-2020 historical reference period, helping users understand whether projected conditions are likely to fall above, below, or near a recent baseline rather than viewing them in isolation.

The underlying data come from CanSIPSv3 (the Canadian Seasonal to Interannual Prediction System, version 3), developed by ECCC. It uses two coupled atmosphere-ocean-land climate models (CanESM5 and GEM5.2-NEMO) with an ensemble of 40 model simulations. This forecasting layer bridges the gap between short-term weather forecasts and the longer-horizon multi-decade projections the platform is better known for.

Feature focus #3: The Maps tool

The Climate Data maps tool
Interactive climate maps allow users to explore projected temperature changes across Canada under different emissions scenarios and future time periods.

We redesigned the platform's interactive maps tool to shift from a download-focused experience to an exploratory one. Rather than treating climate data as something users simply retrieve and interpret elsewhere, the interface is built to support comparison and discovery directly in the browser.

The maps tool covers more than 45 climate variables, including specific indicators such as Hottest Day, Frost-Free Season, Cooling Degree Days, and Freeze-Thaw Cycles. Users can compare emissions scenarios side by side, switch between projected change and absolute values, and navigate data through multiple geographic views (watersheds, health regions, census subdivisions, and grid cells) depending on the context of their work. The front end is built in React, designed to keep interaction smooth as users move between datasets and scenarios.

That geographic flexibility matters because different users approach climate impacts differently. Infrastructure planners, public health teams, researchers, and policy makers often need completely different spatial perspectives and levels of detail from the same underlying data.

Climate Data maps tool variables
ClimateData.ca combines detailed climate indicator explanations with visual browsing tools to help users explore projected climate impacts.

The data behind the platform

The platform's projection datasets are built on rigorous scientific foundations. The primary future projection dataset, CanDCS-M6, shows how temperature and precipitation conditions may change across Canada under four possible emissions scenarios. It uses data from 26 climate models and maps results at a relatively local scale, with grid cells of about 6 by 10 kilometres. A companion dataset, CanDCS-U6, covers three emissions scenarios across the same 26-model suite.

The platform also includes more specialized datasets for climate-related risks, including drought, extreme heat and humidity, sea level rise, coastal infrastructure planning, and extreme rainfall. These help users move from broad climate projections to more specific questions, such as where drought stress may increase, how often heat may become dangerous, how coastal infrastructure may need to adapt by the end of the century, or how stormwater systems should be designed for heavier rainfall.

All datasets go through a formal evaluation process before being added to the portal. Every step involves representatives from all partner organizations, and respects strict data standards.

Who built ClimateData.ca?

ClimateData.ca is a collaborative product involving several of Canada's leading regional climate organizations: Ouranos (Québec), the Pacific Climate Impacts Consortium (PCIC), the Prairie Climate Centre, ClimateWest, CLIMAtlantic, and ORCAA-CRACO. Evolving Web built and maintains the platform alongside Luqia (formerly the Computer Research Institute of Montréal, CRIM), with overarching support from ECCC.

Climate Data regional groups
The platform helps users find regional climate information through partnerships with climate organizations across Canada.


The bottom line

ClimateData.ca doesn't promise simple answers. Climate projections are probabilistic, scenario-dependent, and require careful interpretation. What the platform does offer is something genuinely valuable: a single, well-documented, freely accessible place where any Canadian can engage with the best available science on how their local climate is likely to change.

Given that Canada's own national climate report describes further warming as effectively irreversible, and that every sector of the economy faces risk, that kind of infrastructure matters, now more than ever.

Mobile screenshots of the Climate Data website
A visual overview of ClimateData.ca showcasing climate maps, learning resources, and tools that support climate resilience and informed decision-making in Canada.


Get in touch

If your organization is working with complex data and looking for ways to make it more accessible, interactive, and useful, we can help. From interactive maps and data-rich platforms to visualization tools and UX strategy, we work with organizations to create experiences that help people explore and understand information more effectively.

Get in touch to learn how we can help bring your data to life.

+ more awesome articles by Evolving Web

27 May 2026 8:07pm GMT

LakeDrops Drupal Consulting, Development and Hosting: For Everyone: In-Context Customization Without the Learning Curve

For Everyone: In-Context Customization Without the Learning Curve

Modern lightning bolt icon on clean background, representing instant power and accessibility. A smoking cloud above it indicates the revolutionizing effect this brings with it.

Jürgen Haas

ECA's in-context customization removes the learning curve barrier. A lightning bolt icon appears next to form fields with applicable templates. Click it, select a template, configure parameters - done. No need to understand events, conditions, or tokens. Templates are ECA models with special template tokens that define where they apply and what users can customize. Technical users can transition directly to the full modeler from context. The result: automation and site customization become accessible to everyone, not just developers. Build templates once, apply them dozens of times across contexts.

27 May 2026 1:00pm GMT

Tag1 Insights: Drupal AI Summit NYC 2026: A Community Coming Together Around AI

Tag1's Creative Director/Creative Strategist, Pilar Belhumeur, attended the Drupal AI Summit NYC 2026, which was a full day of talks, demos, and conversations about where Drupal is headed in the age of AI. Here she shares the key themes that emerged, from Drupal's role as an AI orchestration layer to the community's commitment to building a responsible, human-centered AI future.

The Drupal AI Summit in New York City brought together developers, strategists, designers, and agencies for a full day of talks, demos, and conversations about where Drupal will go next in the age of AI. What struck me most wasn't any single talk or demo, it was the common belief that the Drupal community needs to come together to shape this future responsibly.

Here are the core themes, and the talks that stood out.

The Big Picture: Drupal as an "AI Harness"

Matthew Saunders kicked off the day with a framing that anchored everything that followed: "Drupal is becoming an AI harness." As organizations move AI from experimentation into practical operations, the focus should shift from which AI model is used to the system that orchestrates and governs those models.

An AI harness, as Saunders defined it, connects models to essential organizational requirements: structured data, governance, human oversight, and workflow automation. With 25 years of experience managing structured content, APIs, and permissions, Drupal is positioned to act as that operational layer.

Saunders also highlighted the Drupal AI Initiative - a community-led effort with 30+ partner organizations focused on coordinating responsible AI capabilities and avoiding vendor lock-in through community-driven innovation. A core value of the summit, repeated throughout the day, was the importance of a "human × AI partnership" - ensuring AI augments professional expertise rather than replacing it.

What the Industry Is Aligning On: Key Themes from the Drupal AI Summit

These were just a few of the ideas surfaced during the sessions:

Vibecoding for prototypes, Drupal for systems that last. Josh Koenig cautioned that while generative AI can rapidly build websites and democratize web creation by allowing users to assemble functional interfaces without traditional development hurdles, "vibe coding" often lacks long-term maintainability, governance, and structural integrity. The result is frequently "spaghetti code" that becomes difficult for teams to manage as projects grow in complexity. This is where Drupal can shine. The takeaway: use AI to prototype fast, but use Drupal to build systems that last - sustainable, reliable, and integrated into existing professional workflows.

Orchestrating autonomous agents. The future, according to Koenig, lies in turning AI into a teammate. Today's AI-driven web development is largely a "single-player" experience - just an individual talking to a computer. The next chapter is about building orchestrated workflows where multiple stakeholders collaborate within a controlled environment, ensuring consistency across a large ecosystem of websites. Drupal is well-positioned to be that orchestration layer - not just a platform with AI features, but an AI-friendly ecosystem that supports protocols like the Model Context Protocol (MCP), allowing it to act as a structured source of content and context for external AI agents.

Context-driven AI. Without structured context, AI outputs are off-brand, non-compliant, or just generic - what Kristen Pol memorably calls "AI slop." As Pol put it, context is the difference between "AI that guesses" and "AI that gets it." Her project, the Context Control Center (CCC), also known as the AI Context module, provides a centralized hub within Drupal to capture and manage an organization's rules, policies, and guidelines, then map them directly to AI features. Instead of relying on vague prompts or scattered style guides, CCC treats context as managed content - with familiar Drupal capabilities like revisioning, scheduling, and scoping by workflow, language, or site section. That means an organization can declare rules and have them applied consistently across every AI output.

From UX to AX (Agent Experience). Brands now need to design experiences not just for humans, but for the AI agents acting on their behalf. As more website traffic comes from AI agents and crawlers rather than human visitors, organizations have to think about how their content, components, and APIs are "consumed" by machines - and how to ensure brand voice, accuracy, and trust are preserved when an agent is the one mediating the experience.

Data sovereignty and trust. Particularly relevant for the public sector, Amazee's Jeroen Spitaels emphasized guarantees of no data retention and no training on user data as essential for public sector institutions. For governments, universities, and any organization handling sensitive information, it's not enough for AI to be powerful - it has to be trustworthy, transparent, and sovereign. That means knowing exactly where your data lives, who has access, and being certain it isn't quietly being used to train someone else's model.

Where It Got Specific: Sessions Worth a Closer Look

Every summit has sessions that move beyond the conceptual and get specific. These three stood out because they tackled the operational realities of actually deploying AI - and what it takes to do it well.

The Actual Playbook for Deploying AI without Breaking Trust

John Doyle's session on implementing AI teams and workflows was one of the day's standouts because it tackled the operational reality of AI - not just the tech.

His core idea: stop thinking about AI as isolated prompts and start building "digital teammates" - governed agents with defined owners, SLAs, and clear inputs and outputs. That's a profound reframing. A digital teammate isn't a tool you use; it's a team member you onboard, manage, and hold accountable.

Doyle made a strong case for Drupal as the ideal platform for AI orchestration thanks to its API-first architecture, structured content model, and workflow states. He demoed AI integrated directly into a Drupal interface, generating content drafts based on predefined project briefs and design systems.

His operational advice was refreshingly grounded:

This is exactly the playbook organizations need if they want to actually deploy AI without breaking trust. At the end of his talk, I was able to speak with him, and he mentioned they had piloted this approach at Digital Polygon, and it was very successful.

What a Real AI-Powered Website Experience Actually Looks Like in Practice

John Tran, CTO of Image X, delivered the kind of real-world example I wanted to see. His session detailed how Drupal can be transformed from a static content management system into a dynamic, AI-orchestrated experience platform using AG-UI (Agent-to-User Interaction).

The technical foundation is semantic search - using embedding models and vector databases to map relationships between content, focusing on intent, context, and meaning rather than keywords. That allows the system to retrieve highly relevant information even when the user's phrasing is conversational.

The proof-of-concept for an advanced implementation of an AI chatbot was great to see. The system:

Tran's future vision is for Drupal to handle the orchestration of these experiences natively - moving away from rigid, pre-built pages toward fully dynamic, component-based websites where the entire site experience is generated or assembled on-the-fly based on the user's specific goals, all while maintaining site governance and using standard Drupal form-handling workflows.

Just as importantly, because the AG-UI toolkit is agent-agnostic, it prevents vendor lock-in - allowing developers to switch between LLM providers or agent frameworks without rebuilding the front-end experience.

This is what "richer interactivity" looks like in practice. It's still a chatbot at its core, but with a level of engagement and contextual awareness that genuinely solves problems rather than just answering questions. This felt less like a novelty and more like a higher-order assistant doing meaningful work.

Three Capabilities Your Platform Needs for an AI-First Internet

The Acquia session from Martin Anderson-Clutz framed something every digital team needs to wrestle with: in the evolving role of websites and an AI-first internet, content has to go everywhere - not just to your website, but to AI crawlers, agents, and downstream experiences you don't directly control.

To meet that reality, Anderson-Clutz advocated for three keys to a modern DXP:

Agile Content Engine. Beyond traditional drafting and publishing, organizations need to use AI to accelerate planning and ideation, optimize content post-publication for conversion, and embrace structured content in formats like JSON and Markdown for true omnichannel delivery.

Robust Experience Layer. As users increasingly turn to websites to validate purchase decisions rather than for education, the site's role shifts toward frictionless brand onboarding (social proof, case studies, technical specs) and context-aware AI that keeps brand voice accurate, on-brand, and aligned with strategic objectives.

Agent-Friendly Architecture. With non-human traffic rising, websites must be built for AI agents as primary users. That means treating "APIs as the new UI" - standardizing on machine-readable formats, adopting emerging agent-to-agent protocols, and designing systems that offer packageable "skills" or recipes for modular, autonomous agent interaction.

His core argument: Drupal is uniquely positioned as a leading, AI-ready platform because of its emphasis on structured content, enterprise governance, and community-driven innovation.

The takeaway: in a world where your content is increasingly consumed by machines before it ever reaches a human, the platforms that win will be the ones that treat AI agents as primary users - and Drupal is already there.

A Community Embracing AI

If one line captured the spirit of the day, it was this: "Drupal has quietly become one of the most AI-ready platforms available."

While much of the AI conversation centers on flashy chatbots and proprietary tools, Drupal has been steadily building exactly what AI agents need to do real work. That's not marketing spin - it's the natural outcome of 25 years of disciplined engineering around content structure, governance, and openness. The very things that made Drupal a leader in the structured-content era are the things AI agents require to operate reliably, safely, and at scale.

The Drupal community isn't just adapting to AI. It's quietly becoming one of the most credible, agent-ready platforms on the open web - and the summit made it clear we're just getting started.

The conversations at the Drupal AI Summit don't end in a conference room. Tag1's AI Applied Series is our ongoing effort to think out loud about what responsible, practical AI looks like in real work, written by the people actually doing it. We invite you to join us there.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

27 May 2026 12:00am GMT

26 May 2026

feedDrupal.org aggregator

Drupal AI Initiative: Keynote Announcement: Peter Hinssen at Enterprise AI Drupal Summit Europe 2026

We are pleased to announce that Peter Hinssen will be the keynote speaker at the Enterprise Drupal Summit Europe 2026 in Rotterdam on 28 September 2026.

Peter Hinssen

Setting the stage

Peter Hinssen will open the summit with a session on how organizations deal with continuous disruption and long-term digital change - a topic he has spent decades researching, writing about, and bringing to stages around the world.

With over 1,500 keynote presentations delivered to Fortune 1000 companies and leading organisations globally, Peter brings a rare combination of strategic depth, clarity, and a dry sense of humour that turns strategy into clarity.

He is also the bestselling author of six business books, most recently The Uncertainty Principle (2025), a guide for leaders navigating what he calls the "Never Normal" - a world where disruption is not an exception but the baseline.

Why this matters for your enterprise

The summit focuses on AI in enterprise environments, where change is structural rather than incremental. Peter's keynote sets the strategic context for the day's discussions across three key themes:

  • AI in enterprise content systems
  • Composable digital platforms
  • Digital transformation in complex organizations

Because in enterprise environments, the question is no longer whether to adopt AI, but how to do it strategically.

Join us in Rotterdam

Enterprise Drupal Summit Europe 2026 brings together practitioners and decision-makers working on AI (and Drupal) at scale.

The program focuses on real implementations, architecture decisions, and operational lessons from enterprise and public sector environments.

A room full of decision-makers, and there's a seat with your name on it.

More information: summit.enterprisedrupal.eu

26 May 2026 2:35pm GMT

Dries Buytaert: Grow the ecosystem, not just yourself

Two figures with walking sticks stand at the entrance of a glowing cave, looking toward a bright path ahead.

In Open Source software, competition works differently than in proprietary software.

Companies compete through their own products and services, but they all depend on the same commons: the software, the community, the project's reputation, and the shared work that helps people trust and adopt it.

That shared foundation creates a different kind of responsibility: sharing a commons means sharing the work of keeping it strong.

The Open Source companies I admire most show up in two ways. They compete on the merits of their own products: features, support, and price. And they help sustain the commons: through code, documentation, security, marketing, events, education, sponsorships, and more.

Judge companies by what they do

Over the past year, Pantheon, one of Acquia's competitors in the Drupal market, has focused much of its messaging on attacking Acquia, including making our private equity ownership part of its story.

I have no quarrel with Pantheon's products or the people who build them. Competition is healthy. My concern is with marketing that attacks another Drupal company, often with misleading or unwarranted messaging.

I've spent nearly twenty years building Acquia through different stages and ownership models. Acquia has grown from a startup into a company backed first by venture capital and later by private equity. Every ownership model creates different pressures, but ownership determines far from everything.

Customers don't choose a platform because of an ownership model. They choose it because it works, because they can get help, and because they trust it will keep getting better.

No one benefits from unwarranted vendor attacks. They benefit when companies build better products, contribute to Drupal, and help more people adopt it.

License permits, stewardship grows

For an Open Source company, the test is not only what they build for themselves. It is what they help build for everyone.

An Open Source license defines what companies are allowed to do. It sets the floor.

Above that floor is a social contract. No one enforces it, but every healthy Open Source ecosystem depends on it.

Stewardship is what companies choose to do beyond the license: contribute code, fund security work, support maintainers, improve documentation, sponsor events, promote adoption, and more.

Drupal thrives because people and organizations honor the social contract and choose to do more than the license requires.

Contribution is one measure of stewardship

Drupal.org credit is one public signal of that commitment. Acquia is the largest single corporate contributor to Drupal, but the wider community contributes far more than any one company.

In the past year, Acquia engineers earned 2,955 weighted credits on Drupal issues, plus 164 from the Drupal Security Team.

These contributions are good for Acquia, for Drupal, and for every organization that builds on Drupal, including our competitors.

In the same period, Pantheon earned 30 issue credits and 2 security credits. Credits don't capture every form of contribution, and Pantheon contributes in other ways too. Even so, the gap is substantial.

What we let pass becomes the social contract

I don't usually write publicly about competitors. It's not how I want to spend my voice.

Before writing this, I asked myself a simple question: if a major company contributing to Drupal were under sustained attack from another major Drupal company, would I feel a responsibility as Drupal's founder and project lead to speak up?

I would.

The fact that Acquia is the company being attacked made me slower to respond, but it doesn't change the answer.

When companies built on Drupal spend their energy attacking each other instead of growing the project, it bothers me. It's not good for Drupal.

I'm not writing this believing it will change anyone's marketing and sales tactics. I'm writing it because what we let pass now will shape what is acceptable in Drupal years from now.

Communities like ours evolve their social contract through moments like this, when we say in public what we expect of each other. If this post contributes to a healthier social contract taking hold, I'm happy.

Compete on merit, but grow the commons

Every company that builds on Drupal depends on the same commons. Every company has a choice about whether to help sustain it, and how much. Drupal gets stronger when more of us invest in it.

My invitation to every company that builds on Drupal is simple: let's compete on the merits of our products and services, not by attacking each other. Let's serve customers well, contribute where we can, and put our energy into helping more organizations choose Drupal in the first place.

That is the social contract I'd like all of us to live by. I want Acquia to be judged by that same standard: what we ship, how well we serve customers, how much we contribute, and whether Drupal is stronger because of our work.

Not by who owns us. Not by claims made about us. By whether we keep building, contributing, and helping the ecosystem grow.

I have said what I wanted to say, and I won't turn this into an ongoing debate or respond to social media comments on this. My focus is on building and contributing.

26 May 2026 1:43pm GMT

The Drop Times: Cybersecurity Pressures Intensify Across Enterprise and Open-Source Ecosystems

Cybersecurity remained a central concern across enterprise and open-source ecosystems this month as multiple high-profile incidents and critical vulnerability disclosures affected widely deployed platforms. Security teams continued to face pressure to patch faster, monitor exposed systems more closely, and respond to a growing volume of actively exploited vulnerabilities.

Verizon's 2026 Data Breach Investigations Report found that the exploitation of vulnerabilities overtook stolen credentials as the leading initial access method in analysed breaches for the first time. Microsoft's May Patch Tuesday also addressed roughly 120 vulnerabilities affecting Office, SharePoint Server, and Windows enterprise infrastructure.

The open-source sector saw renewed urgency around patch management after the Drupal Security Team released SA-CORE-2026-004, a highly critical SQL injection vulnerability affecting supported Drupal core versions using PostgreSQL databases. The advisory prompted emergency patching efforts across enterprise Drupal deployments.

Security agencies continued to warn about the growing number of actively exploited vulnerabilities tracked in CISA's Known Exploited Vulnerabilities catalogue.

Elsewhere in the open-source ecosystem, discussion turned toward the widening gap between technological capability and public perception. In a recent post, Dries Buytaert argued that Drupal's reputation has not kept pace with its technical evolution despite continued investment in structured content architecture, APIs, and AI-oriented tooling.

The discussion reflects a broader challenge facing mature open-source platforms competing for visibility against newer frameworks with stronger marketing momentum. Community perception increasingly shapes how projects are evaluated alongside technical capability, governance maturity, and long-term sustainability.

That said, let us now look at the major developments covered in Volume 4, Issue 21 of The Drop Times weekly newsletter, Editor's Pick. Story listings are now permanently shifted to teaser blocks below, and we will no longer duplicate linked headlines within the Letter from the Editor.

Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.

Allen Jason
Junior Sub-editor
The Drop Times

26 May 2026 12:41pm GMT

1xINTERNET blog: Why 2026 Is the Year for Integration Over Isolation for Membership Bodies

Managing a patchwork of digital systems? Discover why 2026 is the year for membership bodies and charities to trade platform fragmentation for integration.

26 May 2026 12:00pm GMT

Specbee: What should content editors know about Drupal accessibility?

Does your content team know how much Drupal accessibility depends on them? From headings to tables, the choices editors make every day shape whether assistive tech users can navigate your site.

26 May 2026 10:56am GMT

1xINTERNET blog: Why 2026 Is the Year for Integration Over Isolation

Managing a patchwork of digital systems? Discover why 2026 is the year for membership bodies and charities to trade platform fragmentation for integration.

26 May 2026 8:25am GMT

The Drop Times: Johanna Bates on Drupal, Nonprofits, and the Problem of Stewardship

Johanna Bates reflects on Drupal's nonprofit ecosystem, the value of structured content, and the stewardship needed to support contributors, clients, and mission-driven organisations.

26 May 2026 5:00am GMT

25 May 2026

feedDrupal.org aggregator

Talking Drupal: Talking Drupal #554 - Hey! Scott Tolinski!

Today we are talking about Web Education, Level up Tutorials, and life after Drupal with guest Scott Tolinski. We'll also cover Views Row SDC as our module of the week.

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

Topics

Resources

Guests

Scott Tolinski - tolin.ski stolinski

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Bernardo Martinez - bernardm28

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

25 May 2026 6:00pm GMT

ImageX: Deciphering the Acronyms Behind Your Drupal Site: CDN, CTA, NID & More

If your Drupal website spoke in acronyms, it might sound like this: "DNS hands the request to the CDN, TLS encrypts the connection, and the CTA waits patiently at the end."

These clusters of capital letters can feel like jargon and confuse non-technical users. Yet acronyms, words formed from the first letters of longer phrases, are everywhere because they make complex concepts quicker to say and easier to remember.

25 May 2026 12:27pm GMT

Dropsolid Experience Cloud: After the unbundling, the rebundling

AI is unbundling both agencies and software. The rebundling is coming - will it be open or closed? Open platforms offer freedom, sovereignty, and portability.

25 May 2026 8:07am GMT