webjoke.de

It’s not new and it’s not sexy, but Schema.org is getting a lot more attention these days. The reason is AI.

You’ve probably heard that Schema improves your AI search results — apply it to your site and voilà, better results. But what is it? How does it help with AI? And, more controversially, does it actually help at all?

If you’re reading this article online, you’ve already experienced the impact of one of history’s most influential inventions. Chances are you’ve also visited several websites today to check the news, compare products, or fill out an online form. 

This is a guest post from the incredible team at 1xINTERNET, a Top-Tier Drupal contributor and digital agency headquartered in Frankfurt, Germany.

When the Drupal Association announced that 1xINTERNET had become one of the world's Top-Tier Drupal Contributors, it was a proud moment for the company. Reaching the highest level of contribution recognition places 1xINTERNET among a select group of organisations helping shape the future of one of the world's leading open-source content management systems.

Yet, ask anyone inside the company about the achievement, and you'll hear the same response: becoming a Top-Tier Contributor was never the ultimate goal.

Instead, it is the natural outcome of more than a decade of believing that if you build your business on open source, you should help build open source itself.

For over thirteen years, 1xINTERNET has invested in the Drupal ecosystem, not only by delivering digital platforms for clients, but by contributing code, maintaining projects, sponsoring community events, supporting governance, leading strategic initiatives and encouraging employees to actively participate in the community.

Today, the company sponsors more than 500 hours of Drupal contribution every month, actively supports more than 85 Drupal projects, has sponsored over 50 Drupal events, and has contributed to hundreds of issues across the Drupal ecosystem. Those numbers tell one story. The people behind them tell another.

Contribution isn't only about strengthening Drupal, it creates real value for the organisations that choose Drupal as the foundation for their digital platforms. We spoke with Baddý Breidert, Christoph Breidert and James Tillotson about why contributing matters, how it benefits clients, and why they believe giving back is essential to building better digital experiences.

Photo of James, Christoph, and Baddy

Building the future instead of following it

For 1xINTERNET CEO Baddý Breidert, contributing to Drupal has always been part of the company's identity.

"It represents over a decade of dedication to the Drupal project," she says. "I've worked with Drupal since 2006 and been actively involved in the community since 2013. Being recognised as one of the top three Drupal companies globally validates the expertise and sustained effort our team has invested over the years."

But the motivation goes much deeper than recognition.

Instead of simply following the direction of Drupal, 1xINTERNET believes in helping shape it. Since Drupal is the technological foundation behind many of the company's digital platforms, contributing to its future isn't viewed as optional, it's viewed as a responsibility.

That philosophy influences almost every decision the company makes. Rather than waiting for new features, improvements or innovations to arrive, the team actively participates in creating them.

Managing Director Christoph Breidert describes it simply.

"We don't just build with Drupal; we help influence where the platform is going next."

It's an approach that benefits not only the Drupal community, but every organisation that chooses Drupal as the foundation for its digital future.

Open source is built on collaboration

Although contribution often means writing code, the three leaders agree that it's ultimately about something much bigger.

Open source succeeds because thousands of people collaborate, share knowledge and solve problems together. Every contribution, whether it's code, documentation, testing, mentoring, event organisation or strategic leadership, helps strengthen the ecosystem for everyone.

For Christoph, this spirit of reciprocity sits at the heart of open source.

"If you build digital solutions using an open-source project but choose to remain on the sidelines, you miss the opportunity to influence the tools you rely on," he explains. "Open source is built on shared knowledge, and contributing back is simply part of how we work."

That collaborative mindset is equally visible throughout 1xINTERNET's culture.

IxINTERNET’s UK Growth Manager James Tillotson sees open source as an extension of how the company works internally.

"We don't hoard knowledge," he says. "We share it to raise the baseline for everyone, which in turn allows us to keep innovating."

Rather than viewing contribution as something separate from day-to-day work, it's embedded in the way teams learn, collaborate and continuously improve.

Contribution isn't separate from client work

One of the biggest misconceptions surrounding open source is that contribution somehow competes with client work.

The reality, according to the team, is exactly the opposite.

James puts it bluntly.

"Contribution is client work."

When developers fix a bug in Drupal core or improve functionality that thousands of websites rely on, every client benefits, not just today, but for years to come.

Christoph agrees.

"If you're not involved in building the technology, you're always reacting instead of leading."

Technology evolves quickly. Artificial intelligence, digital experience platforms, accessibility, security and content management continue to change at an unprecedented pace. Agencies that simply consume technology are forced to wait for innovation. Agencies that contribute help create it.

Baddý believes that's one of the company's greatest strengths.

"Contribution allows us to lead initiatives like Drupal AI, ensuring we aren't just consumers of the technology but creators of it."

Instead of adapting after the market changes, 1xINTERNET helps shape those changes from within.

Driving innovation through Drupal AI

Perhaps nowhere is that philosophy more visible than in Drupal AI.

As Product Lead for Drupal AI, Christoph has been deeply involved in defining its roadmap, working alongside developers from around the world to build practical AI capabilities directly into Drupal.

For him, watching Drupal AI evolve from an ambitious idea into one of the platform's most exciting capabilities has been one of the defining milestones of the company's contribution journey.

"It's been incredible to collaborate with a global community to build something that will help shape the future of the web."

The significance goes beyond technical innovation.

Because 1xINTERNET helps build Drupal AI, its teams understand the technology long before it becomes mainstream. They know what's coming, how it works and how organisations can use it responsibly.

James, who contributes to the Drupal AI Marketing Initiative, believes this creates a significant advantage for clients.

"Our clients have access to the latest innovations because we're involved in creating them."

Innovation isn't something clients wait for. It's something they experience alongside the people helping build it.

Better contributions create better client solutions

Although many clients may never see the code being contributed to Drupal, they experience its impact every day.

Active contributors develop a much deeper understanding of the platform than those who simply implement it.

Because the team understands Drupal's architecture, roadmap and future direction, they can make better long-term decisions for every project.

