Title: Local graph broken for non-ASCII URLs — getFullSlugFromUrl in @quartz-community/utils needs decodeURIComponent

[Carnia]

Description

The local graph view shows only a single node for pages with non-ASCII slugs (e.g., Chinese characters), even when the page has valid links. The global graph works correctly.

Root Cause

In graph.inline.ts, the function getSlugFromUrl() calls getFullSlugFromUrl() (imported from @quartz-community/utils), which internally uses window.location.pathname without decoding:

// @quartz-community/utils
export function getFullSlugFromUrl() {
  // uses window.location.pathname directly — no decodeURIComponent
}

// src/components/scripts/graph.inline.ts
function getSlugFromUrl() {
  var slug = getFullSlugFromUrl(); // returns percent-encoded path for non-ASCII
  var base = getBasePath();
  if (base && slug.startsWith(base.replace(/^\//, ""))) {
    slug = slug.slice(base.replace(/^\//, "").length);
    if (slug.startsWith("/")) slug = slug.slice(1);
  }
  return slug; // e.g. "%E5%85%B6%E4%BB%96/all-in-one/..." instead of "其他/all-in-one/..."
}

The browser percent-encodes non-ASCII characters in pathname, but the keys in contentIndex.json are decoded. The BFS traversal in the local graph renderer then fails to match the current page slug against the link data.

The fix should be applied in @quartz-community/utils's getFullSlugFromUrl(), not in the graph plugin itself.

Steps to Reproduce

1. Create two Markdown files with Chinese filenames that link to each other:
   • content/其他/1.md containing [[2]]
   • content/其他/2.md containing [[1]]
2. Build and serve the site
3. Navigate to either page — local graph shows only a single node
4. Click the global graph icon — global graph correctly shows both nodes and the edge

Expected Behavior

The local graph should show the current page and its directly linked neighbors.

Suggested Fix

Add decodeURIComponent() in getFullSlugFromUrl() within @quartz-community/utils:

export function getFullSlugFromUrl() {
  let slug = decodeURIComponent(window.location.pathname)
  // ... rest of the logic
}

[anyJohn]

Just leaving a note in case it helps unblock this — the underlying fix has already shipped in @quartz-community/utils, but the graph plugin's lockfile hasn't picked it up yet.

Root cause (same as the OP and #8)

getSlugFromUrl() seeds the local-graph slug from window.location.pathname via getFullSlugFromUrl(). The browser keeps pathname percent-encoded for non-ASCII / reserved characters, so for CJK slugs the seed slug arrives as e.g. ai/agent-%E4%BB%8E%E9%9B%B6... and never matches the already-decoded keys in static/contentIndex.json (ai/agent-从零开始/...). The BFS neighbourhood then collapses to just the current node, so the local graph renders a single dot.

The fix is already released in @quartz-community/utils 0.1.1

• commit d16d8d9 — fix: decode URI in getFullSlugFromUrl for non-ASCII slugs, which adds the missing decodeURI() call.
• Published to npm as @quartz-community/utils@0.1.1 (2026-07-24). 0.1.0 still reads window.location.pathname verbatim; 0.1.1 reads decodeURI(window.location.pathname).

So the graph-side decode proposed here (and in #7 / #11 / the now-closed #8) shouldn't be necessary once the graph plugin resolves utils ≥ 0.1.1.

Why it's still broken downstream

The graph plugin's committed package-lock.json still pins @quartz-community/utils to 0.1.0 (even on main, commit 4119714). npm install respects that lock, so the bundled graph script keeps pulling in the 0.1.0 getFullSlugFromUrl. Refreshing the lockfile (or bumping the dep range + re-locking) so the graph plugin consumes utils 0.1.1 should propagate the fix without any graph-source changes.

Repros: I confirmed against a live Quartz v5 site with CJK slugs — the deployed graph bundle's getFullSlugFromUrl is let u = window.location.pathname (no decodeURI); forcing utils 0.1.1 into the plugin build turns it into let u = decodeURI(window.location.pathname) and the local graph renders the full neighbourhood (~14 nodes for a page with 12 outgoing links).

Related: #2, #5, #7, #8, #11.

— Posted on behalf of anyJohn by their AI assistant.

[KinnariyaMamaTanha]

Confirming your diagnosis — this matches exactly what I saw on a Quartz v5 site with CJK slugs, and the lockfile pin is indeed the last mile. I verified locally that package.json allows ^0.1.0 (which would accept 0.1.1) but package-lock.json still resolves utils to 0.1.0, so a fresh clone keeps building against the un-decoded getFullSlugFromUrl.

I opened #12 which just does the lockfile refresh you suggested — bumps utils to ^0.1.1 and re-locks, no graph source changes. After that, a clean build emits decodeURI(window.location.pathname) and the local graph renders the full neighbourhood again. Thanks for the thorough write-up here, it made the fix easy to pin down.