fidzu : Drupal

Robert Arias

Backend Engineer

Robert always aims to engineer software that is maintainable, scalable, and reusable while always trying to improve himself and learn from others.

January 1, 1970

Thousands of Drupal sites use SimpleSAMLphp for SSO authentication. But with Drupal 11 around the corner, this setup won't be supported anymore. Here's what site owners and developers should know.

PHP applications integrating with SAML have relied on the SimpleSAMLphp library. Following this standard, the Drupal community created the SimpleSAMLphp Authentication module, which is used by more than 14,000 sites (as of this publication), to provide SSO authentication integration for Drupal sites.

By migrating now, you'll ensure your Drupal site is ready for Drupal 11 without downtime or dependency conflicts, and you can take advantage of the latest features immediately.

Although this library and module is a great resource for SAML integrations, it conflicts with Drupal upgrade paths, hindering the efforts to keep Drupal sites up to date. This is the case for sites that want to upgrade to Drupal 11. If your site has this dependency, you may be stuck until there's a compatible version of the library.

The reason behind this issue is due to the SimpleSAMLphp library having a dependency to Symfony, which collides with Drupal Core Symfony dependency.

Although we're almost there, this issue will continue to persist and will make your site's upgrades dependent on this library. From a technical standpoint, the goal when developing sites is to have the least amount of dependencies, or at least dependencies that are constantly maintained. You can read this Drupal issue to know more about the current issues with the module and D11.

The good news is that there's another PHP library for SAML integrations that has a Drupal contributed module, and it has no conflicting dependencies with Drupal Core! The module is called SAML Authentication, and it uses OneLogin SAML toolkit for PHP. This guide will provide you with the steps for an easy and seamless migration from the SimpleSAMLphp module to SAML Authentication!

Thousands of Drupal sites, especially in higher education, rely on SimpleSAMLphp for single sign-on (SSO). It's been a reliable solution for years. But with Drupal 11 here, that dependency has quietly become a blocker.

If your site depends on SimpleSAMLphp today, you may find yourself stuck waiting on library updates before you can safely upgrade Drupal. For institutions that prioritize security, accessibility, and long-term platform health, that delay isn't just inconvenient. It's risky.

The issue isn't SAML itself. It's the underlying dependency chain. SimpleSAMLphp relies on Symfony versions that conflict with Drupal core, making Drupal 11 compatibility uncertain until the library catches up.

The good news? You don't have to wait.

There's a supported, Drupal-friendly alternative, the SAML Authentication module, that avoids these conflicts entirely. Even better, the community has built tooling to make migration significantly easier than you might expect.

This guide walks through a practical, field-tested approach to migrating from SimpleSAMLphp to SAML Authentication - so you can unblock your Drupal 11 upgrade path without downtime or guesswork.

/**
 * Enable SAML auth module and update authmap table.
 */
function hook_update_N(): void {
  if (!\Drupal::moduleHandler()->moduleExists('samlauth')) {
    \Drupal::service('module_installer')->install(['samlauth']);
  }

  \Drupal::database()
    ->update('authmap')
    ->fields(['provider' => 'samlauth'])
    ->condition('provider', 'simplesamlphp_auth')
    ->execute();
}

The post Don't let SimpleSAMLphp block your Drupal upgrade appeared first on Four Kitchens.

22 Jan 2026 11:15pm GMT

In this episode, we discuss the 'Drupal in a Day' initiative, aimed at introducing computer science students to Drupal and invigorating the community with new energy. Martin Anderson-Clutz and Hilmar Hallbjörnsson talk about its origins, development, and the specifics of condensing a comprehensive university course into a single-day curriculum. They also cover the enthusiasm and logistics behind the events, insights from past sessions in Vienna and Drupal Jam, and future plans for expanding the scope of this program. Tune in to hear the vision for bringing more students into the Drupal community and the benefits for universities and organizations alike.

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

Topics

• What is Drupal in a Day?
• Origins and Development of Drupal in a Day
• Target Audience and Curriculum
• Teaching Methodology and Community Impact
• Student Engagement and Event Comparisons
• Momentum and Future Plans for Drupal in a Day
• Logistics and Volunteer Involvement
• Open Source and Community Contributions
• Personal Stories and Final Thoughts

