Drupal CMS 2.0 still sits on Drupal Core. The same platform known for extensibility, structured content, complex workflows and long-lived websites is underneath the newer editing experience. That distinction matters.

There are plenty of tools that can make putting something on a webpage easy.

The harder question is what happens afterwards and what happens down the road.

What happens when the site grows? When five editors become fifty? When content needs to appear in more than one place? When the organization needs workflows, permissions, integrations, translations, governance and years of future changes?

What feels different now is that the people creating and managing the content do not have to pay such a high usability price to get it.

Easy today isn’t enough. The platform has to stay healthy tomorrow. That is the part of Drupal I have always believed in. Durability, tested through over 25 years of success. Open source with an excellent, devoted community behind it.

I watched the platform grow up

Cool Fire has been a Drupal shop since 2008. I watched the platform grow up. That depth is exactly what I bring to the AI work now.

There were years when I would recommend Drupal because I knew what we could engineer with it, while also knowing we would have to work hard to make parts of the experience easier for the people using it every day.

Now I find myself excited about the experience itself. Canvas is easier. The component approach is cleaner. AI is becoming useful inside the workflow instead of being bolted onto the side.

The content can still have the structure that makes Drupal so powerful in the first place, while the whole platform feels much more approachable without feeling less serious.

After working with Drupal for this long, that is what surprises me most.

It doesn’t feel like Drupal became something else.

It feels like Drupal finally made more of its power accessible to more of the people who were supposed to benefit from it all along. And for someone who has been watching since Drupal 6, it really does feel like a whole new world.

This is the third and final piece of a longer reflection on Drupal CMS 2.0.

Drupal CMS 2.0 doesn’t treat AI as a novelty sitting off to the side. Current features include Canvas AI for generating landing pages from prompts, an administrative chatbot that can help with site-building tasks, and AI-generated alt text for images. Drupal’s current product direction also includes AI-assisted content creation, editing and review as part of the CMS experience.

That’s where I think AI becomes interesting.

I don’t need a CMS to put an AI button somewhere so it can say it has AI. I want AI where the work is happening, integrated. If I’m creating a page, help me create it. If I’m organizing content, understand the content model. If I’m working inside a structured system, use that structure as context. Drupal is particularly well positioned for this because structure has always been one of its strong suits.

Content types, fields, taxonomy and reusable content give Drupal an underlying model of what the information actually is. Drupal CMS continues to emphasize structured content that can be organized, reused and published across different experiences. That structure was valuable before AI, and it may become even more valuable because of AI.

We are already seeing what that structure can mean

We recently ran Cool Fire’s own Drupal site through the FireUp AIO AI Visibility Scorecard. Our overall score was 64 out of 100, so there is plenty we still want to improve. But the Foundation pillar scored 100%. “Foundation” measures structural signals (e.g., semantic HTML, schema, entity clarity) where Drupal naturally excels.

I found that particularly interesting because the foundation is exactly where Drupal has always been strong. Good content is not just words sitting on pages. It has structure, relationships, context and meaning.

That doesn’t mean Drupal automatically gives you perfect AI visibility. It doesn’t on its own. Our own scorecard identified work we still need to do around expertise, citations, case studies and measurable proof. But it does reinforce something I have believed for a long time and that’s when the underlying structure is built well, you are starting from a much better place.

This is the second piece of a longer reflection on Drupal CMS 2.0, more coming.

I’ve carried sites through version after version since then, including the Drupal 7 to 8 rewrite. I’ve watched Drupal become more powerful, more sophisticated and more capable of running websites that organizations depend on every day.

I’ve also watched it make some things much harder than they needed to be.

That was always the tradeoff. With great power came... great complexity. But with Drupal CMS 2.0, the platform finally gets its hero arc.

Drupal could do almost anything, but getting all that power into the hands of the people actually managing the content often took more effort than it should have. Developers understood why Drupal was special. Editors did not always have the same experience.

That’s where Drupal CMS 2.0 enters the picture. It’s not just another version of Drupal.

It feels like Drupal has finally brought two things together that used to live much farther apart: serious engineering underneath and an editing experience that content teams can actually enjoy using.

Canvas changes the conversation

Drupal Canvas may be the part I am most excited about.

Canvas is now the default editing experience in Drupal CMS 2.0. Editors can drag components onto a page, see what they are building as they work and edit directly in context instead of bouncing back and forth between administrative forms and previews.

That sounds simple until you have spent years building CMS websites. The ability to give an editor a visual, drag-and-drop experience without giving up the structure underneath is more of a big deal than one may realize. An editor can work with things that make sense to an editor: a hero, a card, a testimonial, an accordion or a callout. Drupal CMS ships with reusable components for exactly those kinds of building blocks.

