Innehållssamlare

You have a supplier spreadsheet with a category column that reads Animals > Dogs > Food, and you want Drupal to end up with a real taxonomy tree: Animals, with a child Dogs, with a child Food, each level created only if it does not exist yet, and every product referencing the leaf of its own path.

Neither Drupal core nor Feeds does that on its own. Feeds Tamper Term Hierarchy does: it reads the path out of the column, creates the taxonomy terms that do not already exist, and respects the hierarchy between them. It has been on drupal.org since 2021 and reached its first stable release, 1.0.0, this week.

The interesting part is not the splitting. Any parser can split a string on a delimiter. The interesting part is deciding, for each segment, whether the term you are looking at already exists, and that turns out to be a question about identity that most import tooling gets wrong.

Name is not identity

Take a small catalogue:

sku,name,category 1001,Rope leash,Animals > Dogs > Accessories 1002,Dry food 3kg,Animals > Dogs > Food 1003,Dry food 1kg,Animals > Cats > Food

The tree you want out of it:

Animals ├── Dogs │ ├── Accessories │ └── Food └── Cats └── Food

There are two terms called Food in that tree. One is the dog food category, the other is the cat food category, and they have to stay separate. If they collapse into one, every dog product and every cat product point at the same category, your faceted search stops making sense, and the client finds out before you do.

Now ask what “does this term already exist?” means while the third row is being imported. Food exists, in the sense that a term with that name is already in the vocabulary. It is the wrong one. The right answer is that Food under Cats does not exist yet, even though Food under Dogs does.

That is the whole problem in one sentence: in a hierarchy, a term is identified by its name together with its parent, not by its name. A lookup that ignores the parent will happily hand you a term from a different branch.

This is why Feeds’ built-in term autocreation cannot be pressed into service here. It matches by name within the vocabulary, because for a flat vocabulary of tags that is exactly right. Give it a path and it does something reasonable and useless: it looks for a term named Animals > Dogs > Food, does not find one, and creates a single term with that literal name, greater-than signs included. One flat term per distinct path.

Resolving a path one parent at a time

The fix follows from the diagnosis. Rather than looking up each segment in the vocabulary, look it up among the children of the segment resolved just before it:

• Animals is looked up among the root terms.
• Dogs is looked up among the children of Animals.
• Food is looked up among the children of Dogs.

Walking Animals > Cats > Food takes a different turn at step two, finds no Food under Cats, and creates one. Two terms, same name, different parents, which is what the source data described all along.

So how does the plugin know which Food is the right one? It does not. The path tells it, one level at a time, and the only thing carried between levels is a single term ID. This is the loop, with the caching and the options stripped out:

$parent = 0; foreach ($names as $name) { $terms = $storage->loadByProperties([ 'name' => $name, 'vid' => $vocabulary, 'parent' => $parent, ]); $term = $terms ? reset($terms) : $this->createTerm($name, $vocabulary, $parent); // The term just resolved becomes the parent of the next lookup. $parent = (int) $term->id(); } return $parent;

$parent starts at 0, which is how Drupal spells “no parent, this is a root term”. Every lookup is constrained by it, and the last line of the body is what makes the walk work at all.

Trace Animals > Cats > Food through it and the three queries are (Animals, parent 0), (Cats, parent 1), (Food, parent 5). Trace Animals > Dogs > Food and the third one is (Food, parent 3), which is why it finds the dog food term instead of creating a second one. Neither of them ever asks “is there a term called Food?”, which is the question that would produce the wrong answer.

One honest caveat: Drupal does allow two sibling terms with the same name under the same parent. If your vocabulary already contains such a pair, reset() picks whichever the storage returns first. The plugin cannot disambiguate what the data itself does not distinguish.

Two further properties fall out of this for free.

The import becomes idempotent. Re-run the same feed and every segment resolves to the term created the first time, so nothing is duplicated. Add a row with a new leaf under an existing branch and only the leaf is created. That matters because supplier feeds are re-imported nightly, and an import that duplicates its own output is worse than no import.

And the created terms carry the hierarchy, not just the labels. You get a tree you can render as a menu, use in a facet, or attach access rules to, rather than a flat list of strings that happen to contain angle brackets.

Setting it up

With Feeds, Feeds Tamper and Feeds Tamper Term Hierarchy installed, on a feed type with a CSV parser:

1. In Mapping, add your taxonomy term reference field as a target and map the category column to it.
2. In that target’s settings, set Reference by: Term ID. See the warning below.
3. In the Tamper tab, add the Import Taxonomy Terms Hierarchy plugin to the same source.
4. Set the input delimiter to whatever separates your levels. It defaults to >, and spaces around each segment are trimmed, so A > B and A>B behave identically.
5. Pick the vocabulary the terms belong to.
6. Import.

The one step people miss

Step 2 is worth dwelling on for a moment, because getting it wrong produces a failure that does not look like one.

The plugin creates the terms itself and returns the ID of the last one in the path. If the mapping is left on its default of matching by term name, Feeds receives that number and does the only sensible thing with it: it looks for a term called 23, does not find one, and creates it. The import reports success. The log is clean. The vocabulary contains a perfectly correct hierarchy, built by the tamper, sitting next to a handful of terms called 23, 25 and 26, which are the ones your content actually references.

We reproduced exactly that on a clean Drupal 11 site while preparing this release. If your categories are numbers, this is why.

More than one path per column

Sources often pack several categories into one cell:

sku,name,categories 1001,Rope leash,"Animals > Dogs > Accessories, Animals > Cats > Toys"

That works, by combining two plugins in the right order. Tamper runs its plugins as a pipeline, and when one of them turns a single value into several, the ones after it run once per value:

1. Explode, using the separator between paths, here ,.
2. Import Taxonomy Terms Hierarchy, using the separator between levels, here >.

The Explode produces two paths, the hierarchy plugin runs twice, and the field receives two term IDs. Reverse the order and the hierarchy plugin is handed the whole cell, treats the comma as part of a term name, and you get a category called Accessories, Animals.

When you do not want new terms at all

Creating missing terms is the right default for a first import into an empty vocabulary. It is the wrong default when the taxonomy is curated and the feed is a third-party file you do not control, because then a typo at the supplier silently becomes a category.

1.0.0 adds an option for that. Uncheck Allow terms to be auto created and the plugin stops inventing terms: a path that does not fully exist is skipped instead. A supplier renaming Accessories to Accesories shows up as skipped rows rather than as a quietly duplicated branch.

This one came from a support request by someone who wanted precisely that behavior, and from an implementation contributed by someone else two years ago. It sat in the queue until this release, which is on us.

When the source only has part of the path

The opposite case also happens. The vocabulary already holds Animals > Dogs > Food and the source only carries Dogs > Food, because whoever exported it dropped the top level.

By default the first segment has to be a root term, so Dogs > Food creates a second, unrelated Dogs at the root. Correct by the rule above, unhelpful in practice.

Match the first term anywhere in the hierarchy relaxes that first lookup only: the first segment may match a term at any depth, and everything after it resolves underneath whatever it matched. Dogs > Food then attaches to the existing branch.

It is off by default and should stay off unless you need it, because it trades away exactly the identity rule this post is about. When several terms share a name at different depths the first match wins, and which one that is depends on term IDs rather than on anything meaningful.

Where it stands

Feeds Tamper Term Hierarchy 1.0.0 works with Drupal 10 and 11. It depends on Tamper and core’s Taxonomy module, and on Feeds Tamper if you are driving it from Feeds, which is the common case but not the only one: it is an ordinary Tamper plugin and works anywhere Tamper plugins run.

composer require drupal/feeds_tamper_term_hierarchy

The release exists because people kept filing issues against it. The autocreate option, the partial path matching, the Drupal 11 compatibility and the dependency cleanup were all reported, and in three cases implemented, by ethant, bbu23, longwave, damienmckenna and kazah. Their names are on the commits.

Drupal’s automation tools solve different problems. The harder question is how they can exchange work without weakening their execution models, permissions, or auditability.

Author: Will Huggins

In 2025, the Drupal AI Initiative launched with a clear vision: to establish Drupal as the premier open-source AI platform for digital experiences.

One year later, the market momentum is clear. What began as a highly focused working group has grown into a powerful ecosystem supported by 32 global partner organisations, over 50 active contributors, and over $1.5 million in committed funding. Most importantly, with the core AI technology now clocking up over 18,000 installs, organisations are actively building their next-generation marketing engines on Drupal.

For digital teams, AI presents a host of opportunities. The power to increase speed of production on one hand, while maintaining quality, consistency and governance on the other. Drupal is addressing this head-on by creating two dedicated product workstreams: Inside AI and Outside AI.

This blog post outlines what this means for your digital roadmap and how Drupal can help your digital marketing operations win in the age of AI.

"Inside AI" vs. "Outside AI"

As AI has evolved from chat boxes into autonomous, multi-step agents, digital leaders need a platform that does two things simultaneously: empowers human creators inside the browser and securely integrates with external marketing systems.

To accelerate our product roadmap, we have divided our day-to-day development into two specialised, business-focused tracks:

1. Inside AI

• The Core Value: Empowering your marketing and content teams.
• The Focus: This stream focuses on the tools built directly into the editorial interface to supercharge you digital experiences and campaign execution. It drives our visual page-building tools, in-product copy editors, translation modules, and the Context Control Center (CCC).
• The Goal: To eliminate the repetitive tasks and developer bottlenecks that slow down your marketing queue. Your team can take a campaign brief, generate a brand-consistent landing page, optimise it for SEO, and localise it for global audiences in seconds, all while keeping humans firmly in the loop to make the final publishing decisions.

2. Outside AI

• The Core Value: Make it easy for site builders and developers to use coding agents to build, interact with and migrate to Drupal.
• The Focus: This stream ensures that Drupal serves as a highly governed, secure production platform for websites, marketing systems, automation platforms (such as n8n or Activepieces), and external AI agents.
• The Goal: To position Drupal as the most reliable, secure, and structured backend for your wider digital stack. We are making it incredibly easy for external systems and autonomous agents to build and deploy using Drupal without introducing security, compliance, or governance risks.

Through this dual focus, we aim to make Drupal the most advanced, intuitive workspace for your marketing teams and content creators, as well as the most secure and connectable platform to build on.

What is Ready Now?

As you plan your digital product roadmaps and marketing strategies, here is a summary of exactly what is production-ready, what is ready for pilot testing, and what is on the horizon:

Live and Ready

These capabilities are fully stable, secure, and ready to drive immediate ROI in your production environments:

• Freedom of AI Choice: Drupal connects seamlessly with over 87 AI providers (including OpenAI, Anthropic, Gemini, Azure and Amazee.ai). You can swap models behind the scenes to optimise for cost, performance, or geographic data residency rules without rewriting any code.
• Creative & Editorial Assistants: Bounded, human-in-the-loop features like automated image alt-text generation, metadata auto-tagging, and initial copy drafting are ready to go. They act as immediate, built-in time savers for your editorial teams.
• AI Automators: Automate time consuming content management tasks like re-tagging all your content or turning PDF or word documents into accessible HTML pages - AI Automators are your CMS superpower!
• Brand & Data Guardrails: Advanced security filters that automatically sanitise sensitive customer data before it ever leaves for an external LLM, while validating incoming AI responses to ensure compliance and prevent "hallucinations" on your live site.

Ready for Beta Testing

These features are highly advanced and close to general availability. They are perfect for controlled pilot programs to gain a competitive edge:

• The Context Control Center (CCC): The brain of your brand. The CCC is a centralised space where you can define your brand voice, editorial style guides, target audience personas, and domain knowledge. This ensures that any AI-generated layout or copy sounds like your brand, rather than generic web text.
• Automated Translation & Multi-Step Campaigns: Workflows that automatically translate entire content libraries or combine multiple AI steps to generate structured assets while capturing local nuances and brand tone.
• Conversational Site Building: Tools that allow digital product owners and site builders to configure and lay out basic Drupal structures using natural language, drastically reducing initial setup times.
• Cost & Performance Tracking: Fully integrated with standard enterprise monitoring tools. You can track exact token usage, model costs, and AI activity in real time, protecting your marketing budget from unexpected bills.

Coming Soon 

One of the cutting-edge, experimental capabilities currently being refined in sandbox environments is Fully Autonomous Agents. These background agents are designed to analyse website performance, automatically propose layout optimisations to boost conversions, or build complex database queries entirely on their own.

Control and Governance

As a mature open-source platform, Drupal AI is structurally sovereign, model-agnostic, and transparently governed.
Whether you need to host open-source models locally to comply with strict regional privacy regulations or plug into the latest commercial LLMs for maximum speed, Drupal AI ensures you always own your data, your models, and your digital roadmap. We build trust directly into the architecture through branch-based content versioning, strict governance workflows, and deep audit trails.

Accelerate Your Roadmap

The Drupal AI Initiative is driving the future of open-source digital experience. If your marketing or digital product teams are ready to leverage the power of collaborative AI, try Drupal today.

Reusable Drupal components become awkward when each placement needs a different presentation. ERFO adds controlled variation without duplicating or altering the referenced content.

All security issues have been migrated from the older security.drupal.org site to our GitLab instance at git.drupalcode.org. This is the latest in a series of steps to improve Drupal’s coordinated vulnerability disclosure tools. We hope this will help in a few ways:

Merge requests for security issues will get automated testing to increase the quality of the releases. (Previously, tests for core security issues had to be triggered manually, and contrib testing was not available.)
GitLab has more automation to help with advisory creation, reducing manual work.
Powerful features like labels, commenting, and thread reviews on merge requests are now possible for security issues as well.

Here are some of the key steps we took:

• We started by evaluating a few solutions. We decided to use the GitLab instance on drupalcode.org.
• We planned how to remap and improve the current features from security.drupal.org and added some labels and automation to private issues on drupalcode.org.
• We made new security issue reporting default to git.drupalcode.org for several months. This helped us could gain confidence in the system, fix bugs, and make improvements.
• While that happened, Neil Drumm worked to create the migration process.
• The migration finally ran from July 9th to July 12th.

This work is possible because of support from the Drupal Association and is very appreciated.

We suppressed most emails during the migration, but a small number of people did get extra notification emails about issues, including old issues. We apologize for any resulting confusion.

How do I use GitLab to submit and manage security issues?

As before, security reports should be submitted by clicking the “Report a security vulnerability” link on the project page. If a project has already migrated public issues to git.drupalcode.org, you may also mark an issue confidential as you open it. The Security Team triages confidential issues for all covered projects.

For more information about how Drupal.org’s GitLab instance works, read our documentation.

You can read about the Security Team’s process in general. There is also a page dedicated to managing security issues on git.drupalcode.org. Those pages likely need updates, so please report any documentation issues in the Security Team Queue..

What do you think?

Let us know your thoughts. If you have feedback about how to further improve the Security Team process, you can file them in the Security Team Queue. If you have issues to report about the GitLab tooling itself on git.drupalcode.org, you can file them in the Drupal.org queue.

The old site does a redirect to the new location for issues and members of the Security Team can get content out of it if anyone notices items missing from the migration.

Thanks to longwave, hestenet, dokumori, drumm, and xjm for help in writing this post.

Panel access simplifies procurement but does not authorise a deployment. Agencies still need to review the assessment scope, findings, and residual risk against their intended use.

Panel access simplifies procurement but does not authorise a deployment. Agencies still need to review the assessment scope, findings, and residual risk against their intended use.

A new chapter for the Drupal Association - and why I want you in it Jürgen Haas Fri 17 Jul 2026 - 14:00

The Drupal Association is changing CEOs, and the community reacted with the intensity it usually reserves for controversy. Jürgen, who sent the DA a formal four-page letter of concern in May, makes the case for constructive engagement over outrage. Leadership means disappointing half the room on almost every decision - disagree with choices without turning decision-makers into enemies. The practical call to action is the 2026 board election. Become a member now to earn the right to vote. If you are already a member, vote. Show up on the quiet days, not only when the alarm goes off. A transition is rare - a moment where the direction is genuinely open.