Hilmar Hallbjörnsson

Hilmar Kári Hallbjörnsson is a senior Drupal developer, educator, and open-source advocate based in Iceland. He works as a Senior Drupal Developer at the University of Iceland and is the CEO/CTO of the Drupal consultancy Um að gera. Hilmar is also an adjunct professor at Reykjavík University, where he teaches "Designing open-sourced web software with Drupal and PHP."

Deeply involved in the Drupal ecosystem, Hilmar is an active contributor and community organizer, with a particular focus on Drupal 11, modern configuration management, and the emerging Recipes initiative. He is a co-founder of the Drupal Open University Initiative and Drupal-in-a-Day, and has served on the organizing committee for DrupalCon Europe.

His work bridges real-world engineering, teaching, and community leadership, with a strong interest in both the technical evolution and philosophical direction of Drupal as an open-source platform.

Martin Anderson-Clutz

Martin is a highly respected figure in the Drupal community, known for his extensive contributions as a developer, speaker, and advocate for open-source innovation. Based in London, Ontario, Canada, Martin began his career as a graphic designer before transitioning into web development. His journey with Drupal started in late 2005 when he was seeking a robust multilingual CMS solution, leading him to embrace Drupal's capabilities.

Martin holds the distinction of being the world's first Triple Drupal Grand Master, certified across Drupal 7, 8, and 9 as a Developer, Front-End Specialist, and Back-End Specialist. (TheDropTimes) He also possesses certifications in various Acquia products and is UX certified by the Nielsen Norman Group.

Currently serving as a Senior Solutions Engineer at Acquia, Martin has been instrumental in advancing Drupal's ecosystem. He has developed and maintains several contributed modules, including Smart Date and Search Overrides, and has been actively involved in the Drupal Recipes initiative, particularly focusing on event management solutions. His current work on the Event Platform aims to streamline the creation and management of event-based websites within Drupal.

Beyond development, Martin is a prominent speaker and educator, having presented at numerous Drupal events such as DrupalCon Barcelona and EvolveDrupal. He is also a co-host of the "Talking Drupal" podcast, where he leads the "Module of the Week" segment, sharing insights on various Drupal modules. Martin's dedication to the Drupal community is evident through his continuous efforts to mentor, innovate, and promote best practices within the open-source landscape.

Guests

Hilmar Hallbjörnsson - drupalviking Martin Anderson-Clutz - mandclu

22 Jan 2026 3:00pm GMT

I tried Claude Code for a month with Drupal

theodore January 22, 2026

22 Jan 2026 9:00am GMT

I had a great time chatting with Pantheon's Chris Reynolds earlier today about what is coming next for Drupal. We dug into Drupal's upcoming marketplace and where Dripyard fits into that ecosystem.

We also talked through site templates, recipes, single directory components, and how all of this is shaping the future of Drupal.

If you are curious about where Drupal is headed and how the commercial ecosystem is evolving, this one is worth a watch!

22 Jan 2026 1:04am GMT

21 Jan 2026 6:26pm GMT

Supercharging your workflows with artificial intelligence is one of the hottest trends of content editing on a Drupal website. When it comes to AI, Drupal is ahead of the rest, rapidly integrating advanced machine-learning capabilities into its ecosystem.

21 Jan 2026 5:52pm GMT

In B2B ecommerce, one size never fits all. Every business develops unique workflows and processes organically over the years. These vary but include negotiated pricing, custom catalogs, bulk ordering, purchase approvals, and complex fulfillment requirements.

An extensible eCommerce platform provides the flexibility to adapt and customize to specific business needs while keeping pace with evolving market demands.

We can modify a famous quote, usually attributed to General Robert H. Barrow: "Amateurs talk about tactics, but professionals study logistics."

Tactics are important, but it's logistics that enable those tactics and keep an army agile and well-supplied. Long-term thinking and planning are required. It's the difference between winning a single battle and winning a long, protracted war.

So let's modify this principle for B2B companies:

Amateurs shop for features. Professionals architect for tomorrow.

And it's APIs and data structures that help professionals architect for that tomorrow.