But developers are not giving up engineering discipline to make that possible.

Drupal’s Single Directory Components, or SDCs, provide a component architecture where a component’s metadata, markup and, when needed, CSS and JavaScript coexist. They are modular, reusable building blocks rather than one-off page constructions.

That matters because good visual editing should not mean chaos underneath, as visual builders lacking underlying structure often do.

The editor gets freedom while the organization gets consistency. And the developer? The protagonist in this story, still gets maintainable code.

That’s the balance I have wanted Drupal to reach for a very long time.

This is one piece of a longer reflection on Drupal CMS 2.0, more coming.

The problem is that most of us don’t know with precision what to ask. And the tools don’t know the difference.

The Instruction Gap

There’s a meaningful difference between a tool that does what it’s told and a tool that does what you meant for it to do. AI tools are definitely in the first category. They generate output that matches the instruction put in, not the output you’re thinking of. And that accounts for everything the instructions left out.

The compliance requirement that limits what data can be stored where. The future integration that will need this system to behave in a specific way. The security implication of a particular architecture choice. The module that is widely used but poorly maintained. The most important parts of any development decision are the constraints that never appear in the prompt.

AI tools don’t ask about these. They execute against what was specified and produce something that works within that narrow frame. Whether it works within the broader context of the organization’s actual requirements is a different question.

What “It Works” Means

One of the most common misreadings of AI-generated code and content is treating it as a finished product. It generates, it functions, it deploys. The temptation is to treat all of that as completed work you can run with.

When someone says AI-generated code works, here’s what that actually establishes. It produces the expected output given the tested inputs, in the environment where it was tested. It doesn’t mean that it will handle edge cases. It doesn’t mean that it is structured in a way that will be maintainable in two years. It doesn’t mean that it follows the security practices your industry requires. It also doesn’t mean that it will integrate cleanly with the systems you add next year.

Those evaluations require judgment.

Where AI Tools Actually Excel

The point isn’t that AI tools are bad. They’re genuinely useful for many tasks.

They’re good at generating boilerplate code scaffolding, the repetitive structure, the starting point that would otherwise take an engineer a day to produce. They’re very good at documentation and summarizing what a function does then generating first drafts that get edited into something better. They’re good at exploration into things as well. They test approaches quickly, comparing patterns, and generating options for a decision that requires a human to make.

They’re tools, plain and simple, even though they may seem otherwise. The organizations that use them most effectively use them as part of a process that includes human judgment, and not as a replacement for it. The human side matters.

The Compounding Effect

AI-generated code and content has a quality that is often plausible but not quite optimal. It follows common patterns, just like people do.

But, the problem is that looking right isn’t the same as being right when it comes to content and solutions. When a senior engineer reviews AI-generated output, they are evaluating it against a set of criteria the AI didn’t have access to. Most non-engineers reviewing AI output aren’t able to make that evaluation; they see something that looks like it works and they accept it and move on.

The gaps that get skipped at that stage continue to compound. A first unstable, fragile, or insecure pattern could get replicated. An architecture that doesn’t scale may get extended. By the time the problem is visible enough to be realized, addressing it requires reworking everything built on top of the original issue.

What Senior Engineers Do Differently With AI Tools

Senior engineers use AI tools too but the difference is in how they use them and what they do with the output.

They prompt with constraints that reflect the actual context: the specific platform, the compliance requirements, the integration architecture, the performance characteristics and goals the system needs to hit. They review what comes back against criteria the tool did not have. They keep the parts that are good and discard the parts that are lacking or just downright wrong, including parts that may look right but are not.

They treat AI output as a first draft, not a final product, just as a content creator should as well. The engineering judgment that makes a first draft useful is not only in the well planned generation, but in the evaluation.

The Platform Question This Creates

For organizations that have used AI builders to launch sites and applications, the question is not whether to use AI, it’s whether the output has been evaluated by someone with the judgment to know what’s missing, including the obvious and not so obvious.

A site built in Framer or with Lovable can be a valid starting point. It can also be a platform with structural security gaps, SEO ceilings, and architectural decisions that limit what the organization can build on top of it. The tool that built it does not know which situation applies. That evaluation requires a person capable of that call.

Before You Build Anything Else On Top Of It

If you’ve already launched something built with an AI tool, here are five questions worth asking before you add the next thing.

1. Where does your data actually live, and does that hold up against the rules your industry has about it?

2. What happens on the inputs nobody reviewed or tested? Not the demo path, the wonky ones.

