The original problem behind this article is still common: you want Drupal to respect a taxonomy hierarchy in a custom View, not just dump flat term results. That sounds small, but on a live site it affects navigation, landing pages, editorial governance, and how easily visitors can move from broad topics into specific offers or content.
The first thing to say plainly is that Drupal 8 has been end-of-life since November 17, 2021. If you are still on Drupal 8, treat any hierarchy fix as a bridge, not a long-term architecture decision. The pattern still applies on modern Drupal, but the safest implementation choice in 2026 is usually simpler than the old forum and Stack Exchange workarounds suggest.
Start with the real requirement
In client projects, "show taxonomy hierarchy in Views" usually means one of three different jobs:
- Show content tagged with a parent term and its child terms.
- Render the taxonomy terms themselves in a visible parent/child tree.
- Filter by human-readable term names, or expose term depth for custom business logic.
Those are not the same build. If you treat them as one problem, you usually end up with a bloated View that is hard to debug and even harder to hand over to another team.
When core is enough
Drupal core taxonomy still supports hierarchical vocabularies, and for many category pages that is enough. If your goal is to list content under a parent category and include descendants, start with core and keep the model tight. Based on current Drupal.org module documentation, the core gap is not hierarchy itself; the gap is mostly when teams want nicer name-based filtering or extra depth metadata. In other words, core is often fine for ID-based taxonomy logic, and contributed modules are filling edge cases around it.
For business owners and operations leads, the practical rule is simple: use hierarchy only where it improves findability. A services taxonomy, resource library, location tree, or product family structure can help both users and editors. A messy tag cloud with five levels of nesting usually does the opposite.
- Use curated vocabularies for navigation-critical terms, not free tagging.
- Use term IDs or stable aliases as the canonical input for filtering, not raw term names that editors may rename later.
- Keep depth shallow unless there is a clear user need for deeper traversal.
- Check the real result count on large vocabularies before you call the job finished.
That keeps the hierarchy useful for search pages and landing pages without turning the View into a maintenance problem.
When custom code is the better answer
If you need to display the terms themselves in a true tree, custom code is often cleaner than forcing Views to simulate one. Drupal's taxonomy storage API gives you the right primitives for this. Core exposes loadTree() for pulling a vocabulary tree, and the returned items include depth information. Core also exposes parent and ancestor helpers such as loadParents() and loadAllParents().
$tree = \Drupal::entityTypeManager()
->getStorage('taxonomy_term')
->loadTree('categories', 0, NULL, TRUE);That is usually the right move when you want a sidebar tree, an index page, or a structured term browser. Build the hierarchy once in a controller, block, or preprocess layer, render it intentionally, and let Views handle the content listing separately. Agency teams generally find this easier to maintain than stacking groupings, relationships, and custom twig logic inside one giant View export.
It also gives you cleaner UX control. You can decide exactly how parents collapse, how active trails are highlighted, whether empty branches are hidden, and how much depth to expose on mobile versus desktop.
Useful contributed options in 2026
If core is close but not enough, two contributed modules are still worth knowing.
Views Taxonomy Term Name Depth is the more directly relevant one for Views work. Its current Drupal.org project page says it adds a contextual filter for taxonomy term names with depth and supports Drupal 9, 10, and 11. That makes it useful when the business requirement is tied to term names rather than term IDs.
composer require 'drupal/views_taxonomy_term_name_depth:^7.3'Use it carefully. Name-based filtering is convenient, but ID-based logic is still safer on multilingual sites, during rebrands, or anywhere editors regularly rename categories.
Taxonomy Term Depth is useful in a different way. Its current release line supports Drupal 10.3 and 11 and adds a stored depth value to taxonomy terms for code usage. That can be handy when templates, custom business rules, or exports need reliable depth data.
composer require 'drupal/taxonomy_term_depth:^3.0'What it is not is a magic switch that makes Views output a perfect hierarchy by itself. The project page is fairly explicit that better Views field, filter, and sort integration is still work in progress. So treat it as a support module for custom implementations, not a full tree-rendering solution.
What I would avoid
- Building new Drupal 8-only complexity on a production site that should already be on a supported core version.
- Using term names as the only source of truth for routing or filtering.
- Forcing one View to do both content retrieval and tree navigation if a small custom layer would be clearer.
- Publishing thin auto-generated taxonomy pages just because the hierarchy exists.
If this sits on a live marketing or lead-generation site, the best answer is usually boring in a good way: keep taxonomy clean, keep Views focused, and add a light custom tree renderer where the interface genuinely needs it. That gives editors a structure they can manage, gives visitors a clearer path through the site, and keeps future Drupal upgrades cheaper.
If you want a second pair of eyes on the vocabulary design, View configuration, or upgrade path, I can help map the smallest fix that improves structure without creating a long-term maintenance trap.
Need help with this kind of work?
Need a cleaner taxonomy setup or a safer Drupal upgrade plan? Greg can review the hierarchy, Views config, and lowest-maintenance way forward. Get in touch with Greg.