Read more

21 Jan 2026 4:28pm GMT

As global tensions rise, governments are waking up to the fact that they've lost digital sovereignty. They depend on foreign companies that can change terms, cut off access, or be weaponized against them. A decision in Washington can disable services in Brussels overnight.

Last year, the International Criminal Court ditched Microsoft 365 after a dispute over access to the chief prosecutor's email. Denmark's Ministry of Digitalisation is moving to LibreOffice. And Germany's state of Schleswig-Holstein is migrating 30,000 workstations off Microsoft.

Reclaiming digital sovereignty doesn't require building the European equivalent of Microsoft or Google. That approach hasn't worked in the past, and there is no time to make it work now. Fortunately, Europe has something else: some of the world's strongest Open Source communities, regulatory reach, and public sector scale.

Open Source is the most credible path to digital sovereignty. It's the only software you can run without permission. You can audit, host, modify, and migrate it yourself. No vendor, no government, and no sanctions regime can ever take it away.

But there is a catch. When governments buy Open Source services, the money rarely reaches the people who actually build and maintain it. Procurement rules favor large system integrators, not the maintainers of the software itself. As a result, public money flows to companies that package and resell Open Source, not to the ones who do the hard work of writing and sustaining it.

I've watched this pattern repeat for over two decades in Drupal, the Open Source project I started and that is now widely used across European governments. A small web agency spends months building a new feature. They design it, implement it, and shepherd it through review until it's merged.

Then the government puts out a tender for a new website, and that feature is a critical requirement. A much larger company, with no involvement in Drupal, submits a polished proposal. They have the references, the sales team, and the compliance certifications. They win the contract. The feature exists because the small agency built it. But apart from new maintenance obligations, the original authors get nothing in return.

Public money flows around Open Source instead of into it.

Multiply that by every Open Source project in Europe's software stack, and you start to see both the scale of the problem and the scale of the opportunity.

This is the pattern we need to break. Governments should be contracting with maintainers, not middlemen.

Public money flows around Open Source instead of into it. Governments should contract with maintainers and builders, not middlemen.

Skipping the maintainers is not just unfair, it is bad governance. Vendors who do not contribute upstream can still deliver projects, but they are much less effective at fixing problems at the source or shaping the software's future. You end up spending public money on short-term integration, while underinvesting in the long-term quality, security, and resilience of the software you depend on.

If Europe wants digital sovereignty and real innovation, procurement must invest in upstream maintainers where security, resilience, and new capabilities are actually built. Open Source is public infrastructure. It's time we funded it that way.

The fix is straightforward: make contribution count in procurement scoring. When evaluating vendors, ask what they put back into the Open Source projects they are selling. Code, documentation, security fixes, funding.

Of course, all vendors will claim they contribute. I've seen companies claim credit for work they barely touched, or count contributions from employees who left years ago.

So how does a procurement officer tell who is real? By letting Open Source projects vouch for contributors directly. Projects know who does the work. We built Drupal's credit system to solve for exactly this. It's not perfect, but it's transparent. And transparency is hard to fake.

We use the credit system to maintain a public directory of companies that provide Drupal services, ranked by their contributions to the project. It shows, at a glance, which companies actually help build and maintain Drupal. If a vendor isn't on that list, they're most likely not contributing in a meaningful way. For a procurement officer, this turns a hard governance problem into a simple check: you can literally see which service providers help build Drupal. This is what contribution-based procurement looks like when it's made practical.

Fortunately, the momentum is building. APELL, an association of European Open Source companies, has proposed making contribution a procurement criterion. EuroStack, a coalition of 260+ companies, is lobbying for a "Buy Open Source Act". The European Commission has embraced an Open Source roadmap with procurement recommendations.

Europe does not need to build the next hyperscaler. It needs to shift procurement toward Open Source builders and maintainers. If Europe gets this right, it will mean better software, stronger local vendors, and public money that actually builds public code. Not to mention the autonomy that comes with it.

I submitted this post as feedback to the European Commission's call for evidence on Towards European Open Digital Ecosystems. If you work in Open Source, consider adding your voice. The feedback period ends February 3, 2026.