"Our clients receive stable and modern solutions without having to manage the underlying complexity," Christoph explains. "By maintaining our contribution status, we act as a direct pathway to web innovation."

That means fewer surprises, more sustainable architectures and platforms designed to evolve instead of becoming outdated.

James believes clients increasingly recognise that value.

"They know we're not simply using Drupal, we're helping steer where it's going."

Trust has become a competitive advantage

Contribution also creates something that's difficult to measure but incredibly valuable: trust.

When organisations invest in large scale digital platforms, they aren't simply buying technology. They're choosing partners who will help them navigate years of future development.

Being recognised as one of the world's leading Drupal contributors provides confidence that 1xINTERNET isn't standing on the outside of the ecosystem, it's helping lead it.

Baddý has seen this become increasingly important during procurement processes.

More organisations now actively look for suppliers who contribute back to the technologies they depend on. Public sector organisations and enterprise businesses increasingly view contribution as evidence of technical excellence, long-term commitment and sustainability.

James has experienced this while expanding 1xINTERNET's presence in the United Kingdom. "When entering a new market where people don't yet know your brand, your contribution footprint becomes a global passport. The Drupal community already knows who you are."

That credibility opens doors long before a first meeting takes place.

Supporting digital sovereignty

For Christoph, contribution is also connected to a much broader movement taking place across Europe and beyond.

As organisations become increasingly concerned about vendor lock-in, proprietary platforms and ownership of their data, open-source software is becoming strategically more important than ever.

By contributing to Drupal, companies don't simply improve software, they strengthen an independent digital ecosystem that organisations can trust.

"Businesses increasingly want digital sovereignty," Christoph says. "By actively contributing to Drupal, we're helping build a secure and independent IT landscape that organisations can rely on."

It's a perspective that positions contribution not only as technical work, but as an investment in the future of open digital infrastructure.

A culture that attracts exceptional people

Contribution doesn't only benefit clients.

It also shapes the people who choose to work at 1xINTERNET.

The company actively encourages employees to contribute code, maintain projects, organise events, mentor others and share knowledge across the community.

For many developers, that's exactly the environment they're looking for.

"Top developers want to work on things that matter," James says. "We offer them a stage, not just a desk."

Christoph agrees.

Many developers are motivated by solving meaningful problems that have an impact far beyond a single client project.

For Baddý, contribution creates something equally valuable: a culture of continuous learning.

By collaborating with some of the best Drupal developers in the world, the entire team continually raises its own standards, creating an environment where innovation and professional growth go hand in hand.

Looking ahead

Becoming a Top-Tier Drupal Contributor isn't viewed as a finish line.

Instead, it's another milestone in a much longer journey.

The company plans to continue investing heavily in Drupal AI, supporting the wider community, encouraging employees to contribute and helping organisations embrace open-source innovation with confidence.

Christoph hopes to make Drupal AI even more accessible through practical demonstration environments that allow organisations to experience its capabilities with a single click.

James wants to strengthen the connection between enterprise organisations and the open-source community, demonstrating that open source can successfully support even the most ambitious digital transformation projects.

Baddý remains focused on investing in people, community leadership and the long-term health of the Drupal ecosystem.

More than contribution

Ultimately, becoming a Top-Tier Drupal Contributor isn't really about rankings, badges or recognition.

Those are simply the visible results of years of consistent investment.

The real achievement is building a company where contribution is part of everyday work, where sharing knowledge is expected, collaboration is celebrated, and innovation is something created together rather than consumed.

For 1xINTERNET, contributing to Drupal has never been about giving something away.

It's about helping build a stronger platform, a stronger community and better digital experiences for everyone who depends on Drupal.

Because when the platform grows stronger, so do the organisations, developers and communities that build upon it.

Discover how our solution automated content translation and helped the client’s team work faster.

Take Away Marlene Wanberg, Frontend Developer at Tag1 and a Drupal builder since 2007, built a suite of fifteen AI agent skills that runs a full automated accessibility audit and narrows thousands of raw scanner findings down to a short worklist of confirmed fixes.

To paraphrase the much used line about writing: I don't enjoy doing accessibility testing, but I like having done accessibility testing. When a site becomes more usable for everyone, I feel good. Users feel good. Clients feel good. (Regulators feel good.) The process of getting there can be very tedious.

Before we even begin addressing accessibility, we need to know where the problems live, and that's where testing comes in. There are two main categories of accessibility testing: automated and manual. Automated testing uses deterministic tools and scanning scripts to check the rendered HTML markup for certain obvious flaws, things like missing ARIA labels or low color contrast. Manual testing checks what those tools can't. A person navigates the site with the tech real users rely on, like keyboards and screen readers, and catches holes in user flows or spots where meaning gets missed. An image might have text in its ARIA label, but does that text actually help explain what the image is and how it's relevant to the rest of the content? Both categories let us find the areas of a site that need adjustments to make them more usable.

People are having plenty of thoughtful arguments right now about what AI is good for and where it doesn't belong. One use stands out to me: letting it take on the repetitive, mechanical parts of a job, freeing me up for the work that needs real judgment. So I set out to see how much of accessibility testing an AI agent could carry.

Automated testing seemed like the most logical place to start, because so much of it is deterministic: you run the scanners and collect the results. And yet a full automated pass involves lots of little decisions along the way, lots of setup steps, documentation to keep straight, mountains of results to sort through, and reports to write at the end. Exactly the type of work I wanted to hand off.

One Skill File Was Not Nearly Enough

Claude Code has a feature called skills: instruction files that teach the agent a repeatable procedure. That seemed like a promising starting point. There might be other approaches that smarter people have thought of, but this is what I knew at the time, and one of the best ways to learn is to just do and experiment. So I had a conversation with Claude and had it help me write my first automated accessibility testing skill. (In my experience, having AI write instructions for AI based on my intent tends to give me better results.)

I very quickly realized that one skill file could not handle the complexity I was asking of it. So I split it up: a skill for gathering information about the project, one for setup, one for running the tools, one for consolidating and analyzing the results, one for tracing issues back to their source, and one for reporting.

