Drupal now ships with HTMX, and there is currently a proposal to add a few of the building blocks into the HTML specification. The effort is nicknamed the triptych and the goal is to add three new HTML features:
theodore June 17, 2026Join us THURSDAY, June 18 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
Information on joining the meeting can be found in our collaborative Google document.
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.
This post is a companion to AI and the great digital agency unbundling. That post looked at AI's impact on the digital agency market. This one looks at the same unbundling pattern in content management systems and digital experience platforms. AI lowers the cost of creation, not the cost of trustWe 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:
Put those questions on a grid, and four use cases emerge.
The more people, agents, systems, and channels involved, the more a CMS matters as the control layer.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 systemThis 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 systemThis 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 systemsHere 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 systemsThis 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 rebundlingOne 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 DrupalTo 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 DrupalScolta 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 scoltaComposer 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 APIThis 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 ProviderScolta gives you three ways to wire this up:
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 DoneThe 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:
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:
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 DescriptionBecause 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.
A great site description with default scoring parameters will outperform a generic description with perfectly tuned scoring. It's held true on every site we've built with Scolta. Tune the description first. Tune the numbers second.
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 WorkingHere 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.
Run the same two queries on any keyword search engine and compare.
The AI Overview Sees Your Data, Not Just Your TextFinding 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.
Scolta solves this by passing all indexed metadata to the AI alongside each result. Not just the text, but also every structured field in the index: word count, reference count, date, taxonomy, and whatever you've configured as sortable or filterable.
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 OrderSo 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 FieldsSort 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 crNote 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 FieldsThe 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 CurrentWhen 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 NextThe 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 ItThe 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!
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
TopicsOliver Davies - oliverdavies.uk opdavies
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
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.
Two questions for you.
The first question is about capability. Every organization has a ton of information stored in different systems, and an understanding of that data's structure and how to use it in the heads of its people. How do you unlock it so AI can access it, and do so in a way you can trust?
The second is about sustainability. Most organizations can get an AI project working. The problem is what happens next. It hits trust and safety concerns that prevent it from going live. A new model is released and prompts don’t perform like they used to. The next project retreads the same trust and safety concerns that take longer to get through than the project took to implement.
The enterprise intelligence layer is the architecture that answers both questions. It's not a single product you buy or a platform you install. It's a collection of products, practices, and approaches to building with AI, which is the outcome your organization reaches when the right pieces are in place and working together.
This probably sounds familiar. Data warehouses, knowledge management systems, enterprise search, service-oriented architecture, and a long line of approaches before them all promised a version of the same thing: let people and organizations make effective use of what they know. None of them fully delivered on it, and if you've been through a few of these cycles you have every reason to be skeptical of another one.
Three things are distinctly different this time.
1. The consumer of your data is no longer humanPrevious iterations of "unlock your data" made it available to analysts running reports, to developers building integrations, or to deterministic systems calling APIs. The consumer was always a person or a program that knew exactly what it was looking for.
Now the consumer is a large language model. That changes what "accessible" means. It's not just SQL access or REST endpoints, it's semantic understanding. The AI needs to understand what data exists, what it means, and how to use it in context. Discoverability isn't a nice-to-have catalog feature. It's the difference between an AI that can figure out how to answer questions about your organization and one that needs much more human guidance. Without this, an agent needs a person to provide the “tribal organizational knowledge” that isn’t written down or in a system.
2. Governance concerns have increasedGovernance used to be primarily concerned with access control: who can see what. That problem still exists. But AI adds a governance surface that didn't exist before. You now need to govern what the AI does with your data — monitor for hallucinations, enforce business-specific rules about what it can and can't say, trace outputs back to their sources, and intervene when something goes wrong.
Your data warehouse never hallucinated. Your SOA services never gave inappropriate advice to a patient. AI-output governance — the policies, monitoring, and enforcement around what AI produces — is a novel problem, and it's the one that keeps many organizations from moving AI into production.
3. Development capacity isn't the limiterA new application or feature is not necessarily a significant build. Once the data access, governance, and operational infrastructure are in place, a new AI application can be remarkably lightweight — an agent configuration, a prompt workflow, a new interface on top of existing retrieval. With LLMs, the ability to run ad hoc analyses and build custom-fit tools for working with information has accelerated dramatically.
Reusable infrastructure that makes the next project cheap is exactly what previous approaches have promised. However, each project still required a developer to find the right service, or understand the data available, and wire it in by hand. What's different now is that the thing doing the composing is an LLM. An agent can discover the capabilities that already exist, understand how to use them, and assemble them - without a person wiring each connection. That's what makes the payoff for shared infrastructure faster and more dramatic than it has ever been. Coupled with the amount of time and effort spent on governance concerns, the second project argument is more compelling.
Taken far enough, and for organizations willing to take the leap, it opens a door prior waves never could: AI that recommends and implements its own evolution — proposing new capabilities and building them against the foundation that's already there.
With that context, here's how the intelligence layer organizes. Three areas, each addressing a different concern, each buildable incrementally.
This layer is where your data lives along with ways to discover its existence, and how to access it. It is composed of things like: data warehouses, source systems, APIs, document stores, discoverability features, semantic layers, vector stores, embedding pipelines, knowledge graphs, LLM models — that makes unstructured data usable by AI.
The critical capability here is discoverability. Can your AI systems find what they need across your organization's data without someone manually wiring each connection? When a new application needs access to provider information, is that a human task, or can the coding agent discover an API that provides it, understand how to use it, and implement a feature for review?
2. Operations and governance: the infrastructure that lets your organization say yesThis is the controls and visibility layer. It covers four concerns:
This is where the gap between ambition and execution usually lives. Organizations don't lack governance concern — governance is often the reason AI projects stall. I’ve seen instances where the work to address the governance concerns far outweighed the work to develop the functionality. Every stakeholder has legitimate questions about data access, compliance, auditability, and safety. The problem is that without concrete infrastructure to address those questions, they can't be resolved.
The intelligence layer gives governance something tangible to work with. Instead of abstract policy debates, you can point to specific audit trails, defined access controls, real-time monitoring of AI outputs, evaluation runs testing specific concerns, and configurable rules that compliance teams can review and adjust. Governance becomes the mechanism for saying "yes" to AI with confidence — not the reason projects sit in limbo.
This is the value layer: interactive AI tools, agentic systems, automated workflows, development assistants, AI-augmented dashboards. Applications are where AI produces business value, and they're what every organization wants to build.
But applications built without the layers below them are fragile, opaque, and hard to trust in production. They work in demos and break at scale. The intelligence layer exists so that applications can be built quickly, run safely, and earn the trust of the people who depend on them. And because AI applications are lightweight relative to their infrastructure, each new one built on a shared foundation is dramatically faster than the last.
The second project is the real test
The real test of an organization's AI architecture isn't whether the first application works. It's what happens when you build the second one and beyond.
Without an intelligence layer, each project spends a disproportionate amount of time and effort retreading the trust and safety areas, potentially coming up with differing approaches and fragmenting your organization's ability to govern effectively and efficiently. With the intelligence layer in place you're building on a foundation, not starting from bare ground. The data connections exist. The governance policies are enforced. Observability is already running and feedback loops are in place to support evolving model and agent evaluations.
This is the architecture designed to prevent the patterns that stall AI at scale. It provides the elements needed so you can trust AI is producing accurate and appropriate responses. Model and agent evaluations let you trust what output will be produced for given inputs. Guardrail and policy application let you trust that the system will catch and prevent any undesired output should it occur. Observability allows you to trust that you'll be able to see how AI is being used and the responses it is producing. Each of the elements is present to address governance concerns that cycle without resolution because there's no infrastructure to resolve them, AI operations that are invisible and therefore unauditable, and foundations that get rebuilt by every team because nothing was shared.
You don't need all three layers in place before you build anything. In fact, most organizations shouldn't try to stand up the full intelligence layer before they have a real application to build on it. The most practical path looks like this:
The intelligence layer isn't a prerequisite you have to complete before the real work begins. It's what emerges when you make deliberate architectural choices on every AI project instead of expedient ones. And critically, it's what turns governance from a blocker into an enabler — giving your compliance, security, and clinical leadership the visibility and controls they need to let AI move forward.
If you've been thinking about this as you read, you probably already have a sense of where your organization is strong and where the gaps are. Maybe your data infrastructure is solid but observability is nonexistent. Maybe you have governance policies written but no infrastructure to enforce them. Maybe every team is building AI independently and you're starting to see the cost of that duplication.
That assessment — where are we strong, where is the gap, and what do we address first — is exactly the conversation worth having. If it would be useful to think through it with someone who has done this across multiple enterprise organizations, we'd welcome that conversation.
Publication Date Thu, 06/11/2026 - 11:32 Chris Johnson VP, EngineeringCJ is a seasoned hands-on web developer and enterprise architect whose specialties include high-performance database-backed content management systems, large-scale Drupal systems, complex multi-system integrations, and continuous integration and delivery pipelines. He ensures our Engineering team excels at solving problems and applying the right technology, or none at all, to the job at hand.
Featured Blog Post? Yes Has this blog post been deprecated? No Summary Most organizations can get an AI project working. The problem is what happens next. The enterprise intelligence layer is the architecture that makes AI trustworthy, repeatable, and scalable across your organization by addressing data discoverability, governance, and observability as shared infrastructure rather than one-off solutions. Topic Artificial Intelligence Blog Post Graphic Intelligence Layer Banner.png Promo ImageExplore why digital sovereignty matters for critical infrastructure and how organisations can reduce dependency through open-source technologies and resilient digital strategies.
Building workflows blind - configure, deploy, hope, check logs - was the reality for years. ECA's integrated test, replay, and debug features close the feedback loop. Put the modeler in listening mode, trigger events, see execution results immediately with token values at each step. A small widget appears on any page where ECA processed events - click it, modeler opens in overlay with recorded execution data, replay what just happened right there in context. Recording is expensive (despite 70% CPU and 85% storage optimizations), so use temporarily when debugging. Production event replay lets you step through failures with actual data from when they occurred. Conditional recording triggers and JSON export across environments are coming. No other workflow tool in any CMS - not WordPress, Joomla, n8n, or Zapier - offers step-through replay with production recordings at this level. This is what existing ECA users requested most: visibility into workflow execution. Infrastructure-level work that required sustained investment but compounds over years. Workflow Modeler exclusive feature, not available in BPMN.iO.
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 doesThe 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.
CKEditor5 markdown example
Why explicit conversion instead of the official Paste Markdown featureCKEditor5 includes a built-in Paste Markdown feature that detects…
When working on contributed Drupal modules, you sometimes need to make changes to schema or data structures.
This will generally need an update hook to make necessary changes to existing stored data on sites that installed the module before the change.
The update hook itself is generally simple enough. Here’s an example from the Smart Trim module, to update “read more” link settings on each display type:
/** * Update Smart Trim more settings. * * Iterate through entity view displays and for any with Smart Trim as formatter * type, move top level more link settings into...