Special thanks to Taco Potze, Sachiko Muto, and Gábor Hojtsy for their review and contributions to this blog post.

21 Jan 2026 3:59pm GMT

New versions of the CKEditor contributed modules bring new formatting and content control features to Drupal. Premium Features module 1.7.0 introduces Footnotes and Line Height support, expanding the toolkit for structured writing and print-optimized formatting. The release also includes support for watermarks in Word exports and several fixes to improve authoring experiences and compatibility. Plugin Pack module 1.5.0 delivers the long-awaited Restricted Editing feature for locked-down templates and controlled collaboration, along with configuration improvements to Layout Tables and general stability fixes.

21 Jan 2026 1:53pm GMT

Monday January the 12th 2026, the UI Suite team has proudly released the first beta of the Display Builder module, a display building tool for ambitious site builders:A single display building tool deeply integrated with DrupalIts powerful unified UI can be used instead of Layout Builder for entity view displays, Block Layout for page displays, and as a replacement of the Views' display building feature. No more struggle with overcomplicated inconsistent UIs!

21 Jan 2026 12:49pm GMT

Speed up your testing with Deuteros

At Tag1 we like performance.

We also like not being yelled at because a recently released production build introduced a major regression and suddenly the dev team has to scramble to hot-fix the issue.

Our industry has settled for quite a while now on a solid strategy to avoid that scenario: automated testing. It's not a silver bullet but, when done right, it can hugely increase confidence in making changes to large and/or complex codebases, where even minimal tweaks can sometimes trigger very hard to predict side-effects.

Doing it Right

Automated testing is a vast and complex subject, with some grey areas, especially around terminology; however, there's a key principle it's a good idea to stick to: always run your automated tests after any change.

If you are embracing Test Driven Development, you'll have written new tests covering the changes you are working on before implementing them: this will require running tests multiple times before the task is over. However, even if you are following a more traditional approach, writing test coverage after implementing changes, you will still end up running tests very often.

Admittedly, in the cases above we are talking about a very limited set of tests; however, if tests run slowly, even those will add a significant overhead to development time.

Another widely accepted best practice is to run the entire test suite before merging a change into the project's repository. This both ensures that the new code behaves as expected and that no regression was introduced in the process. Once again, if tests run slowly, it may take a long time to get feedback, adding further overhead due to context switching.

Aside from the impact on developer experience, which at Tag1 is taken very seriously, the larger the overhead, the harder it is to justify to clients the amount of time spent implementing a change. I guess I don't need to describe the cascading effects.

The Test Pyramid

An approach that's very effective in addressing test speed issues is the test pyramid: without going too much into detail, the idea is that a test suite should be organized in a pyramidal shape with multiple layers getting smaller and slower to run as they approach the top.

This commonly translates into having:

• A large amount of fast-running unit tests, covering individual aspects of the codebase.

• A medium amount of integration tests combining multiple units into a consistent (sub)system and testing its behavior.

• A small amount of end-to-end (E2E) tests pulling everything together and testing the business-critical behaviors of the entire codebase.

  

What about Drupal?

At Tag1 we do many things, but Drupal has a special place in our hearts. However, running Drupal tests quickly has often been challenging.

Support for automated tests was initially added to Drupal 7 and, as awesome as it was at the time, it involved running a full site installation in the test setup phase before being able to perform a single assertion. The Simpletest framework focused mainly on UI testing and, even if it was sort of possible to use it to write unit tests, it was like driving to your favorite movie theater during rush hour just to check whether the car battery was wired properly. As you can imagine, it took time.

In Drupal 8 and above the situation vastly improved with the adoption of the PhpUnit testing framework. Multiple types of tests were introduced:

• Browser tests (and their companion WebDriver tests) are the successors to the original Simpletests and are primarily meant to perform UI testing. These are a very good fit to implement E2E tests, as they cover the full request/response scope, albeit being slow, as they still require an installed site and a full Drupal bootstrap.

It should be noted that the introduction by Moshe Weitzman of Drupal Test Traits helped to speed up these tests, as it allows them to run with an existing database, instead of installing an empty site from scratch every time.

