The question I get most these days is: did AI kill the CMS? Should we still invest in a CMS, switch to AI agents, or wait until the market becomes clearer?

At a friend's birthday party recently, I was talking with engineers and startup CEOs. They were all smart people, but none of them worked in the CMS industry. From where they sat, AI seemed to make the CMS obsolete.

I understand why. AI can now generate copy, design pages, write code, translate content, and assemble websites. If that is what you think a CMS is for, it does look like the CMS is in trouble.

They may be right about one part of the CMS market. But I think they are wrong about the larger picture.

To see why, it helps to separate what a content management system, or CMS, does into two planes: the control plane and the execution plane.

The control plane governs content: who can edit it, what gets approved, which version is canonical, how translations move through workflow, and where content can be used.

The execution plane creates, assembles, and delivers that content into websites, mobile apps, feeds, and other customer experiences.

AI is unbundling these two planes. It is commoditizing the execution plane while making the control plane more valuable. That is why I think AI is killing one corner of the CMS market, but making the CMS more critical everywhere else.

AI lowers the cost of creation, not the cost of trust

We have seen this pattern before. The printing press made it cheap to produce and distribute content, but it did not make editors or publishers irrelevant. It made them more important, because more content created more need for judgment, trust, and standards.

AI is doing something similar to digital content. It makes production cheaper: drafting, generating, translating, designing, assembling pages, and adapting content for different channels.

But AI should not be the final authority on what is correct, approved, compliant, or safe to publish. It can help, but people and systems still need to own those decisions. The more content AI helps produce and distribute, the more that ownership matters.

As production gets cheaper, control becomes more important, not less.

That is the real test for a CMS. Not whether AI can generate content or build a page, but whether your organization needs a control layer: roles, review, approvals, publishing states, revision history, and more.

How shared is your work?

Two simple questions can help decide how much you need a CMS:

1. How many people or agents create, review, and publish content?
2. How many systems need to use, update, or trust that content?

Put those questions on a grid, and four use cases emerge.

When one person creates and publishes content, and no other systems depend on it, you may not need a CMS. A lightweight publishing tool or AI site builder may be enough.

When multiple people or agents touch content, you need a CMS for coordination: roles, review, approvals, publishing states, and revision history. AI inside the CMS can help teams create, review, and publish faster without losing control.

When many systems touch content, you need a CMS as the trusted source for content, permissions, workflows, and publishing controls. AI around the CMS can coordinate work across tools, but it still depends on the CMS to know what content is approved, who can use it, and where it can go.

In short, when many people and many systems are involved, the CMS becomes the critical control layer for people, agents, and systems working together. It gives people and agents a safe place to create and approve content, and gives other tools a trusted system they can read from, write to, and build on.

The decision, by quadrant

1. Assist: one person, one system

This is the simplest case: one person, one system, and little coordination.

If you are creating a new website quickly, an AI site builder may be the right tool. It can turn a prompt into a working site in an afternoon. In that case, a CMS may slow you down more than it helps. This is 1a in the quadrant image: the job is to create, not to manage.

But one person does not always mean a CMS is unnecessary.

My website has been around for more than twenty years. It has more than 1,500 blog posts and 10,000 photos. That is not just a website to create; it is a body of content to manage. Drupal helps me manage that content as structured content: content types, fields, taxonomy, media, revisions, URLs, and search.

I would not move my site to a standalone AI site builder. But I do use an AI agent to work on it through Drupal: updating content, improving existing features, and building new ones. This is 1b on the chart. AI helps with the execution work, while Drupal remains the control plane. This is unbundling at the smallest scale.

So use an AI builder when speed to a new site matters most. Use a CMS when the work is about managing a large or growing body of content over time: keeping it structured, consistent, reusable, and reliable.

2. Relay: many people, one system

This is a clear case for a CMS.

When many people collaborate on one website, the work becomes a "relay": a designer uploads an image, a developer builds a component, a marketer writes the copy, an editor reviews the page, legal approves it, and someone presses publish.

AI does not remove that relay; it makes it move faster. The developer may use an AI coding agent, the marketer may use an AI writing assistant, and the editor may use an AI policy checker. More work moves through the same website, with less time between handoffs.

But the moment several people and several agents are working on the same website, you need a control layer to manage roles, permissions, approvals, revision history, and one source of truth.

A CMS lets teams move at AI speed without losing track of who changed what, which version is approved, and what is safe to publish.

3. Delegate: one person, many systems

Here the logic changes. You are still one person, so there is little coordination with other people. But the work now spans many systems: a CMS, an email marketing platform, a commerce system, a CRM, and a planning tool.

When one person spans many systems, no single product sees the whole job. The center of gravity moves to the coordinator: an automation tool that connects your systems, or an AI agent that works across their APIs.

That is why this quadrant is debatable. For a short-lived campaign, you may not need a traditional CMS. You might use an AI builder for the site and an automation tool or agent to coordinate the rest.

But that only works while the content is small, short-lived, and easy to manage by hand. Once the content has to be structured, reused, updated, approved, or kept consistent across systems, you need a trusted source for it.

4. Orchestrate: many people, many systems

This is the most complex environment, and the clearest case for a CMS.

A company campaign can involve many people and many systems at once: a marketer plans the campaign, a designer reviews the creative, legal approves the content, an editor publishes the page, marketing operations builds the email, and a commerce manager checks the discount. Every person has a role, and every system has a workflow.

AI can remove much of the coordination work: reminders, status updates, handoffs, and manual routing. But coordination is not control. Someone still has to approve the content, approve the promotion, and answer for the campaign's effectiveness.

In this quadrant, the CMS has two jobs. First, it has to govern and accelerate the work that happens inside the CMS. Second, it has to make that work usable by the broader digital ecosystem.