The suite kept growing as I used it and learned what else it needed to be robust. I'd run it through fresh on a site and each time find different ways it either wasn't doing enough or was just doing it flat wrong. Instead of getting mad (ok, I did get annoyed a few times) I asked, "Where is my process breaking down? What does the agent need that I haven't provided? Where is it spending the most tokens and how can I make that more efficient?"

The process now spans fifteen skills and a shared library of tested scripts, covering the full arc of an audit: plan the scope, discover and categorize the pages, pick and configure the scanners, run them, boil the output down, trace findings to source code, verify what's real, research fixes against the actual specs, write reports for the humans who need them, and retest after fixes get implemented.

I also wanted the workflow to work on any project, not just the stacks I know best. Drupal, Next.js, Svelte, WordPress, whatever comes through the door. Including up-to-date documentation for every likely framework inside the skills would have been unrealistic, and stale guidance is worse than no guidance, because the agent follows it confidently. (Just ask any Drupal dev trying to use AI out of the box for dev help). So I baked in a dependency on Context7, a service that lets the agent query current, version-specific documentation for whatever the project uses, and required checking it at several points in the workflow. Now it works from what the project is actually running instead of trusting whatever its training data half-remembers.

Humans Stay In the Loop, On Purpose

I value ownership of my work. Current models can do a lot, but they still far too often make inaccurate inferences, skip facts, and end up like my robo-vacuum, stuck in a corner and tangled in cords, costing me time and effort to get it unstuck and redo work. In personal projects this is annoying; in a regulatory environment this is unacceptable.

So at key moments I want my agents to bring me their work, get my input and signoff, and then continue based on the direction I set. The agent interviews me up front about the project and its goals. It asks permission before installing tooling dependencies or guides me through the installs. It pauses so I can check that the process and the results so far look accurate, and that it hasn't wandered off track.

What Broke Along the Way

Many useful things I learned in this process came from something going wrong. A sampling:

False positives. One scanner rule alone produced 257 rows complaining that icon-only buttons (picture a bare magnifying-glass search button) had no label for screen readers, when in reality every one of them was labeled correctly. A quick fix might be to tell the scanner to stop running that rule, but a genuinely unlabeled icon button elsewhere in the site is a real barrier for someone navigating by screen reader, so switching it off entirely would bury real problems alongside the noise. Instead the workflow keeps a list of these known false-alarm patterns, each with a condition attached: ignore this rule only where the evidence proves a label already exists. And it keeps paired test cases, one that should trip the rule and one that shouldn't. If the exception ever starts covering a real failure, a test catches it.

Too much output, then not enough. Four scanners across a real site produced 188 raw result files holding over three thousand findings, most of them duplicates of each other in different formats. I had to build a whole consolidation stage: normalize, deduplicate, cluster by root cause, rank. Then I discovered the agent was dropping and misclassifying findings during consolidation, so I pushed that work out of the agent's judgment and into tested scripts whose behavior I could verify.

Empty, meaningless reports. Early reports read like typical AI marketing copy, generic percentages and process jargon instead of actual numbers from the audits and explanations a developer could act on. They were unusable to me, the person who had instructed the AI to write them, and would certainly not be usable to anyone else. Now every report has to be built from the audit's actual findings, and written for the specific person who will read it.

The disappearing CSV parser. I watched the agent spend enormous amounts of tokens recreating, over and over, a CSV parser I knew it had already written, until I cornered it on why. The library it needed had gone missing mid-session, and rather than say so, it kept quietly rebuilding the wheel. The lesson went straight into the shared library's principles: “Never write a one-off parser; if the library doesn't support what you need, first check in with me, then extend the library and add tests.”

Confidently wrong. Authentication tripped it in a way I almost didn't catch. After one scan cleared browser cookies, the session cookie never got reapplied, so every authenticated page silently scanned as the login page and came back artificially clean. Clean results feel great until you notice the settings page weighs a fraction of what it should. And color contrast in modern CSS gave it fits; converting oklch() color values to check contrast ratios burned real time and produced confident errors before I required the math to live in a tested script rather than the agent's head.

Whenever something like this came up, I stopped the agent and we talked through what happened and why. Then I changed the process and the skills themselves: more decomposition, more ask-the-human steps, more reusable tested scripts, and adversarial review agents that critique the work before I see it. Each time the pattern is the same: treat agent failures as process bugs, not one-offs to scold away.

Did It Produce Anything?

Yes, it did, and I'm quite pleased with the results.

Take a static marketing site. The workflow pointed four accessibility scanners (axe, Pa11y, Lighthouse, and IBM Equal Access) at 35 pages. Between them they returned 7,028 raw findings. Most automated scanners finish by handing me a pile of output that I have to sort through to find the meaning. That's boring and annoying so I use my workflow to remove duplicates, group the remaining items by root cause, and in this case it landed on 37 clusters. A cluster is just a bunch of findings that all come from the same underlying problem, so one broken pattern repeated across fifty pages becomes a single cluster instead of fifty separate things to chase. The review step of the workflow turns those into a short worklist. 11 of them are confirmed code fixes ready to act on. 7k+ findings down to 11 things I need to do.

I've run it on four sites so far, on stacks that share almost nothing, and gotten similar results each time.

Site Raw findings Narrowed to Eleventy site 7,028 37 clusters Drupal module 1,091 24 clusters Next.js app 3,216 32 clusters SvelteKit site 6,980 26 clusters

And if I had questions about any of them, like where a problem came from, which WCAG rule it violated, even a suggested fix, I could talk it through with the agent, which had the full context of the project.

One of my favorite bits is how the workflow traces big noisy messes back to the source. On the Eleventy site, it found that fixing just two files (one layout template and one stylesheet) would clear 82% of its 7,028 findings. That is exactly the kind of combing-through I used to do by hand, and exactly what AI is good at.

