mirror of
https://github.com/quartz-community/note-properties.git
synced 2026-07-22 02:50:26 +00:00
3539cf1e6a
Wikilinks appearing in frontmatter property strings (e.g. 'related: "[[My Note]]"') were rendered with their raw target passed directly to resolveRelative, leaving the space intact. The browser then percent-encoded it as %20 in the rendered href, producing broken links like './My%20Note' that never resolve. The root cause was in renderTextWithLinks (NoteProperties.tsx): the matched wikilink target went straight into resolveRelative without going through slugifyFilePath, so spaces, ampersands, and other characters that should be slugified survived into the href. extractLinksFromValue (transformer.ts) had the same issue: it stored raw target strings in file.data.frontmatterLinks instead of canonical slugs. Adds a shared slugifyWikilinkTarget helper in util/path.ts that mirrors the slug+anchor contract CrawlLinks uses for body-content links, so frontmatter wikilinks and body wikilinks now produce identical hrefs. Both NoteProperties.tsx and the transformer's extractLinksFromValue now go through this helper. Also replaces the plugin's local slugTag/slugifyFilePath/ getFileExtension helpers with the shared @quartz-community/utils versions. This eliminates slugification drift between plugins and ensures that note-properties honors the same case-insensitive matching that the rest of the Quartz ecosystem uses. BREAKING CHANGE: tag URLs and frontmatter-wikilink slugs are now lowercased (inherited from utils' case-insensitive matching). Tags #MyTag, #mytag, and #MYTAG collapse into a single tag page tags/mytag. |
||
|---|---|---|
| .. | ||
| frontmatterLinks.test.ts | ||
| slugifyWikilinkTarget.test.ts | ||
| slugTag.test.ts | ||