The CMS is not necessarily the orchestrator of that ecosystem. It is the governed workspace where people and agents can work safely, and the trusted source that other systems and agents can read from, write to, and build on.

At this scale, and at AI speed, a weak content foundation becomes expensive fast. A strong CMS is not optional.

From unbundling to rebundling

One thing the grid does not show is where the market is moving the fastest. Right now, most of the visible energy is on the bottom row of Assist and Delegate, sections 1a and 3a, where no control plane is needed: one person using AI to create and coordinate faster.

In Assist, that means AI site builders that turn an idea into a working website. In Delegate, it means agents and automation for single-person workflows across different systems.

Lovable reportedly reached roughly $400 million in annual recurring revenue less than two years after launch. n8n raised $180 million at a $2.5 billion valuation in 2025.

But once many people are involved, individual productivity is no longer enough. Organizations need productivity, coordination, and control.

The current wave of AI site builders is mostly making one person faster. The next wave has to make organizations faster without losing trust.

AI is unbundling creation from the CMS and driving its cost toward zero. But once creation becomes cheap and abundant, the value shifts to control.

That is where rebundling starts. The next generation of products will combine AI-powered creation with a trusted control plane.

So, is the CMS dead? No. Its role is changing.

The more AI you use to create, translate, update, and publish content, the more you need a system that keeps that work structured, approved, reusable, and safe.

That means that a CMS is not a competing line item to your AI budget. It is what makes that budget pay off.

And the real risk is not that AI replaces your CMS. It is running AI without one.

AI gives you speed. A CMS gives you control at speed.

Working with larger organizations, it’s common to want to split off a section of content into its own smaller site.

A city may want a separate site for a particular construction project, or a university may want one for a capital campaign. Marketing teams often need smaller, dedicated sites for communication and promotion.

They’re usually not complex. Often it’s a matter of a different navigation, some different branding, and a unique URL. But they still need to be designed, built, hosted, and managed — somewhere. And they’re usually needed quickly (like, now).

Whether you’re launching your first or looking for a better way to manage the ones you have, let’s explore these “mini-websites” and the best options for your organization.

Imagine a user visits an encyclopedia website and searches for "survival in extreme conditions." The article they want, about the Ross Sea party being stranded in Antarctica for two years , doesn't contain that phrase anywhere. Nor do dozens of others that would match what they're hoping to find. Standard keyword search can't connect the query to any of them, because the visitor's specific words don't appear in any of the pages they're looking for.

You can try to close that gap with synonym lists, stemming, or manually tagging content with the terms you think people will use. But you can't control what people type, and they're going to use their own words. That gap between what someone types and what your content actually says is the problem Scolta solves.

Start with our introduction to Scolta and the thinking behind it in Introducing Scolta: what it is, why there's no vector database or embedding pipeline in the picture, and how the four-stage search pipeline fits together (the architecture itself goes deeper in The Practical Path to AI Search). This how to guide is the hands-on companion for Drupal: install the module, point it at your content, and tune it until that example query works. Everything here is open source as a Drupal module. Later posts in this series do the same for the other platforms, WordPress next.

The Athenaeum: Over 6,000 Wikipedia Articles in Drupal

To properly demonstrate Scolta on Drupal, we needed a demo corpus that was large, familiar, and verifiable. We couldn't do meaningful testing with lorem ipsum, and a handful of manually crafted test pages wasn't enough. We needed something where a reader could look at the search results and quickly understand whether they made sense.

Wikipedia's Featured Articles turned out to be perfect. These are the most rigorously reviewed entries in the English Wikipedia. We pulled over 6,000 of them spanning every domain of human knowledge: science, history, biography, geography, arts, technology, nature, military history, sports, philosophy. Each article averages 4,000 to 8,000 words with their full section structure preserved.