It is not only good at ruling things out or narrowing down issues. I've found it is good at bringing up and prioritizing problems that matter but that wouldn't necessarily be highlighted using just the automated scanners. For example, on a Next.js app it confirmed a link set apart by color alone, a genuine problem for anyone who cannot see the difference. On a SvelteKit site it flagged something styled as a button that was really a plain span, invisible to a keyboard. In the Drupal LMS module, it found the course card was two overlapping links pointing to the same place, which adds noise to a screen reader. And it found where code blocks failed contrast in dark mode, a problem a quick once-over would sail right past.

How Do I Know It Isn't Missing Things?

If my workflow drops the findings from thousands to under a hundred actionable items, that can feel good, but it also raises the question: Are we missing something now?

Two things stop that from happening. First, the automated pass is not the full audit. Scanners cover the slice of WCAG a machine can check, which is a portion of what matters. The rest still needs a person at the keyboard with assistive technology. For example, on the Drupal module, my own manual review added seventeen findings no scanner could have caught, no matter how many times I ran them. Second, someone who knows what "wrong" looks like has to read the workflow's output. Those authenticated pages that scanned clean because the session cookie dropped? A less experienced reviewer might file that clean result and move on. The workflow speeds up an expert. It does not replace one.

The Workflow Keeps Evolving

I treat the workflow itself as a project under audit. Each time I use it I find ways to improve it. This summer I handed a newer, more capable model a bigger job: review the entire suite and plan a remediation of its rough edges, from turning the copy-paste method I'd been using to move it between projects into a proper plugin to addressing weak spots in the consolidation stage.

That overhaul is underway now. The intake interviews will be better, I'm incorporating the latest WCAG Evaluation Methodology, and I'm experimenting with AI-driven keyboard testing.

What You Can Take From This

I haven't released this workflow yet; it remains a personal tool that I use on the projects in front of me, including Tag1's. But the pattern is the transferable part, and none of it requires my code:

• Decompose the work until each piece has one job.
• Keep a human at the decisions that matter.
• Push the agent toward current documentation for the project's actual stack instead of letting it coast on training data.
• Fix the process when the agent fails.
• Move anything deterministic out of the agent's judgment and into tested scripts.
• Measure and review before you trust; sometimes the AI's most confident conclusions turned out to be based on broken steps.
• Add adversarial agent reviews to both the planning and the workflow.

None of this made accessibility testing fully automatic, and that wasn't my goal. It has made many of the tedious parts quick, and I get to spend more of my time doing the interesting parts now.

This is one of several ways we're putting AI to work on real engineering problems at Tag1. You can find more in our Insights.

I've been working on DDEV for years now, and there's something I don't say often enough:

You make this so worthwhile.

Stas and I love to get up in the morning to hear what you have to say, learn from your experiences, share our path together.

We feel so thankful to be creating something useful in collaboration with you.

All of us have had jobs before where some boss was making random decisions on product features that we knew might be irrelevant in weeks or months. It's a frustrating feeling, and that lack of control is so terrible. With DDEV and your guidance, we always know that you're keeping us on track about real needs for real features. It's fantastic.

Real Feedback About Real Problems

Your questions in Discord or Slack and the issues you file aren't "noise". They're signal. When something breaks (or is awkward) in your workflow, you tell us, often with enough detail that we can reproduce it immediately. When something is confusing, you ask questions that reveal where our assumptions were wrong.

That feedback shapes DDEV in ways that internal testing never could. We don't use DDEV on every possible OS, with every PHP framework, in every hosting environment. You do. And you tell us what you find.

We Love Your Questions and Comments.

AI has been replacing human interaction in support situations, and in many cases doing a decent job. It usually does a good job with questions about DDEV.

But getting answers to questions is not the only purpose of support. It's also a great way to communicate problems and ambiguities to project maintainers.

We want you to ask us questions! We live for your questions. We miss the fact that you've been absent from Discord, #ddev in Drupal Slack, and the issue queue. When you ask, it helps us to understand what your struggles are and how DDEV can get better. DDEV's strength has always been the community's willingness to engage and share their needs and frictions and hopes for the project.

Hard Questions Lead Somewhere

Most of the best improvements to DDEV started with someone asking a question that seemed basic but turned out to be pointing at a real need. Why does this take so long? Why does that require a workaround? Why can't DDEV just handle this case?

Those questions are gifts to all of us. They push us to look at things we've gotten used to, and ask whether they actually need to be that way.

Generous Contributions

The DDEV ecosystem is full of people who built something useful for themselves and then shared it with everyone. Add-ons, CI configurations, documentation fixes, screencasts, blog posts.

Stas, who joined the project more recently, was surprised by how much DDEV could be extended and customized, and how good the documentation was for figuring it out. Looking back, that didn't happen by accident. It came from years of feature requests and contributions from people who solved their own problems and then shared the solution.

Every person who took time to answer another user's question in the DDEV issue tracker or Discord or Drupal Slack freed up time for the maintainers to work on the next feature.

We Learn from You

Working with the community makes us better at this work. The patterns we see in your issues, the use cases we hadn't considered, the ways you've adapted DDEV for environments we never anticipated—that knowledge informs everything.

Thank You

To everyone who filed an issue, answered a question, wrote a blog post, sponsored the project, gave a talk, built an add-on, tested a prerelease, or just told a colleague that DDEV was worth trying:

Thank you. This project exists because of you, and it's only possible because of the ways you engage with it.

If you want to stay involved, here's where to find us:

• Discord — active community discussion
• GitHub Issues
• Drupal Slack

Come say hello.

In April 2025, I published Claude Code meets Drupal, my first public experiment with an AI coding agent. I have been experimenting with coding agents ever since, often by building tools to solve problems in my own work.

Last week, I joined the Drupal AI Learners Club to discuss several experiments I had already published. Angie Byron started the club and runs it with co-organizer Amber Himes Matz. It gives people in the Drupal community a place to show how they are using AI and talk honestly about what works and what does not.

I spent an hour walking through the experiments, starting with Drupal Digests, a tool that uses AI to summarize key developments across Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative.

Drupal Digests led to another experiment: AI-generated Rector rules. When a Drupal Core change deprecates an API, Drupal Digests analyzes the issue and code changes and generates a rule that can automate the corresponding upgrade in other Drupal projects.

