AI Workflows in Drupal 11: What Really Relieves Editorial Teams
Back in 2023, the old arocom blog featured an experiment: a Drupal module that generated meta descriptions via the OpenAI API. At the time, a toy at the edge of the system. Three years later, it has grown into a reliable pattern that we use productively in client projects. The constant throughout: the AI writes suggestions, the human publishes.
Which tasks can be delegated
The most rewarding candidates are tasks that can be derived from existing content. The editorial team has already done the real work, the article. Everything else is transformation:
- Meta title and meta description from the article text, with a length limit and a keyword hint
- Alt texts for images in their media context (what does the image show, what is it for on this page)
- Teaser variants for overview pages, newsletters, social media
- Raw translation drafts DE→EN that a human edits, as the successor to the old DeepL/TMGMT workflow
- Structure suggestions: subheadings, FAQ extraction, related internal links
Three things are not delegable, and we mean that as a finding, not as a precautionary phrase: tone of voice ("does this sound like us?"), fact-checking and the decision what gets published at all.
Architecture: draft fields instead of autopilot
Technically, we use the Drupal AI module ecosystem with a provider abstraction layer. The language model stays interchangeable, which at the current pace of model releases is no theoretical advantage. The decisive design pattern is simple: AI results never land directly in the published field. They land in a suggestion field that the editorial team sees in the familiar form, then adopts, changes or discards.
// Event subscriber: on presave, draft a meta description
// suggestion for nodes that lack one. Never overwrites.
public function onPresave(EntityPresaveEvent $event): void {
$node = $event->getEntity();
if (!$node->hasField('field_meta_suggestion')) {
return;
}
if (!$node->get('field_meta_suggestion')->isEmpty()) {
return; // editor already has a pending suggestion
}
$suggestion = $this->aiProvider->chat([
'system' => 'Write a meta description, max. 155 characters, '
. 'phrased in active voice, no superlatives.',
'user' => $node->get('body')->summary
?: mb_substr(strip_tags($node->get('body')->value), 0, 2000),
]);
$node->set('field_meta_suggestion', $suggestion);
}The same mechanism carries alt texts (a vision model describes the image, the editor sharpens the page context) and translations (the raw draft goes into the translation queue instead of directly into the EN node). The approval process, in our case Draft → Review → Published, stays untouched. That is exactly why editorial teams accept the system: it takes typing off their hands, not control.
One workflow from start to finish: the meta description
The meta description workflow, step by step, shows what this feels like in everyday editorial work. An editor writes a technical article and saves the node as a draft. On save, the event subscriber from the code example above checks whether the suggestion field is empty. If it is, the article text goes to the model with a fixed instruction: maximum 155 characters, active voice, no superlatives. A few seconds later, the suggestion appears in the edit form, clearly marked as a suggestion, right next to the actual meta field.
The editor now has three options: adopt it, adopt it and sharpen it, or discard it and write her own. In our projects, we see the middle one most often. The suggestion captures the content, the editor replaces a generic verb or moves the most important keyword to the front. Only with her approval does the text move into the real meta field and, with the status "Published", out into the world.
For the editorial team, almost nothing changes in the familiar form; it is one more field. No new tool, no second browser tab, no half-day training session. This unobtrusiveness is no accident but the most important acceptance criterion we took away from the first projects.
Alt texts with a vision model: what the AI sees and what it lacks
In the alt text workflow, a vision model describes the image when it is uploaded to the media library. It reliably sees what is in the picture: "Two people in front of a monitor in a meeting room." What it cannot know is the function of the image on the page. Does the photo document a workshop report, does it serve as a symbolic image, or does it show the team from the article? The editor adds this context in half a sentence, something like "editorial workshop at the client's office in March".
The division of labour is clean: the model delivers the correct, complete base description, the human delivers the meaning. Previously, alt texts often stayed empty because describing from scratch was tedious. Now the tedious part is done, and the human contribution takes ten seconds per image. The effect pays in twice: into accessibility and into image search.
Translations: from the DeepL workflow to the LLM raw draft
Multilingual Drupal sites have had a well-rehearsed translation path for years: TMGMT queue, machine raw draft (for a long time DeepL), human editing. Switching to a language model changes the quality of the raw draft more than the process. An LLM does not translate sentence by sentence; it knows the whole article and keeps terminology consistent across the text. We steer technical terms via a glossary in the prompt: which terms stay German, which product names are never translated, which register the brand speaks in the target market.
So what does the human reviewer still change? In our projects, mainly three things: idioms that sound wooden when translated literally, legally tinged phrases that go by different names in the target market, and headlines that are correct as translations but weak as headlines. The effort drops from "translating" to "editing". That is the difference between hours and minutes per page.
What comes out of it
Averaged across several projects, we see 20–30% time savings in ongoing content maintenance. At the upper end are multilingual sites, where the raw translation drafts make up the largest block. Just as important is the quality effect: fields that used to stay empty because they were tedious (alt texts!) are now consistently maintained. Accessibility and SEO benefit in equal measure.
To put the number in its proper place: it is an observation across several projects, not a laboratory value, and it refers to ongoing content maintenance, not to writing the articles themselves. The largest single item on multilingual sites is the raw translation drafts, roughly half of the effect. Metadata and teaser variants follow, and last come the alt texts, which are small in time but previously simply got left undone. Monolingual sites accordingly land at the lower end of the range.
If you want to check whether this pays off for your editorial team: measure for one week how much time goes into metadata, alt texts and translations. That number decides whether the workflow is worth it.
Prerequisites: what you need for this
For the pattern to run, four things are needed:
- A current Drupal base: Drupal 11 or a well-maintained Drupal 10.3+. The AI module ecosystem supports both.
- The AI module ecosystem: the central AI module with the provider plugin for your chosen model vendor, plus building blocks for translation and media depending on the workflow.
- Clean field structures: The workflows build on defined fields. A site whose content lives in a single body field needs structural work first.
- An API budget: for ongoing editorial workflows, realistically a low two-digit euro amount per month. The one-off translation of large back catalogues costs more depending on volume, but stays far below the cost of human first translation.
The biggest item is not the inference but the setup: prompts per content type, permissions, editorial training. Plan days for it, not weeks.
Which model do you use?
Deliberately none in particular. The Drupal AI ecosystem separates workflows and model vendors through a provider abstraction, and we configure for each task the model that best balances quality and cost. At the current pace of new model releases, this interchangeability is the real architectural advantage: a better or cheaper model is a configuration change, not a project.
What does operation cost?
The model costs are rarely the problem. For typical editorial workflows (metadata, alt texts, teasers), in our experience they sit in the low two-digit euro range per month; the raw translation of larger back catalogues costs more as a one-off. Add the upkeep of prompts and occasional model updates, realistically a few hours per quarter. The bigger item is the one-off setup, and that depends on the number of workflows.
Does this work in Drupal 10 too?
Yes. The AI module ecosystem supports Drupal 10.3 and Drupal 11 equally. If an upgrade is due anyway, it is worth planning both together, because the workflows build on well-maintained field structures. An AI workflow project is, however, no reason to migrate a stable Drupal 10 prematurely.
Go deeper in our knowledge base
Want to know what these topics mean for your company? The Future Check shows you the biggest levers within 2–4 weeks.