3. If you handed this to a new developer in two years, could they pick up where you left off, or would they want to start over?

4. Are the modules and libraries in it actually maintained, or just widely used? Those aren’t the same thing.

5. What’s the next system you’ll want to connect this to, and has anything already been decided that makes that harder?

If you can’t answer these, that isn’t a failure. It’s the evaluation the tool couldn’t do for you. Where does your code or content fall?

What happens is quieter, and it is why it goes on so long.

A while ago we were brought into a Drupal site that looked completely fine from the outside. Loaded properly, looked professional, nothing visibly wrong.

The forms were not working. Emails were not going out.

Sit with that for a second, because it is worse than a site being down. A site that is down tells you. Everybody knows within the hour and somebody fixes it. A form that quietly fails tells nobody. People filled it in, hit send, saw a thank you message, and went about their day thinking they had reached someone.

Nobody on the business side had any way to know. There is no alert for the message that never arrived.

There was more. Functionality already built into the site was not doing what it was supposed to do. Other things the business genuinely needed built could not get built, because the work had outgrown the setup they had. So the list of things that did not quite work got longer, and everyone learned to route around it.

That is the pattern, and I see it constantly. **No single bad decision. A hundred small workarounds nobody wrote down.**

When we got into the code we found the rest of it. There was broken code, messy code, and patched patches. Problems layered on top of older problems, in the way that happens when every fix has to avoid the last one.

The client was frustrated and genuinely did not know what to do next. That is the honest emotional middle of this story and I think it is the most common place for a business owner to be. They weren’t indifferent, they were stuck. Aware something was wrong, unable to describe it precisely enough to ask for the right help, and braced for someone to say the whole thing had to be rebuilt.

It did not have to be rebuilt.

We refactored the code that was causing the trouble. We built the functionality they had been waiting on. We fixed the long tail of things that were not working properly.

It was the same site and same platform, and their content and their history all stayed exactly where they were.

What changed is that it worked. The forms went through. The emails arrived. The functionality they had been unable to get built existed. The workarounds went away, and so did the complaints, which in a story like this one means more than it sounds like, because the silence before was the problem.

The client was thrilled. Sales went up and their customers were happier with the experience.

Here is the thing I most want you to take from this story.

Their site was costing them money for months and it did not look like anything was wrong. That is the whole danger. A slow site is annoying and a hacked site is a crisis, but both of those announce themselves. A form that silently drops leads doesn’t. Neither does functionality that just annoys people, quietly, with nothing reporting it. Problems like those keep going for as long as nobody tests them.

So while you are here, go and do these five things. They take about fifteen minutes.

1. **Fill in your own contact form.** All the way through, like a stranger would. Then confirm the message actually arrived somewhere a human reads.

2. **Do the same for every other form**, quote requests, newsletter signups, applications, event registrations. **Forms fail one at a time, not all together.**

3. **Ask whoever maintains your site when the last security update was applied**, and if anything broke when it was. If nobody knows, that is your answer.

4. **Write down every workaround your team uses.** Note the “oh you have to do it this way” instructions. Each one is a broken thing no one is fixing.

5. **Ask what your team has wanted to build and could not.** The reason is usually the real diagnosis.

If that list turns up nothing, genuinely good. You are in better shape than most.

If it turns up something, you have not found a disaster. You have found the thing that was quietly true anyway, and now you can decide what to do about it.

That is a much better position than not knowing.

The businesses that get stuck aren’t lazy and they’re not behind on tools. They’re carrying too much that only exists in one person’s head, sitting on top of systems that were never built for anyone else to understand.

I’ve spent twenty-one years building and untangling the systems businesses run on. Before that it was servers, networks, and databases, so I’ve seen this from a few angles. Lately a lot of that work is AI. Which is where this gets interesting. AI is the first tool that genuinely cannot help you until what’s in your head is gathered somewhere it can reach. Once it is, and you point AI at it with the right directions and guardrails, the thing that only existed in one person’s head becomes something your whole business can benefit from.

That’s what this newsletter is about. Signal is the part that actually matters. Structure is what makes it usable by someone other than you, including, now, by AI.

Here’s what to expect. Short pieces, most of them under five minutes. Plain language, because most of the jargon in my industry exists to make simple things sound expensive. And occasionally, something you can actually go do at the end, not just something to think about.

I’ll write about websites, because that’s where the scar tissue came from. I’ll write about AI honestly, including the parts that are overhyped and the parts that genuinely changed how my own company works. And I’ll write about the unglamorous structural things that decide whether either one is of any help to you at all.

If you’re sitting on a website that’s holding you back, or trying to work out where AI actually fits in your business, that’s what I’m here for.