use Deuteros\Double\EntityDoubleFactory;
use Deuteros\Double\EntityDoubleDefinitionBuilder;

class MyServiceTest extends TestCase {

  public function testMyService(): void {
    // Get a factory (auto-detects PHPUnit or Prophecy)
    $factory = EntityDoubleFactory::fromTest($this);

    // Create an entity double
    $entity = $factory->create(
      EntityDoubleDefinitionBuilder::create('node')
        ->bundle('article')
        ->id(42)
        ->label('Test Article')
        ->field('field_body', 'Article content here')
        ->build()
    );

    // Use it in your test
    $myService = new MyService();
    $myService->doStuff($entity);
    
    // These assertions would all pass
    $this->assertInstanceOf(EntityInterface::class, $entity);
    $this->assertSame('node', $entity->getEntityTypeId());
    $this->assertSame('article', $entity->bundle());
    $this->assertSame(42, $entity->id());
    $this->assertSame('Article content here', $entity->get('field_body')->value);
  }

}

class MyNodeTest extends TestCase {

  private SubjectEntityFactory $factory;

  protected function setUp(): void {
    $this->factory = SubjectEntityFactory::fromTest($this);
    $this->factory->installContainer();
  }

  protected function tearDown(): void {
    $this->factory->uninstallContainer();
  }

  public function testNodeCreation(): void {
    $node = $this->factory->create(Node::class, [
      'nid' => 42,
      'type' => 'article',
      'title' => 'Test Article',
      'body' => ['value' => 'Body text', 'format' => 'basic_html'],
      'status' => 1,
    ]);

    // Real Node instance with DEUTEROS field doubles.
    $this->assertInstanceOf(Node::class, $node);
    $this->assertSame('node', $node->getEntityTypeId());
    $this->assertSame('article', $node->bundle());
    $this->assertSame('Test Article', $node->get('title')->value);
    $this->assertSame('Body text', $node->get('body')->value);
  }

}

21 Jan 2026 12:00am GMT

A few weeks ago, Simon Willison started a coding agent, went to decorate a Christmas tree with his family, watched a movie, and came back to a working HTML5 parser.

That sounds like a party trick. It isn't.

It worked because the result was easy to check. The parser tests either pass or they don't. The type checker either accepts the code or it doesn't. In that kind of environment, the work can keep moving without much supervision.

Geoffrey Huntley's Ralph Wiggum loop is probably the cleanest expression of this idea I've seen, and it's becoming more popular quickly. In his demonstration video, he describes creating specifications through conversation with an AI agent, then letting the loop run. Each iteration starts fresh: the agent reads the specification, picks the most important remaining task, implements it, runs the tests. If they pass, it commits and exits. The next iteration begins with empty context, reads the current state from disk, and picks up where the previous run left off.

If you think about it, that's what human prompting already looks like: prompt, wait, review, prompt again. You're shaping the code or text the way a potter shapes clay: push a little, spin the wheel, look, push again. The Ralph loop just automates the spinning, which makes much more ambitious tasks practical.

The difference is how state is handled. When you work this way by hand, the whole conversation comes along for the ride. In the Ralph loop, it doesn't. Each iteration starts clean.

Why? Because carrying everything with you all the time is a great way to stop getting anywhere. If you're going to work on a problem for hundreds of iterations, things start to pile up. As tokens accumulate, the signal can get lost in noise. By flushing context between iterations and storing state in files, each run can start clean.

Simon Willison's port of an HTML5 parsing library from Python to JavaScript showed the principle at larger scale. Using GPT-5.2 through Codex CLI with the --yolo flag for uninterrupted execution, he gave a handful of directional prompts: API design, milestones, CI setup. Then he let it run while he decorated a Christmas tree with his family and watched a movie.

Four and a half hours later, the agent had produced a working HTML5 parser. It passed over 9,200 tests from the html5lib-tests suite. HTML5 parsing is notoriously complex. The specification precisely defines how even malformed markup should be handled, with thousands of edge cases accumulated over years. But the agent had constant grounding: each test run pulled it back to reality before errors could compound.