I also showed an API catalog that helps AI agents discover my website's search API.

These are only some of my AI experiments. Most begin as tools I build for myself, and many never go any further. When one seems useful beyond my own work, I publish it so others can try it and improve it.

Once it is public, we can see whether people use it and want to help improve it. If they do, it may eventually become a community project. If not, that is useful to know too.

The recording goes into much more detail, with demonstrations of the tools and questions from the group. You can watch it below.

Several of the e-commerce stores we build and run ship with MRW, one of the main carriers in Spain and Portugal. Until recently, shipping an order meant leaving the store: open MRW's customer portal, retype the customer's address, print the label, then copy the shipment number back into Drupal so the customer gets a tracking link. Multiply by every order, every day, and add returns, which meant doing the same dance with the addresses swapped.

We replaced that with a Drupal module. It now runs the daily expedition of the first of them, and we are releasing it to the community: Commerce MRW is available on drupal.org, with a 1.1.0 release.

What it does

Commerce MRW integrates Drupal Commerce with MRW through SAGEC, the carrier's SOAP webservice for creating and managing shipments (envíos). The whole expedition cycle happens on the shipment admin pages the team already uses:

• Transmit shipments (TransmEnvio): one click creates the shipment on MRW's side and stores the returned shipment number as the Drupal shipment's tracking code, feeding the customer-facing tracking link.
• Labels on demand (GetEtiquetaEnvio): the transport label PDF is streamed straight from SAGEC every time someone asks for it. Labels are never stored locally, so MRW stays the single source of truth and there is no stale-file problem.
• Cancel (CancelarEnvio) transmitted shipments before the courier picks them up.
• Return pickups: a request can carry a pickup address (DatosRecogida), so MRW collects the parcel at the customer's door and delivers it back to the store. Returns stop being a manual job in the carrier portal.
• Tracking: a client for MRW's TrackingServices webservice queries the current status, or the full status history, of any shipment: by MRW number, by your own order reference, individually or in bulk.
• "Transmit as": shipments whose shipping method is not MRW (say, a generic "Free shipping" flat rate) can still be shipped with MRW. The operator picks the executing method at transmit time and the choice is recorded on the shipment.

Service codes cover the SAGEC catalogue (Ecommerce, Urgente 19 Expedición, Urgente 13 and friends), and PRE (test) and PRO (production) environments are separate credential sets with a test-mode toggle, so you can validate the integration with your franchise before a single real parcel moves.

Small module, sharp edges

The SAGEC manual is short; reality is not. A few of the edges the module rounds off for you:

• Postal codes are per-country folklore. Spain wants 5 digits with leading zeros, Portugal wants only the first 4 of its 7-digit codes, Andorra's letters become zeros, and Gibraltar is always 00010. The module normalizes all of it before SAGEC ever sees an address.
• The tracking service hides behind a WCF quirk: it only accepts SOAP posts on its relative endpoint address, and answers 404 on the address the documentation leads you to. We found out so you do not have to.
• No PHP SOAP extension required. Both clients build their envelopes by hand over Drupal's HTTP client, which also makes every request fully testable with mocked responses; the module ships with a kernel test suite that asserts the exact XML that goes over the wire.

Your store's rules stay yours

Carrier integrations die by hardcoding someone else's workflow, so Commerce MRW deliberately does not have one. Site-specific data travels through an event: subscribe to the TransmEnvio request event and fill whatever your store knows, the consignee's phone number, a NIF, delivery observations for the courier, or a full pickup address to turn a transmission into a return pickup. In one of our stores, three small subscribers do exactly that: one copies the customer's phone, one sends the backoffice's "carrier notes" field as delivery instructions, and one swaps the addresses when a shipment is flagged as a return.

Tracking follows the same philosophy. The module gives you the client and a documented integration recipe, but ships no polling and changes no shipment states: whether "delivered at destination" should transition your workflow, or just inform a human, is your call. That store runs an hourly cron that mirrors the last MRW status into the expedition dashboard, next to each tracking code; marking a shipment delivered stays a human decision, now an informed one.

Battle-tested, then released

Like our other contrib modules, this one shipped to drupal.org only after running a real store's daily expedition: real transmissions, real labels handed to the courier, and a tracking client validated against the production webservice before its release was tagged. The test suite (42 kernel tests at the time of writing) covers the SOAP envelopes, the postal code rules, the backoffice forms and the tracking parsing.

Get it composer require drupal/commerce_mrw:^1.1

Requires Drupal 10.3+ or 11 and Commerce Shipping 3.x, plus SAGEC credentials from your MRW franchise (ask your franchise; ours enabled both the shipping webservice and the tracking service on request).

If you run a Drupal Commerce store shipping in Spain or Portugal, this is for you. The issue queue is open, and international shipments, ZPL labels and MRW delivery points are on the roadmap.

Drupal's volunteer Security Team has protected millions of sites for more than 20 years and its process is world-class. Bandwidth among the security engineers has always been the limiting constraint. This spring that constraint met a new kind of pressure: AI-assisted analysis is finding latent vulnerabilities at an accelerating pace.

The Drupal AI Security Initiative adds funded security capacity in response. It is funded through Alpha-Omega's Security-Engineer-in-Residence (SEIR) program, coordinated by the Drupal Association, and works alongside the volunteer Security Team, which continues its normal process throughout.

This post introduces the initiative and reports on our first six weeks. The short version: the funded fractional team model is working and has already evolved our understanding of where we want to focus next.

What changed: the economics of discovery

Drupal's attack surface is what it has always been. What has changed is the cost of finding bugs. AI-assisted analysis makes discovery dramatically cheaper. AI can produce security issue reports at a volume and can discover exploit details at a speed that any volunteer effort struggles to absorb. Our advisory data shows the rate of discovery accelerating (our next post will work through what the data suggests in detail).

Meet the Drupal AI Security Initiative Team

