11ty Navigation Plugin: Computed Data Issues

Nov 13, 2025 by Admin 45 views

Navigating 11ty: Solving Computed Data Puzzles with the Navigation Plugin

Hey everyone! First off, massive props to the 11ty and Eleventy Navigation Plugin creators – this project is seriously awesome. Today, we're diving deep into a head-scratcher that many of you might bump into: the 11ty navigation plugin not working correctly with computed data. It’s one of those quirky issues that can leave you scratching your head, wondering if you’ve missed something obvious. But don’t worry, guys, we’ll break it down and figure it out together.

Imagine this scenario: you’ve got a neat directory structure for your 11ty site, with main posts and subfolders, each containing Markdown files and a helpful JSON file for frontmatter. It’s a super organized way to manage your content, right? You’ve got something like this:

post/
  post-1.md
  post-2.md
  index.md
  ...
  subfolder/
    otro-post.md
    index.md
    ...

And within each of these, you’re using a JSON file, let’s call it post.json, to inject some sweet frontmatter. This post.json looks something like this:

{
  "layout": "base.njk",
  "eleventyComputed": {
    "eleventyNavigation": {
      "key": "{{ title }}",
      "parent": "..."
    }
  }
}

Now, you’re trying to render your navigation using the magic of the Eleventy Navigation Plugin. You’ve got this code snippet in one of your Nunjucks files:

{{ collections.all | eleventyNavigation | eleventyNavigationToHtml | safe }}

But then… crickets. Nothing shows up. Nada. Zilch. This is where the frustration can really set in, right? You’ve followed the docs, you’ve set up your files, but the navigation just isn't appearing. It’s like the plugin is having a tiny tantrum and refusing to cooperate. You start to question everything: Is my collection set up right? Did I misspell something? Is the plugin even installed correctly?

The Computed Data Conundrum

The core of the issue often boils down to how the 11ty navigation plugin interacts with computed data. When you define eleventyNavigation within eleventyComputed, you’re telling Eleventy to calculate these values after the initial data processing. This is super powerful because it allows you to dynamically set navigation keys, parents, and other properties based on other data in your frontmatter, like the title in the example. However, plugins, including the Navigation Plugin, might process collections at a specific stage. If the plugin tries to access eleventyNavigation before eleventyComputed has had a chance to run and populate those values, you’re left with nothing.

This is precisely what happened in the scenario described. The user was seeing an empty navigation, indicating that the plugin wasn’t picking up the eleventyNavigation data. The initial thought, and a very common one in these situations, is that there's a problem with how computed properties are being handled. It’s a logical leap because computed properties are inherently dynamic, and sometimes, plugins can struggle if they expect static, pre-calculated data.

To really pinpoint the problem, the user did some crucial testing. They decided to bypass the plugin's automatic generation for a moment and manually loop through the collections.post. Inside the loop, they tried to access the title and eleventyNavigation.key directly:

<ul>
{%- for post in collections.post -%}
  <li>{{ post.data.title }} - {{ post.data.eleventyNavigation.key }}</li>
{%- endfor -%}
</ul>

And guess what? It worked! The titles and the eleventyNavigation.key were displayed exactly as expected. This was a game-changer because it proved that the data was present and was being calculated correctly within the Markdown files. The title was there, and crucially, post.data.eleventyNavigation.key was showing the computed value, like post-1, post-2, and so on. This piece of evidence was key because it shifted the suspicion away from the data itself and firmly onto the interaction between the Navigation Plugin and the computed data processing pipeline.

So, the data is there, it’s being computed, but the Navigation Plugin isn't seeing it when it generates the navigation structure. This strongly suggests that the timing of when the plugin reads the data versus when Eleventy computes it is the culprit. The plugin needs that eleventyNavigation data to be readily available when it’s doing its work of building the navigation tree.

Why the Discrepancy? Understanding Eleventy’s Processing Pipeline

To really nail this down, let’s chat about why this happens. Eleventy has a pretty sophisticated processing pipeline, and understanding its stages is key to unlocking these kinds of mysteries. When Eleventy builds your site, it goes through several steps: first, it reads your files, then it processes the data (including frontmatter and JSON data files), and then it runs any computed data properties. Finally, it renders your templates.