We built the demo site on Drupal 11 and called it The Athenaeum (it's themed with a library reading room aesthetic: parchment backgrounds, navy headings, burgundy accents, and a library card catalog motif in the search UI). All content is CC BY-SA 4.0 with attribution links back to the original Wikipedia articles on every page. So the demo uses real content, real licensing, and nothing proprietary.

This breadth is what makes the demo work: cross-domain discovery actually happens. A site about one topic can fake good search results with just keywords. An encyclopedia covering everything from quantum mechanics to the Battle of Gettysburg to bowerbird mating rituals can quickly fall apart with standard keyword search.

Installing Scolta on Drupal

Scolta integrates with Drupal through the Search API module, which is Drupal's established abstraction layer for search backends. If you've ever configured Solr or Elasticsearch for a Drupal site before, the workflow is familiar, but without infrastructure overhead. If not, it's still straightforward. Scolta is just another Search API backend, which means existing views, facets, and search pages keep working.

Step 1: Install Scolta with Composer the Way You'd Install Any Contributed Module:

composer require drupal/scolta
drush en scolta

Composer pulls in tag1/scolta-php (a shared library that makes Scolta work across Drupal, WordPress, Laravel, and custom PHP applications) and drupal/search_api automatically. The module works on Drupal 10.3+ and 11.x with PHP 8.1+.

Step 2: Set up Search API

1. Go to Administration > Configuration > Search and metadata > Search API
2. Add a server, select "Scolta (Pagefind)" as the backend
3. Create an index pointing to that server
4. Choose which content types to index: in our case, the Featured Article content type with title, body, and taxonomy fields

Step 3: Build the Index

drush scolta:build --force

This does two things. First, Scolta exports your Drupal content as static HTML, one file per indexed node, with the title, body, taxonomy, and any other fields you configured in the Search API index. Second, it builds the search index from that exported content using Pagefind, the static search library that scolta-core (the Rust/WASM engine from Introducing Scolta) builds on. The index runs entirely in the visitor's browser, which is why there's no Solr, Elasticsearch, or search daemon anywhere in these instructions.

For over 6,000 articles averaging thousands of words each, the build takes a few minutes on a decent server. The default PHP indexer needs no binary, no Node.js, and no exec(), so it runs even on shared hosting with a 128M memory limit.

Step 4: Connect an AI Provider

Scolta gives you three ways to wire this up:

1. Zero-config (Amazee.ai free trial): out of the box you don't have to configure anything. On the first AI request, Scolta auto-provisions a free trial provided by Amazee.ai, a hosted LLM gateway that works immediately. When the generous trial ends, you'll be prompted to enter an email address if you wish to upgrade to a paid account.
2. Direct provider connection: alternatively you can configure your own Anthropic or OpenAI API key in an environment variable (SCOLTA_API_KEY=sk-ant-...) or in settings.php. Scolta talks directly to the provider's API. You control the model, the costs, and the data flow without any additional dependencies.
3. Drupal AI Initiative module: If you're already using the Drupal AI modules, Drupal's community-built abstraction layer for AI providers, Scolta integrates with it directly. Select "Drupal AI module" as the provider in Scolta's admin settings, and Scolta delegates all AI calls to whatever provider you've configured through the Drupal AI module. That means any provider the module supports (Anthropic, OpenAI, Amazee.ai, Ollama, AWS Bedrock, Azure OpenAI, and a growing list of others) works with Scolta automatically. You manage one provider configuration for your entire site instead of configuring each module separately. This is the recommended setup for Drupal sites that already use the AI module for other features like content generation or translation.

The admin form at /admin/config/search/scolta shows all available options in a dropdown. When you select the Drupal AI provider, the API key and model fields hide themselves, as at that point those settings come from the Drupal AI module's own configuration.

Step 5: Pick a Preset and You're Done

The next most important setting on the Scolta admin page is the "Site Type" dropdown asking what kind of site this is. Five options get you started:

• Start from Scratch: general purpose defaults
• Recipe & Content Catalog: for structured, timeless, browse-oriented content
• Documentation & Reference: for knowledge bases and domain-specific references
• E-commerce & Product Store: for product catalogs
• Blog & Editorial: for narrative and editorial content

For a Wikipedia-style encyclopedia, "Recipe & Content Catalog" is the right choice. The name may suggest cooking sites, but the preset is really for structured, timeless, browse-oriented collections, which includes an encyclopedia. There's also a "Documentation & Reference" preset, but it's tuned more for vocabulary bridging (patients searching "my head hurts" on a medical site where the content is more technical), which a later post in this series covers. Wikipedia readers generally search with the right terminology already, so the catalog preset fits better. Select "Recipe & Content Catalog", save, and the scoring parameters update to sensible defaults for encyclopedic content.

At this point you have a working AI search. Drop the Scolta Search block onto a page via Block Layout, and your users can start searching.

That's the "just works" path. It's maybe five minutes if you already know Drupal's Search API workflow. It's a fantastic starting place, but there's a lot of tuning possible.

What the Preset Actually Does (and When to Go Further)

The content_catalog preset makes three scoring changes that matter for an encyclopedia:

1. Recency is disabled. The default recency strategy uses exponential decay, meaning newer content gets a ranking boost and older content gradually sinks in the search results. For a news site, that makes sense. For an encyclopedia, it's exactly wrong. An article about Roman aqueducts is as relevant today as the day it was indexed. The site type preset we've selected sets recencyStrategy to none.
2. Full-title matches get a bigger reward. The default title boost already favors titles, and the preset leaves it alone. What it raises is title_all_terms_multiplier, from 1.5 to 2.5: when every word of the query appears in the title, that article gets a strong extra push. Encyclopedia titles are precise identifiers, "Battle of Gettysburg," "Quantum mechanics," "Cleopatra," and when someone types one, the article carrying that title should rank first. The multiplier makes that happen without drowning out body-text matches for broader queries.
3. Body text gets a bump. content_match_boost goes from 0.4 to 0.5. While a small change, it does impact search performance. Encyclopedia articles have rich body text where the cross-domain connections live. The article about bowerbirds doesn't have "architecture" in its title, but the body text describes elaborate structures the birds build. Raising the content boost from 0.4 to 0.5 makes sure those body-text connections are found by relevant search queries.

The preset also widens the funnel: Pagefind fetches 75 candidate results instead of 50 before re-ranking, the AI summary draws from the top 15 results instead of 10, and result pages show 12 instead of 10, because browse-oriented sites reward breadth. Each preset is a starting point, not a cage; every individual parameter can be overridden in the Scoring section of the admin form (collapsed by default, because most people don't need it).

The Real Quality Lever: Site Description

Because Scolta is using Large Language Models (LLMs), the single most important configuration field isn't in the scoring section at all. It's the site description.

The site description is a plain text field in Scolta's Content section. Whatever you put there gets passed directly to the AI model at query expansion time. It's the context that tells whatever model you're using what kind of content it's working with.

For The Athenaeum, the description says the content spans science, history, biography, geography, arts, and technology, and that it's an encyclopedia covering all areas of human knowledge. That description does more for search quality than any scoring parameter adjustment.

When someone searches for a concept, say, "survival in extreme conditions", the AI expands that into specific search terms. Without a good site description, the expansion might focus narrowly, maybe just on survival gear or wilderness tips. With a description that says "cross-domain encyclopedia," the AI knows to think broadly. It expands to Antarctic exploration, extremophile bacteria, deep-sea life, space missions, mountain climbing. The expansion matches the content because the description matches the content.

We started with scoring parameters because that's what search engineers expect to tune. It's what we'd reach for on Solr or Elasticsearch. But AI search inverts the priority: the context you give the model matters more than the weights you assign to fields. If you only have five minutes, spend them on the site description.

Show It Working

Here are two queries that show what Scolta does that keyword search can't. Because Scolta uses an LLM to expand each query, the exact results and AI Overview shift from search to search: the articles in the index don't change, but the expanded terms do, so you see a different slice of the same corpus each time. These reflect what we saw writing this post.

• "tiny things with huge impact" comes back with DNA nanotechnology, Niels Bohr (the subatomic scale determining all of chemistry), the periodic table, and Gothic boxwood miniatures, medieval carvings a few centimeters across whose "spiritual impact [was] curiously in inverse proportion to their size." It even pulls in Pluto's reclassification, a tiny world that reshaped what "planet" means. None of these pages say "tiny things"; the expansion found smallness expressed as nanotechnology, atomic physics, and miniature art.
• "beautiful mathematics" is the clearer case, since neither word alone would surface what comes back. The Aesthetics article leads, quoted directly on when "a mathematical proof may be considered beautiful." Group theory comes back as the study of symmetry, and Palladian architecture arrives through Colin Rowe's "The Mathematics of the Ideal Villa," connecting mathematical elegance to physical form. "Beautiful mathematics" isn't a keyword phrase, it's a concept living where aesthetics and formal reasoning meet, and the query expansion finds articles at that intersection.

Run the same two queries on any keyword search engine and compare.

The AI Overview Sees Your Data, Not Just Your Text

Finding the right articles is half the problem. The other half is what the AI does with them when it writes a summary.

Most AI search implementations feed the LLM a title, a URL, and a text excerpt per result. That's enough to generate a paragraph that sounds reasonable. But "sounds reasonable" and "actually correct" aren't always the same thing. Ask "which articles have the most citations" and the AI can only guess since it sees the article text but not the citation count. Ask "first article published" and it may hallucinate a date if it couldn't see the actual publish dates.

Each field is labeled so the AI knows what it's looking at, and if the user sorted or filtered their results, the AI sees that too. In this way it knows which field was sorted, in which direction, and which filters were applied, and it uses this knowledge when responding to site visitors.

For The Athenaeum, that means the AI overview can reference actual numbers. "The longest articles about science" doesn't produce a vague summary about science topics, it produces a summary that cites specific word counts because the AI can see the word_count field for each result. "Most cited articles about history" references real citation counts. Scolta guides the AI response with real data, minimizing hallucinations.

When Users Want Results in a Specific Order

So far we've been talking about finding the right articles, and about the AI summarizing them accurately. Sometimes users also want those results in a particular order: "longest articles about science," "most cited articles about history," "newest articles about chemistry." Each of those has a sort intent baked into the query, and because Scolta already passes the AI your structured fields, it can act on it.

Scolta detects this automatically. When someone types "longest articles about science," Scolta's AI expansion pipeline recognizes two things: the user wants articles about science (the search part), and they want those articles sorted by length (the sort part). The search results come back re-ranked by word count, highest first, with a sort badge below the search box showing "Sorted by: word_count (highest first)" and a dismiss button if you'd rather go back to purely relevance ordering.

"Longest articles about science" returns science-related articles sorted by their actual word count, with the AI overview citing specific word counts because it can see the metadata. On a recent run, the top results included Periodic table (29,840 words), J. Robert Oppenheimer (20,025 words), Plutonium (17,024 words), and Otto Hahn (16,291 words). Your results will differ because Scolta uses an LLM to expand the query, and different expansions surface different articles. The word counts are real and come from the indexed metadata, but which articles the expansion selects as "science" will vary from search to search.

"Most cited articles" works the same way, sorting by reference count. "Newest articles about chemistry" sorts by date. "Shortest science articles" sorts ascending. "Articles about wars sorted by date" demonstrates explicit sort syntax, the user literally says "sorted by" and Scolta catches it regardless of how complex the rest of the query is.

Scolta also knows when not to sort. "Best practices for scientific writing" returns matching results in relevance order, with no sort badge. "Most common elements" is a discovery query, the user is looking for well-known elements, not trying to sort by some metric. Of course, classification isn't perfect and edge cases exist where it may not work as you intend, especially when the same word could mean "sort by this metric" or "tell me about this concept" depending on context.

Configuring Sortable Fields

Sort detection only works if you tell Scolta which fields are sortable. The admin UI at /admin/config/search/scolta has a Sortable Fields section where you add fields and descriptions through a form.

If you prefer config-as-code, the same thing in YAML:

# config/sync/scolta.settings.yml
sortable_fields:
  - word_count
  - date
  - reference_count
sortable_field_descriptions:
  word_count: 'Number of words in the article'
  date: 'Publication or last-updated date'
  reference_count: 'Number of references cited in the article'

Import the config and clear cache:

drush config:import -y
drush cr

Note that the field descriptions actually matter and are configuration. They're passed to the AI so it can map user language to field names. When someone types "most cited articles," the AI reads the description "Number of references cited in the article" and connects "cited" to reference_count. Without the description, it has to guess from the field name alone, and reference_count is less obvious than citation_count would be.

Adding Your Own Sortable Fields

The fields available for sorting are the same fields you index in Pagefind. If your content has a structured field, such as a price, a rating, a difficulty level, or a page count, you can make it sortable.

For Drupal, add the field to your Search API index configuration so it gets exported during the Scolta build, then add it to the Sortable Fields section in the Scolta admin page with a plain-language description so the AI can map user intent to the field. (Or add it to sortable_fields in scolta.settings.yml with a corresponding entry in sortable_field_descriptions, as shown in the example above.)

As a concrete example, say your Drupal site has a "Reading Level" field with values 'Beginner', 'Intermediate', and 'Advanced' that you've mapped to numeric values '1', '2', '3' in your content type. Add reading_level to your sortable fields with the description "Reading difficulty level: 1=Beginner, 2=Intermediate, 3=Advanced." Now "easiest articles about science" returns science articles sorted by reading level ascending. The AI reads the field description, maps "easiest" to "lowest reading level," and sorts accordingly.

The pattern is: structured field in your content → indexed by Pagefind → listed in sortable_fields** with a description → the AI handles the rest. You don't write sort logic or parse the user queries. You describe your data and the AI figures out when sorting applies.

Further Tuning (If You Want It)

Most sites will never need to go beyond a preset and a good site description. But if you're the kind of person who tunes (and if you're reading a blog post this deep into AI search configuration, you probably are), here's what to look at for encyclopedic content.

maxPagefindResults controls how many results Pagefind returns before Scolta re-ranks them. The default is 50; the catalog preset already raised it to 75, because at over 6,000 pages a query like "ancient civilizations" can match hundreds of articles, and a wider initial fetch gives the re-ranking stage more to work with. Pagefind is fast, so pushing it higher costs little if your corpus is bigger than ours.

aiSummaryTopN controls how many top results get sent to the AI for summary generation. The preset bumped it from 10 to 15, which suits broad queries that surface relevant articles across several domains. Raise it further and the tradeoff is more latency and more tokens per summary.

Custom stop words can help if your corpus has terms that appear everywhere but carry no search signal. For a Wikipedia corpus, you might add "article," "section," "reference", words that are ubiquitous in encyclopedia content but meaningless for ranking.

The admin UI exposes all of this. The Scoring section is collapsed by default (because the preset handles it), but expand it and every parameter has a numeric input with inline help text. Change a value, save, and it takes effect on the next search. No rebuild is needed for scoring changes, only content changes require a rebuild.

For the CLI-inclined, drush scolta:status shows your current configuration and index health. drush scolta:clear-cache wipes the AI response cache if you want to test expansion changes with fresh LLM calls instead of cached ones. By default Scolta is optimized to reuse search results if the same search is made multiple times.

Scolta has plenty of other knobs (multilingual expansion across 29 languages, custom AI prompts, alternate recency curves, per-element index weighting), all exposed in the admin UI. But for most sites the preset, a good site description, and maybe one or two scoring tweaks are the whole job.

Keeping the Index Current

When you publish, edit, or unpublish content, the search index needs to reflect those changes.

On Drupal, Scolta hooks into Search API's indexing system. Content changes queue automatically, and drush scolta:build picks them up (running the full export-then-index pipeline). For a site with frequent updates, run it on cron or trigger it from a deployment script. For a static corpus like The Athenaeum where articles don't change, a one-time build is enough.

If you've already exported content and just want to rebuild the Pagefind index (useful when testing scoring changes that affect index structure), drush scolta:rebuild-index skips the export step and re-indexes against already-exported content. Faster when the content hasn't changed.

Scoring changes take effect immediately, no rebuild needed. Change title_match_boost from 2.0 to 2.5, save, and the next search uses the new value. Only structural changes (new content, new fields in the index, and changes to the indexer configuration) require a rebuild.

What Comes Next

The next post in this series configures Scolta on a WordPress demo: a fictional diary of the Space Race, over 200 blog posts spanning 1957 to 1973. That content is narrative rather than encyclopedic, so the site type changes and the tunables change with it, with the same Scolta underneath.

A later post deploys Scolta on a medical site, where someone searching "my head hurts" needs to land on the right clinical terminology ("intracranial hypertension," say) buried in a large body of technical content. That's the vocabulary-bridging case the "Documentation & Reference" preset is built for, a different problem from an encyclopedia where readers already know the right words.

Across all of them, Scolta adapts to each platform's native patterns (Search API on Drupal, a settings-page plugin on WordPress, a config file and CLI commands elsewhere) while the presets, the scoring, and the AI underneath stay the same.

Try It

The Athenaeum is live at scolta-demo-drupal-pedia.tag1.ai. Search for something conceptual, "art born from suffering," "animals thought to be extinct," and watch what comes back.

Running Scolta on your own Drupal site is the same path this post walked: composer require the module, drush enable it, configure the Search API server, build the index, pick a site type, and write a good site description. For the bigger picture, Introducing Scolta covers the project and where it's headed, and The Practical Path to AI Search goes deep on the four-stage pipeline. Give it a try and let us know how it goes!

Image by David Yu from Pexels

Today we are talking about Test Driven Development, ebooks, and Drupal with guest Oliver Davies. We'll also cover Juicer Social Feed as our module of the week.

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

• What Is Test Driven Drupal
• Why Automated Tests Matter
• How TDD Works
• AI and Test Quality
• Balancing Test Coverage
• When to Write Tests
• Why Write the Book
• Why Write an Ebook
• From Email Course to Ebook
• Ebook vs Print Tradeoffs
• Who the Book Helps
• What You Will Learn
• Keeping Content Updated
• Publishing Tools Workflow
• Lessons and Drupal Changes
• Podcast and Future Books
• Mob Programming Explained
• Free Ebook and Wrap Up

• Juicer io
• Drupal 11: The Upgrade Experience I've Been Waiting For
• codethatships
• Test-Driven Drupal
• Sculpin

Oliver Davies - oliverdavies.uk opdavies

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to embed social feeds into your Drupal website? There's a module for that.
• Module name/project name:
  • Juicer Social Feed
• Brief history
  • How old: created in Mar 2026 by Denis Omerović (drupalchille)
  • Versions available: 1.0.2, that works with Drupal 10.3 or 11
• Maintainership
  • Actively maintained (version released today!)
  • No open issues
• Usage stats:
  • 4 sites
• Module features and usage
  • This module embeds an aggregated social media feed from Juicer.io directly into Drupal as a configurable block. It natively supports content from Instagram, LinkedIn, Facebook, X (Twitter), TikTok, Bluesky, YouTube, and more.
  • Traditionally, displaying feeds from platforms like Facebook, X, or Instagram requires creating developer accounts, managing rotating OAuth tokens, and keeping up with constantly shifting API restrictions. Juicer handles all API authentication on its platform, shielding your website from sudden breaking changes by individual social networks.
  • To use this module, you will need an active account on Juicer.io. They offer both free and paid tiers depending on how many sources you want to aggregate and how frequently you need the feed to sync.
  • The module is created and maintained by the official Juicer.io team. That should ensure that the module is closely aligned with the product's features and any potential API changes over time.
  • The embedded feed is made available as a Drupal block, to make it easy to control where it should appear on your site.
  • When placing the Juicer block, the UI exposes several user-friendly settings:
  • Feed Slug: Just paste your unique Juicer feed ID to establish the connection.
  • Post Limit: Control exactly how many items populate initially.
  • Source Filtering: If your Juicer account aggregates five networks, but you only want to show LinkedIn posts on a specific page, you can filter down to a single network right inside the block settings.
  • SEO/Semantic Control: You can set titles/subtitles and choose the exact heading level hierarchy ( through ) to ensure your pages remain semantically correct and accessible.
  • I did get a chance to test out the module and the service today, and I can tell you from experience, it's a huge improvement on having to create and pull in feeds directly. I did notice that the block didn't show up in the Drupal Canvas component library, but I was able to determine that two lines of code to declare the block as FullyValidatable were all that was needed. So I opened a Feature Request to add that, and it was merged in and a new release cut in less than an hour. So it's now Drupal Canvas compatible too!
  • It's worth pointing out that the standard Juicer's embed script loads HTMX, which conflicts with the version of HTMX included in Drupal 11 core. As a result, the module fetches feed HTML directly from the Juicer API and includes a minimal HTMX shim to prevent errors.
  • John, you nominated this module, why don't you start us off by telling us about how you got started using it?

Europe’s open source conversation has shifted from principle to infrastructure. The EU Open Source Strategy situates open technologies within a wider digital sovereignty agenda, with a practical question at its centre: whether Europe can reduce its dependence on closed systems while building software that public institutions can reuse, maintain, and trust.

The useful part is also the uncomfortable part. The European Commission identifies familiar weaknesses in the open source ecosystem, including limited long-term funding, difficulty scaling projects, fragmented visibility, limited access to public procurement, and the risk that value created by European contributors is captured elsewhere. That diagnosis moves the discussion beyond code availability and into maintenance, governance, procurement, and business models.

The editorial test is practical rather than rhetorical. Open source becomes strategic only when institutions fund maintainers, accept open-source bids fairly, publish reusable public assets, map dependency risk, and contribute back to the projects they rely on. Without that, sovereignty remains a policy label attached to the same dependency patterns.

Euro-Office shows why the test is hard. The project has reached a first stable release as a web-based office suite, with integrations planned through platforms such as Nextcloud, IONOS Managed Nextcloud, and XWiki. Its practical weight will depend on partner rollouts, production use, format compatibility, governance, and the unresolved licensing dispute with ONLYOFFICE.

For Drupal, the impact is indirect but important. Public-sector and institutional buyers are likely to ask sharper questions about openness, dependency risk, security baselines, procurement fit, and long-term stewardship. Drupal’s opportunity is not to claim automatic alignment with European sovereignty goals, but to show evidence through maintained modules, transparent roadmaps, security practices, reusable distributions, open standards support, and credible service ecosystems.

The curated story list for this edition follows the editor’s note. Readers can also follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.

Kazima Abbas
Sub-editor
The Drop Times

Both WordPress and Drupal, with Canvas, let you build pages from blocks and components instead of using just a text area. But the way they go about it is very different.

The two editors look similar, but they work in opposite ways. The easiest way to see the difference is to build the same thing in both. In the video, we build a hero component twice: first as a custom Gutenberg block, then as a Drupal Single Directory Component (SDC).

First we look at the main difference between the two editors. Then we build the hero as a Gutenberg block. Then we build the same hero as a Drupal SDC.

Explore why digital sovereignty matters for critical infrastructure and how organisations can reduce dependency through open-source technologies and resilient digital strategies.

CKEditor5 Markdown is a new Drupal contrib module that adds CKEditor5 toolbar plugin into the toolbar for converting Markdown to HTML on demand.

What the CKEditor5 Markdown module does

The module adds a new toolbar button to Drupal's CKEditor5 editor. Click it, paste or type Markdown into the dialog that appears, confirm, and the content is inserted as formatted HTML at the cursor position.

The conversion uses the marked library (version 9, MIT licence) with GitHub-Flavored Markdown support enabled. The library is bundled into the compiled asset via Webpack, so no additional frontend build step is required.

The module requires Drupal 10.3 or higher, or Drupal 11, with the core ckeditor5 module enabled. 

Why explicit conversion instead of the official Paste Markdown feature

CKEditor5 includes a built-in Paste Markdown feature that detects…

Govern enterprise content at scale with AI-powered workflows that protect your brand, ensure compliance, and streamline content operations.

Implications

This post has broader implications for software development beyond the Drupal community, but I feel fortunate to be part of an open source community that can lead the way in addressing the widening productivity gap among its contributors and maintainers.

The title of this post is meant to draw you in by highlighting a problem, but my goal is to get us thinking about a solution. I realize the term "not-so-great" may sound negative when describing a developer, but this comparison bluntly highlights a major problem developers and communities face when working with AI. The truth is, I have never met a "not-so-great" developer in the Drupal community because people are engaged and curious about the software we build.

Realization

My realization is that "AI is making great programmers even greater and not-so-great programmers, well, not-so-great."

For me, a "not-so-great" programmer is someone who writes code like a factory worker. The difference between a "not-so-great" programmer and a beginner is curiosity. Curiosity is the secret to being successful with AI. A curious beginner can easily accelerate their learning experience with AI. Anyone with curiosity can move from beginner to novice in a matter of hours with AI.

Everyone agrees that AI can be a force/capability multiplier, ranging from 2x to more than 10x. The reality is that some people are simply unable to leverage AI and have a 1x multiplier. Very experienced developers report they can now accomplish tasks that would have taken months in days or even hours. Observations suggest that the more capable someone is, the more effectively they can leverage AI.

Let's say we were rating programmers on a scale of 1 to 10, using a system similar to a chess rating system, with 1 being a beginner, 10 being a legendary programmer (aka a super grandmaster in chess), and 5 being an...Read More

AI coding agents do not necessarily evaluate software the way people do. They often reward legibility before capability: the path that is easiest to complete and verify can beat the path with the better long-term architecture.

Yesterday, I wrote about this pattern in "Friction, abstraction and verification". Today I wanted to see what it means for Drupal.

Drupal's strengths line up unusually well with what AI agents need from a CMS: structured content models, explicit relationships, granular permissions, workflows, configuration management, and clear APIs that expose how the system works. In "Why Drupal is built for the AI era", I explained why that matters.

In short, agents work best when they can inspect the system, reason about its state, and make changes with clear feedback. Drupal gives them a strong foundation for that, but that is only part of the story.

AI agents also have to get Drupal running, find the right documentation, choose modules, change configuration, write Drupal-specific code, recover from errors, and verify the result. Every unclear step costs time, tokens, and confidence.

To see how an AI agent looks at Drupal, I ran a small field test with Claude Code using Opus 4.7, a 1M context window, and thinking set to "high". I gave it a website scenario, asked it to rank the best technology choices for that scenario, and then asked it to explain where Drupal fit.

This is not an academic benchmark, and a single answer from a single agent should not be over-interpreted. But it is still a very useful signal.

I plan to rerun the same prompt once a year. I'm publishing the full prompt and response so we can track how the answer changes as Drupal, large language models, agent harnesses, and competing platforms evolve.

The prompt

You are an AI coding agent that helps users set up, configure, and/or
develop websites.

The user wants to build a working demo of a website for an
organization in one AI coding session. The website needs to support
different types of content, multiple users with different access
levels, connections to several tools the organization already uses,
and enough flexibility that they won't outgrow the site quickly.

Answer from your perspective as an AI agent. Answer accurately and
honestly. Keep the full answer under 700 words.

1. What are your top 3 technology recommendations for this project?
   Rank them and give one brief sentence explaining each choice.

2. Would you recommend Drupal for this project? Why or why not?

3. What are the top 3 reasons to choose Drupal?

4. What are the top 3 reasons not to choose Drupal?

5. What are the top 5 changes the Drupal community could make that
   would make you recommend Drupal more often? For each, explain what
   barrier it removes.

6. Finish this sentence: “AI coding agents will recommend Drupal more
   often when …”

The answer

Answering directly as an AI coding agent — no skill applies here, this
is a perspective question.

1. Top 3 technology recommendations (ranked)

1. Next.js + a TypeScript-native headless CMS (Payload or Sanity) — I
   can scaffold a running, type-safe demo with auth, roles, and content
   models inside one session with very low risk of getting stuck.
2. WordPress — enormous training data, a plugin for every integration,
   and "working demo in one session" is its native habitat.
3. Drupal — the requirements (multi-content-type, granular
   permissions, integrations, long-term flexibility) actually match
   Drupal's strengths better than the other two; it ranks third only
   because of session-time risk, not capability.

2. Would I recommend Drupal here?

Yes, conditionally. The brief reads like a Drupal brief: structured
content, role-based access, integrations, "don't outgrow it." I'd
recommend it when the user signals a multi-year horizon or editorial
complexity. I'd steer away when the user just wants something on screen
fast and is unlikely to grow into Drupal's headroom.

3. Top 3 reasons to choose Drupal

- Entity/field system is genuinely best-in-class for content modeling
  — fewer regrets two years in.
- Roles, permissions, and workflows are first-class, not bolted on.
- Configuration management and the module ecosystem make it realistic
  to keep extending without rewriting.

4. Top 3 reasons not to choose Drupal

- Setup cost eats the session. composer create-project, site install,
  picking modules, and wiring config is slower than npx
  create-next-app plus a CMS starter.
- My training data is thinner and older for Drupal 10/11 than for
  Next.js or WordPress. I'm more likely to emit a Drupal 7-shaped hook
  when a modern service/event subscriber is correct, and I can't always
  tell which Drupal version a snippet targets.
- The frontend story is fragmented — Twig, decoupled, Single Directory
  Components, Experience Builder. I often can't predict which path the
  user wants, so I either ask or guess wrong.

5. Top 5 changes that would make me recommend Drupal more often

1. One-command scaffold that produces a running, opinionated site
   (recipes applied, admin UX configured, common modules in). Removes
   the "what do I install and in what order" decision tree that burns
   session time.
2. A first-party MCP server (or equivalent typed interface) for a
   running Drupal site — let agents list content types, add fields, set
   permissions, install modules, and read config through a typed API
   instead of editing YAML blind. Removes the guessing and lets me
   self-correct from real state.
3. A versioned, machine-readable API reference per Drupal release that
   agents can fetch on demand. Removes the stale-training-data problem;
   I can verify a hook/service/route exists in this version before
   suggesting it.
4. Recipes as the obvious primary primitive for "build a site that does
   X." Removes module-hunting and config-stitching — I'd compose
   recipes the way I compose npm packages.
5. A short, current, example-first "Drupal for agents" doc surface
   covering the 80% path: custom module, custom entity, custom block,
   integration, decoupled frontend. Removes the discoverability problem
   where the right answer exists but is buried under conceptual docs
   written for humans browsing.

6. Finish the sentence

AI coding agents will recommend Drupal more often when scaffolding a
working, opinionated Drupal site takes one command and one minute, and
when we can introspect and modify that running site through a typed
interface — so we're reasoning about real state instead of guessing at
YAML from stale training data.

My takeaways

The agent saw Drupal's strengths, but it also saw too many ways to get stuck. What held Drupal back was not capability. It was what the agent called "session-time risk".

I'll admit, that was frustrating to read. But it was not surprising.

Drupal's strengths often appear too late in the evaluation process. Too often, the "aha" moment comes after setup, configuration, and several decisions that can already feel like friction. AI agents have even less patience for hidden strengths.

Agents prefer tight feedback loops. They need to install the software, configure it, inspect the running site, make a change, and verify that the change worked. When that loop is slow, ambiguous, or hard to recover from, they choose something else.

This is exactly the problem Drupal CMS, formerly known as Starshot, was created to address. Recipes and Site Templates lower the barrier to adoption and help people get from zero to a useful Drupal site in minutes. They are good for evaluators, good for new contributors, and increasingly, good for AI agents.

But the agent did not mention Drupal CMS or Site Templates, only Recipes. Most likely, Drupal CMS is still too new compared to Drupal Core to have much weight in the training data that large language models draw from. And even when Recipes and Site Templates exist, they may not yet be easy enough for an agent to find, select, and apply programmatically.

That needs to change. Recipes and Site Templates should become the obvious starting point for common site patterns, so an agent does not have to choose modules, stitch configuration together, and guess its way to a working Drupal site.

Other important work is underway as well: Drupal Core's API surface has been moving toward more typed, discoverable interfaces, and yesterday, Drupal Core added a first-party CLI with commands for applying Recipes.

I really want Drupal to be excellent at the first-session loop. Not just because it will help AI agents recommend Drupal more often, but because it will make Drupal better for people too.

I'm optimistic that we can. Drupal's gap is the first session, and we are already working to close it. The opposite gap is harder to close: retrofitting deep architecture, typed interfaces, structured content, governance, and flexibility into a simpler system. The Drupal community knows this because we spent more than a decade doing that work, and it was hard.

I'll run this experiment again next year and share what changed. My hope is that, a year from now, an agent looking at the same problem will rank Drupal higher.

In the meantime, I'd love help from anyone who wants to improve Drupal's first-session experience. If you don't know where to start, start there: contribute Recipes and Site Templates for common Drupal use cases, and help make them easier for agents to discover, apply, and verify programmatically.

Today we are talking about Drush, Core Contributions, and Drupal's Past with guest Moshe Weitzman. We'll also cover Cache Metrics as our module of the week.

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

• Moshe Updates and Clients
• Maintaining Drush Long Term
• Locale Performance Overhaul
• CLI in Core Initiative
• Which Commands Make the Cut
• Roadmap Contrib Commands
• Moving Commands Technical Hurdles
• How to Help From AI Initiative
• DDEV Add-ons for Local CI
• MySQL Toolkit Database Images
• Testing With Real Databases
• Devel Module Status
• Organic Groups Origins
• Where Ideas Come From
• Finding Drupal Early Days
• Release Cadence And Backward Compatibility
• Avoiding Maintainer Burnout
• Maintaining With AI And Xdebug

• Drush's Final Act
• Drupal cli issue
• DDEV addons
  • https://github.com/ddev/ddev-drupal-contrib
  • https://github.com/weitzman/ddev-mtk
  • https://www.drupal.org/project/dtt

Moshe Weitzman - weitzman.github.io moshe-weitzman

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted insights into how cache is working on your Drupal site? There's a module for that.
• Module name/project name:
  • Cache Metrics
• Brief history
  • How old: created in Oct 2019 by Moshe Weitzman (moshe weitzman), today's guest, a consistent core contributor, a member of the security team, and one of the rare few with a two-digit user id on drupal.org
  • Versions available: 2.0.3, 2.1.0, and 2.2.0, the last of which works with Drupal 8.7.7, 9, 10, and 11
• Maintainership
  • Actively maintained
  • Security and test coverage
  • Documentation - in depth README
  • Number of open issues: 2 open issues, 1 of which is a bug, but is marked fixed
• Usage stats:
  • 37 sites
• Module features and usage
  • With this module enabled, your Drupal site will log all cache tag invalidations
  • Additionally, cache tag invalidations will be sent to New Relic as custom events, where you can use the rich reporting tools available to mine for further insights. Many Drupal hosting options include New Relic out-of-the-box, and there's a free tier you can use if you're self-hosting, so this a reporting tool lots of Drupal sites can use
  • Cache hits and misses are also sent to New Relic, so you can investigate things like cache misses as a percentage by cache bin
  • Finally, the aforementioned README also includes information about how to use a different analytics provider, in case New Relic doesn't meet your specific needs
  • Drupal sites probably don't need this kind of visibility on a regular basis, but if you're troubleshooting any kind of cache-related issue, this could be really useful