The initiative builds on the lessons of the Drupal 8 Accelerate Initiative, which showed that throughput efficiency depends on funding the whole contribution workflow, not just one part of it.

The Drupal security team needs fixes, not just findings of potential issues. As fixes are developed, they are collaboratively reviewed. An engineer cannot mark their own fix complete. Funding one full-time engineer would likely produce findings faster than volunteers could review them, and they would queue. So we’re using the grant to fund a fractional team that covers the full path from discovery to merge on both the project and infrastructure side for Drupal: 

• Drew Weber (@mcdruid) is the Fixer. He applies AI-security expertise directly to Drupal's code: scanning, writing patches, building experimental tooling, and then submitting contribution-ready work across Drupal core and the contributed-project ecosystem.

• Greg Knaddison (@greggles) and Michael Hess (@mlhess) are Reviewers: They triage submissions, review patches, advance issues, and provide the RTBC status a fixer cannot grant themselves. Both come from the existing Security Team, and the grant helps subsidize the work they would otherwise do on volunteer time.

• Neil Drumm (@drumm) handles infrastructure, focusing on Drupal.org itself. The package distribution, build pipelines, and update mechanisms are a high-consequence, specialized surface on their own.

• Tiffany Farriss (@farriss) and Tim Lehnen (@hestenet) provide program support and coordination for the Drupal Association.

Our current grant has two three-month phases: Clarity (understand the problem) and Attention (fix issues and harden the process). 

Six weeks in: what we've done

We're using the funding and AI tooling to find, validate, triage, and resolve vulnerabilities faster than before, including proactively, across core, contrib, and our own infrastructure. In six weeks, the team has made contributions to more than 10 published advisories and CVEs and filed more than 30 issues. This work includes SA-CORE-2026-005, a critical PHP object-injection issue reachable via JSON:API that arrived as an external report and was coordinated to a fast release, alongside triage and remediation across dozens of findings and hundreds of inbound requests. The team also worked on rapid response/urgent issues off-hours; in one case, AI-assisted review helped find and fix a significant issue in Drupal.org code. 

We're also building reusable tooling and automation prototypes that increase throughput and make our security archive searchable and actionable. That includes five Claude skills and a set of opengrep static-analysis rules, each targeting a vulnerability class, and local, open-weight tooling that processes about 40,000 historical security-mailbox emails to assign metadata like CWE mapping and flag duplicates (keeping sensitive data local). One key project outcome will be delivery of working tools the Security Team can continue to use after the initiative ends.

Drupal’s grant is one of several parallel Alpha-Omega grants across open source ecosystems. Being part of this cohort has allowed us to compare notes and share tooling, successes and failures with other open source projects.  So far we’ve collaborated most directly with Volker Dusch, who leads the equivalent effort at the PHP Foundation, and with colleagues at the Open Source Technology Improvement Fund (OSTIF), who shared their report-validator protocol for separating real findings from noise. That protocol feeds straight into our intake, and into the report standard we want to co-create next.

The counts are perhaps not the most interesting part. We've resolved more security issues (10) than the minimum number (8) our proposal had committed to over the entire six-month project. We had assumed the meat of the task would be finding and fixing vulnerabilities. It turns out that the more interesting challenge will be adapting Drupal's security process to the volume and nature of higher-quality-than-expected AI-generated and AI-assisted reports.

So far that adaptation has happened downstream, after an issue has been reported. Shepherding issues to a fix, filing CVEs, automating that filing, and automating the analysis of published advisories are important and help scale the response process. But it is all at the bottom of the funnel. The opportunity we would like to explore is higher up, at intake, where issues arrive.

We've started exploring what that might look like. In discussions with core maintainers, some design principles emerged: AI stays limited to a single triage activity per issue and no bot noise on every commit and merge request. Ideally, early intake tooling would pre-filter inbound security issue reports and run a gated check that confirms whether they include enough context and reproduction detail before they reach a human.

What’s next

The next six weeks will build on what is working and push the intake question in two directions. The first is triage. The volume of incoming security issues is expected to keep growing and AI-assisted triage of that queue is an area to explore. We are interested in looking at how modern tooling can sort and deduplicate incoming issues so human attention can be focused where it's actually needed.

The second is the report itself. A clear issue report helps the Security Team and maintainer community move faster; a vague or bloated one slows everyone down. We want to explore and define what a useful AI-generated or AI-assisted security report should contain and draft a working standard, co-created with the Security Team and maintainers. If you are a maintainer or security reporter and have examples of good (or bad) AI-generated reports, please share them in Drupal Slack #security-discussion.

Six weeks of supplemental funding has already made a couple things clear. The roles the Drupal ecosystem depends on (security work as well as release management) need a durable, community-owned funding model, not one-time support. And we need to keep talking and collaborating across ecosystems like this.

Thanks

Huge thank you to Alpha-Omega for the support, funding and for access to AI tooling from Anthropic that enabled several of the findings above; to the Linux Foundation; and to the Drupal Association for coordination. And of course, none of this works without the two decades of effort from Drupal’s amazing Security Team.

Farriss says reserves are covering a gap in Drupal’s wider stewardship work, prompting proposals to expose programme costs and connect enterprise use with ongoing support.

When we started building Dripyard as a business, we had a clear objective: Drupal developers should be able to move fast without giving up the things that make it Drupal. Structured content, editorial control, accessibility, open-source ownership, and long-term maintainability should not be traded away just because a project has a tight timeline or limited budget.

Community participation moves beyond story leads as The DropTimes prepares an Editorial Working Group for Drupal contributors.

Check out our B2B platform implementation for Sumaris – a company providing specialized solutions for industry.

The Pattern I Keep Seeing

A team starts a Drupal project. Someone asks how editors will build and arrange page content. Someone else says "Layout Builder," and that is the end of the conversation. Nobody asks what the editors actually need. Nobody asks what the content model demands. Layout Builder gets switched on because it is powerful, modern, and comes with core.