As Willison put it: "If you can reduce a problem to a robust test suite you can set a coding agent loop loose on it with a high degree of confidence that it will eventually succeed". Ralph loops and Willison's approach differ in structure, but both depend on tests as the source of truth.

Cursor's research on scaling agents confirms this is starting to work at enterprise scale. Their team explored what happens when hundreds of agents work concurrently on a single codebase for weeks. In one experiment, they built a web browser from scratch. Over a million lines of code across a thousand files, generated in a week. And the browser worked.

That doesn't mean it's secure, fast, or something you'd ship. It means it met the criteria they gave it. If you decide to check for security or performance, it will work toward that as well. But the pattern is the same: clear tests, constant verification, agents that know when they're done.

From solo loops to hundreds of agents running in parallel, the same pattern keeps emerging. It feels like something fundamental is crystallizing: autonomous AI is starting to work well when you can accurately define success upfront.

Willison's success criteria were "simple": all 9,200 tests pass. That is a lot of tests, but the agent got there. Clear criteria made autonomy possible.

As I argued in AI flattens interfaces and deepens foundations, this changes where humans add value:

Humans are moving to where they set direction at the start and refine results at the end. AI handles everything in between.

The title of this post comes from Geoffrey Huntley. He describes software as clay on the pottery wheel, and once you've worked this way, it's hard to think about it any other way. As Huntley wrote: "If something isn't right, you throw it back on the wheel and keep going". That's exactly how it feels. Throw it back, refine it, spin again until it's right.

Of course, the Ralph Wiggum loop has limits. It works well when verification is unambiguous. A unit test returns pass or fail. But not all problems come with clear tests. And writing tests can be a lot of work.

For example, I've been thinking about how such loops could work for Drupal, where non-technical users build pages. "Make this page more on-brand" isn't a test you can run.

Or maybe it is? An AI agent could evaluate a page against brand guidelines and return pass or fail. It could check reading level and even do some basic accessibility tests. The verifier doesn't have to be a traditional test suite. It just has to provide clear feedback.

All of this just exposes something we already intuitively understand: defining success is hard. Really hard. When people build pages manually, they often iterate until it "feels right". They know what they want when they see it, but can't always articulate it upfront. Or they hire experts who carry that judgment from years of experience. This is the part of the work that's hardest to automate. The craft is moving upstream, from implementation to specification and validation.

The question for any task is becoming: can you tell, reliably, whether the result is getting better or worse? Where you can, the loop takes over. Where you can't, your judgment still matters.

The boundary keeps moving fast. A year ago, I was wrestling with local LLMs to generate good alt-text for images. Today, AI agents build working HTML5 parsers while you watch a movie. It's hard not to find that a little absurd. And hard not to be excited.

20 Jan 2026 7:39pm GMT

Aidan Foster - Strategy Lead, Foster Interactive

The Big Shift in Web Creation

For years, the hardest part of building a website was technical execution. Slow development cycles, code barriers, and long timelines created bottlenecks.

AI has changed this.

Execution is no longer the limiting factor. Understanding is. The new challenge is knowing your audience, clarifying your message, and structuring the story your website needs to tell.

The future is not prompt-first. It is people first. Strategy, insight, empathy, and structure.

This was the core message of my talk AI Page Building with Drupal Canvas. It is also why Foster Interactive joined the Drupal AI Makers initiative.

But none of this works unless the human layer comes first.

Why People-First AI Matters and Why AI Slop Happens

AI is a powerful assistant, but it cannot replace human judgment.
Large language models can synthesize patterns, but they cannot invent your strategy.

When teams skip the foundational work such as audience research, messaging clarity, and brand systems, AI produces generic output that feels shallow and off-brand.

This is what we call AI slop. The issue is not the model. The issue is unclear inputs.

AI can only accelerate the parts you already understand. The human layer must come first. Audience insight. Value propositions. Tone and language rules. Page-level content strategy.

Without this structure, every output becomes guesswork.

The New Tools: Canvas and the Context Control Center

Drupal's new AI features are powerful because they finally support how marketers work.

Canvas: The visual editor built for marketers

Canvas allows anyone to build pages using drag and drop.
It offers instant previews, mobile and desktop views, simple undo and redo, and AI built directly into the editor.