Here’s the kicker, guys: the Navigation Plugin often hooks into the collection processing stage. It looks at your collections and tries to find that sweet eleventyNavigation data to build its tree. The problem arises because, at the exact moment the plugin is peeking, the eleventyComputed properties haven’t necessarily run yet. Think of it like trying to get a guest list for a party before all the RSVPs have come in. You might have some names, but the final, accurate list isn't ready.

This is why the manual loop worked! When you did {%- for post in collections.post -%}, you were accessing the post items after Eleventy had finished its entire processing, including the computed data. The post.data.eleventyNavigation.key was populated and visible. But when collections.all | eleventyNavigation runs, it might be happening earlier in the pipeline, before those computed values are baked in.

So, the plugin isn't wrong, and your data isn't broken. It's a timing issue, a classic case of workflow mismatch. The plugin needs the data to be ready when it's ready, but computed properties change when that data becomes available.

Troubleshooting Steps: Getting Your Navigation Back on Track

Alright, so we know the problem is likely timing. How do we fix it? Don't sweat it, we've got a few tricks up our sleeves. The goal is to ensure the eleventyNavigation properties are available when the plugin needs them.

1. Adjusting `eleventyComputed` Timing (If Possible)

Sometimes, you might be able to influence when computed properties are evaluated. However, with the standard Eleventy setup and the Navigation Plugin, this is less about changing the plugin's internal timing and more about ensuring your data structure supports it. The key is often to have your eleventyNavigation properties not be solely dependent on eleventyComputed if you need them at the earliest collection processing stage. But in this specific case, the user wants to use computed properties for flexibility.

2. Using Data Files Strategically

Instead of relying solely on eleventyComputed for properties the navigation plugin needs immediately, consider putting some of that navigation data directly into your _data folder or your individual JSON data files. For example, if a navigation key or parent is static for most items, define it directly in post.json like this:

// post.json
{
  "layout": "base.njk",
  "eleventyNavigation": {
    "key": "{{ title }}" // Or a static value if computed isn't strictly needed here
  },
  "eleventyComputed": {
    "eleventyNavigation": {
      "parent": "..."
    }
  }
}

This way, the basic key is available earlier. However, the user's requirement was specifically to use eleventyComputed for the key, driven by the title. The issue is that {{ title }} itself might not be fully resolved when the navigation plugin first inspects.

3. Leveraging `eleventyNavigation` within `collections.all`

Let's re-examine the code snippet causing the issue:

{{ collections.all | eleventyNavigation | eleventyNavigationToHtml | safe }}

This line attempts to process collections.all. If your posts are specifically in a collection named post (as implied by your directory structure and the manual loop), it might be more reliable to target that specific collection:

{{ collections.post | eleventyNavigation | eleventyNavigationToHtml | safe }}

This change is subtle but important. The eleventyNavigation filter works best when applied to collections where items are correctly configured with eleventyNavigation data. If collections.all contains items that don't have this data (e.g., other types of pages), it could potentially confuse the filter or result in an incomplete navigation tree.

4. Ensuring Correct Data File Loading

Double-check that your post.json files are correctly recognized by Eleventy as data files associated with your Markdown files. Eleventy usually does this automatically based on naming conventions (e.g., post-1.md and post-1.json in the same directory). Make sure there are no typos in filenames or directory structures that could prevent this association.

5. Explicitly Defining `title` in Frontmatter

Since the eleventyNavigation.key is computed using {{ title }}, ensure that the title property is always explicitly defined in the frontmatter of your Markdown files, even for index.md files. If title is missing for any file, the computed key will be empty or undefined, breaking the chain.

Example index.md frontmatter:

--- 
title: "My Section Index"
layout: "base.njk"
eleventyNavigation:
  key: "{{ title }}"
  parent: "..."
---

And the corresponding index.json (if you're using it to override or supplement):

{
  "layout": "base.njk",
  "eleventyComputed": {
    "eleventyNavigation": {
      "key": "{{ title }}",
      "parent": "..."
    }
  }
}

Wait, if you're using both? That might be redundant! Let's clarify. If you put eleventyNavigation directly in the Markdown frontmatter like above, you might not need the eleventyComputed version in the JSON for the same properties. The JSON often overrides or merges with the frontmatter. The user's example showed eleventyComputed in the JSON. The core issue is still that {{ title }} within eleventyComputed might not be resolved early enough.

6. A Potential Workaround: Pre-computation or Different Structure

If the timing issue persists and you absolutely need computed values for navigation keys/parents, you might need to explore a slightly different approach. One idea is to perform a