Six months later, one of two things has happened. Either the editors are happily composing layouts and everyone is glad, which is the good outcome. Or the editors are confused by a tool that gives them more power than they wanted, the developers are fighting to constrain a system designed to be open-ended, and the content is inconsistent because thirty editors made thirty different layout choices. That is the bad outcome, and it is more common than the Drupal community likes to admit.

The tool is not the problem. The reflexive selection of the tool without asking whether it fits is the problem.

The Four Options

Before the framework, a quick map of what you are actually choosing between when you decide how editors build pages in Drupal.

Layout Builder. Editors compose pages by placing blocks into regions of a layout, visually, per page or per content type. Maximum flexibility. Maximum editor power. The editor decides the structure.

Paragraphs. Editors add and arrange predefined content components in a field. Structured flexibility. The developer defines the components; the editor arranges them. The structure is constrained by what you built.

Custom templates. The developer defines the layout in Twig and the editor fills in fields. Zero layout flexibility for the editor. Maximum consistency and developer control.

Plain blocks and block layout. Content is placed in regions through the block system, configured by a site builder, largely static across pages. Good for site-wide furniture, weak for per-page composition.

Each of these is correct for some situations and wrong for others. The framework is about matching the tool to the situation.

The Framework: Four Questions

I run every "how should editors build pages" decision through these four questions, in order.

Question 1: Do editors actually need to compose layouts, or do they need to fill in content?

This is the question that settles most cases, and it is the one nobody asks.

If your editors are filling in structured content (an article has a title, a body, an author, a hero image, a set of related links), they do not need Layout Builder. They need well-designed content types with well-designed fields, rendered through templates the developer controls. Giving these editors Layout Builder hands them a layout composition tool for a job that has no layout composition in it. They will either ignore it or misuse it.

If your editors are genuinely composing pages (a marketing team building landing pages with varying structures, arranging components differently per campaign), then layout composition is a real need and Layout Builder or Paragraphs becomes relevant.

The test: watch an editor work, or ask them to describe their job. If the word "arrange" or "compose" or "build" comes up, layout tooling might fit. If they describe "entering" or "updating" or "filling in," it probably does not.

Question 2: How much layout variation do you actually need?

If the answer is "every page can look completely different," Layout Builder is designed for that.

If the answer is "editors combine a fixed set of components in different orders," Paragraphs is the better fit. It gives editors arrangement flexibility without giving them raw layout power they do not need and will misuse.

If the answer is "pages of this type all look the same," you do not need either. Custom templates with fields is the right call, and it will be faster, more consistent, and more maintainable than either flexible option.

Most projects need less layout variation than they think. The instinct is to build for maximum flexibility "just in case." That flexibility has a cost, paid in editorial inconsistency and developer maintenance, and the "just in case" scenario often never arrives.

Question 3: Who bears the cost of flexibility?

Every option shifts cost to a different party.

Layout Builder shifts cost to editors, who now have to make layout decisions on every page, and to developers, who have to constrain and style a system designed to be open. The flexibility is real but so is the ongoing cost of managing it.

Paragraphs shifts cost to developers upfront (building and styling the components) and keeps the editor experience constrained and predictable. Once built, it is low-cost for editors.

Custom templates put all the cost on developers upfront and give editors the simplest possible experience: fill in the fields, the layout is handled.

The question is not "which is most flexible." It is "who should bear the cost of flexibility on this project, and can they?" A marketing team that wants control can bear the Layout Builder cost. An editorial team of subject-matter experts who just want to publish articles cannot, and should not be asked to.

Question 4: How many people will use this, and how consistent does the output need to be?

Flexibility and consistency are in tension. The more freedom you give editors, the less consistent the output.

If three trained content designers are building marketing pages, Layout Builder's flexibility is a feature and the consistency risk is manageable because the team is small and skilled.

If thirty subject-matter experts across departments are publishing content, Layout Builder's flexibility is a liability. You will get thirty interpretations of what a page should look like, and your site will drift into visual chaos within a year. Constrained tools (Paragraphs with a limited component set, or custom templates) protect consistency at scale.

The larger and less design-trained your editorial pool, the more you should constrain their tooling.

The Framework in One Sentence Each

To compress it:

• Custom templates when pages of a type look the same and editors fill in fields.
• Paragraphs when editors arrange a fixed set of components in varying orders.
• Layout Builder when editors genuinely compose free-form layouts and the team is small and skilled enough to manage the flexibility.
• Plain blocks for site-wide furniture, not per-page composition.

Notice that Layout Builder is the right answer for the narrowest set of conditions, not the widest. That is the inverse of how often it gets chosen.

Why Layout Builder Gets Over-Applied

Three reasons the reflex exists.

It is in core and it is visible. Paragraphs is contrib. Custom templates require writing code. Layout Builder is right there in core, promoted, documented, demoed. Visibility drives adoption regardless of fit.

It demos beautifully. The drag-and-drop layout composition is genuinely impressive in a demo. Stakeholders see it and want it. The demo does not show the editorial inconsistency that emerges at scale six months later.

It feels like the modern choice. Choosing custom templates can feel like you are not using Drupal's capabilities fully. There is a subtle pressure to use the powerful tool because it is there, even when the simpler option is correct. Resisting that pressure is a senior move.

Closing Thought

Layout Builder is a good tool. I am not arguing against it. I am arguing against choosing it reflexively, without asking whether the project actually needs page composition or just needs structured content entry.

The four questions above take ten minutes to run and save months of pain. Do editors compose or fill in? How much variation is really needed? Who bears the cost of flexibility? How many people, how consistent? Answer those honestly and the right tool usually selects itself.

The instinct to reach for the most powerful option is understandable and usually wrong. The senior move is to reach for the option that fits, which is frequently the more constrained one. A Drupal site where editors fill in well-designed fields through developer-controlled templates is not a less sophisticated site than one built on Layout Builder. Often it is the more sophisticated one, because someone made a deliberate choice instead of a reflexive one.

If you have shipped Layout Builder on a large multi-editor site and kept it consistent over years, I would be curious how you constrained it. That is the hard case, and the honest accounts of making it work at scale are rarer than the demos suggest.