You can ask Canvas to assemble a campaign landing page and it uses your brand components, design system, content rules, and tone to create useful starting points.

This is the most marketer-friendly Drupal experience ever made.

The Context Control Center: The AI knowledge base

This is where strategy becomes usable by AI. It allows teams to load audience personas, value propositions, tone guides, brand rules, page templates, messaging frameworks, and content strategy documents.

With this context available, the AI produces work that is aligned, accurate, and consistent.

Instead of guessing, it draws from your organization's strategic foundation.
For the first time, brand and audience knowledge can be reused across the entire website.

The Demo: How We Built FinDrop Landing Page Demo

To demonstrate what is possible, we built a fictional SaaS company called FinDrop.

We created product stories, value props, audience personas, PPC ads, content strategy, and a visual system that matched the Mercury design system.

We generated all of this using strategy first, then AI. We crafted brand rules, used Nano Banana for consistent imagery, built campaign assets, and generated full landing pages for three stages of a funnel.

AI gave us speed, but only because the human structure was already in place. Without strategy the output collapsed. With structure it accelerated.

The Real Lesson: AI Only Works When the Inputs Are Strong

The FinDrop demo made something clear. AI did not save time because it is smart. It saved time because the rules were defined. Your success depends on the strength of your foundations.

Clear value propositions. Real audience insight. A defined tone. Predictable page patterns. Brand rules the AI can follow. Without this, AI slows teams down.

At Foster Interactive we are testing the best models for Drupal workflows, refining content strategy structures for the Context Control Center, creating systems to make AI-ready brands easier to build, and bringing the marketer's perspective into the AI Makers roadmap.

Our goal is simple. Make AI genuinely useful for small marketing teams without sacrificing accuracy or authenticity.

What Is Coming Next for Drupal AI and Why It Matters

Drupal CMS 2 is coming in early 2026. It will include deeper Canvas integration, more intuitive site templates, a lighter AI suite, reusable design systems, expanded knowledge base support, and better tools for auditing and maintaining content.

But the biggest change is this. It will become easy to install the tools and it will be obvious who has done the strategic work. Teams relying solely on AI will blend into the noise.

Teams grounded in human insight will stand out.

Now Is the Time to Unlearn What Is Possible

A few months ago, I did not believe a CMS could generate usable landing pages in minutes or create consistent AI imagery. Then we built FinDrop.

The tools have changed. The pace has changed.

Human insight cannot be outsourced to AI.

We want our AI tools to take care of boring, repetitive jobs to free up our time for creative and strategic work.

The role of marketers is shifting away from production bottlenecks and toward clarity, empathy, positioning, narrative, and audience understanding.

AI can accelerate execution and remove repetitive tasks. But it cannot replace the strategy behind them.

If we get the human foundations right, we create a future where imagination becomes the bottleneck, not time.

That's the future I want to live in.

Ready to put people-first AI into practice?

Start with your foundations. Sit down with your team and audit your brand guidelines. Talk to front-line support and sales - the people closest to your customers. Update your tone, messaging, and audience details. This is the work that makes AI useful.

Then try Canvas. Once your foundations are solid, test what's possible with the upcoming Drupal CMS 2.0 demo at drupalforge.org. (Or if you're a little more technical, test the Driesnote Demo which is available right now).

20 Jan 2026 6:05pm GMT

Friday, 2:00 PM. New developer, production bug. Something's broken with a custom queue worker. In the past, this meant tracking down the previous developer, consultations, wasting time - all on a Friday. Now? The developer asks artificial intelligence and AI responds with useful answers because it knows the project. How? Just one file: AGENTS.md.

20 Jan 2026 12:14pm GMT

For years, Drupal relied on the doctrine/annotations library to add metadata to plugin classes. This approach works through docblock comments. The /** ... */ blocks that appear above class definitions. While convenient, this method has several inherent limitations and will be gradually replaced by PHP attributes.

20 Jan 2026 8:03am GMT

Losing track of revisions after repeated edits in Drupal? Learn how Entity Reference Revisions preserves content integrity by ensuring safe edits, accurate history, and reliable workflows.

20 Jan 2026 5:44am GMT