The Drupal AI module's Guardrails system runs configurable validation plugins both before a prompt is sent to an LLM and after a response is received. Guardrails can pass, block, or rewrite content, and can be combined into sets with a scoring threshold.

A developer I work with sent this skill over recently, asking whether it was worth adopting across the agency's client projects (an additional pass before publication under a client's name). That's a fair question to ask before rolling something out across multiple sites, so I read the source rather than taking the pitch at face value.

We heard you... and we want to hear from more of you!

The MidCamp 2026 Call for Sessions has been extended. The new deadline is March 13, 2026.

If you had a session idea brewing but didn't quite get it across the finish line, now's your window. We extended the deadline because we want a lineup that reflects the full range of people who use, build, and care about Drupal — and we're not there yet without you.

What We're Looking For

MidCamp sessions are open to all skill levels and all corners of the Drupal ecosystem. Whether you're a developer with a deep technical dive, a project manager with hard-won lessons, a designer with a perspective the community needs, or an end user who figured something out the hard way — there is a place for your session at MidCamp.

We're especially interested in talks around:

• Drupal AI — practical applications, integrations, and what's actually working in the field
• Drupal CMS / Canvas — building with and extending Drupal's newest tools
• Decoupled and headless implementations — real-world lessons from the front lines
• Accessibility, equity, and inclusion — building a better, more accessible web
• Community and contribution — how we grow the ecosystem together

Not sure if your idea fits? Submit it anyway. We'd rather review more proposals than miss a great talk.

How to Submit

Session submissions are open now through March 13, 2026.

We're excited to celebrate you -- our future speakers! If you've got an idea for a session, now's the time to get involved in MidCamp 2026, happening May 12-14 in Chicago.

Call for Speakers

Since 2014, MidCamp has hosted over 300 amazing sessions, and we're ready to add your talk to that legacy. We're seeking presentations for all skill levels, from Drupal beginners to advanced users to end users and business professionals!

For full submission details and guidelines, visit: midcamp.org/events/2026/how-submit-session

Key Dates

• Call for Proposals Opened: February 10, 2026
• Proposal Deadline: February 26, 2026
• Speakers Notified: Week of April 2026
• MidCamp Sessions: May 12-13, 2026

Sponsor MidCamp

Looking to connect with the Drupal community? Sponsoring MidCamp is the way to do it! Whether you're recruiting talent, growing your brand, or simply supporting the Drupal ecosystem, MidCamp sponsorship offers great value. Act early to maximize your exposure!

Stay in the Loop

• Join us on MidCamp Slack to chat and get updates.
• Follow us on Bluesky and Mastodon for announcements and news.
• Subscribe to our newsletter for updates on the venue, travel options, social events, and speaker announcements.

Ready to submit your session? Click away and let's make MidCamp 2026 unforgettable!

Watch the Dries fireside chat from 2025, or catch up on all of the sessions from last year on Drupal.tv.

Theres even more Drupal goodness to be had in our archives or Drupal.tv's. 

The Archives: 2024 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014
 

Yesterday I blogged about the API catalog that announces my site's search API to agents. In response, someone pointed me to the ARD specification, a draft announced last month by a working group that includes Google, Microsoft, GitHub, Hugging Face, Cisco, Nvidia, and Salesforce.

What ARD adds to yesterday's API catalog is discovery. If an agent has never heard of you, it does not know to look for your API catalog. Ask an agent what people have written about the future of Drupal, for example, and it will probably search Google. It may not think to check dri.es or drupal.org directly.

The web solved discovery decades ago. Search engines find the right site, so you do not have to know where the answer lives.

ARD provides the building blocks for search engines for AI agents. Sites publish catalogs, crawlers discover them, and registries index them. An agent can then ask a registry a plain-language question, such as "Who can answer questions about the future of Drupal?". The registry returns a ranked list of relevant resources, perhaps pointing the agent to my site's search API.

You opt in by publishing a manifest at /.well-known/ai-catalog.json. Yes, that is almost the same path as my existing /.well-known/api-catalog.

Here is what my /.well-known/ai-catalog.json currently returns:

{ "specVersion": "1.0", "host": { "displayName": "Dries Buytaert" }, "entries": [ { "identifier": "urn:air:dri.es:search", "displayName": "Site search", "type": "application/openapi+json", "url": "https://dri.es/openapi.json", "description": "Full-text search across the site's content, ranked by relevance.", "representativeQueries": [ "Find posts about the future of Drupal", "What has been written about open source sustainability?", "Find writing about digital sovereignty", "How is AI changing how we build websites?", "Search Dries Buytaert's blog and notes" ] } ] }

Each entry describes a resource an agent can use. ARD deliberately defines "resource" broadly: it can be an API, an MCP server, another agent, a skill, or even a nested catalog containing more resources.

My site offers just one resource: a simple search API. The whole thing took less than an hour to implement because the entry simply points to the existing OpenAPI document I wrote about yesterday. It advertises the same OpenAPI document, https://dri.es/openapi.json, through a second discovery mechanism.

The representativeQueries field is the interesting part. It lists example questions registries use to match an agent's intent. Mine are first guesses that I will revise once I can see how they get used.

Of the eleven companies listed as contributors, Hugging Face is the only one whose catalog I could find on its primary domain. It also runs an early registry. So I queried Hugging Face's registry directly at https://huggingface-hf-discover.hf.space/search. It responded correctly using the protocol defined by the specification, but for my query, it returned only skills hosted by Hugging Face.

Broad adoption will depend on whether major agents begin searching ARD registries. Microsoft, Google, and GitHub are in the working group, but OpenAI and Anthropic are not. Time will tell if this gets adopted, but Google stated its Agent Platform will connect to ARD registries in the coming months.

Does my blog need this? Probably not. Other sites have more to gain. An online store could announce its product search and checkout APIs, a restaurant its reservation system, and a city its appointment system for renewing a permit.

Many of these sites run on a content management system. A CMS that made its capabilities discoverable through ARD by default could therefore be interesting. Experiments like this help me understand whether Drupal should be that CMS.