On the surface it seems that only google and plausible scripts handle
the SPA correctly - but I don't know if maybe others handle
window.history API themselves somehow or something like that.
However, I am trying out goatcounter and in it's docs I see that it
does no special SPA handling, so this has to be fixed.
Just doing the dynamic script thing on every nav seems to do the trick.
The script is not "spa-preserve" so they wouldn't accumulate - and when
I tried the "spa-preserve" + call goatcounter api route it didn't quite
work, they actually did accumulate
With markdownLinkResolution: "shortest", aka "+/- how Obsidian does it"
and given pages A and nested/B which has an alias Z, if you try to link
from A using [[Z]] it wouldn't work and get 404.
This is caused by alias slugs (nested/Z in this case, emitted by
AliasRedirects) not being present in the `allSlugs` list which is used
by the link transformer.
The fix is to compute the alias slugs in the frontmatter transformer
and add them to `allSlugs` there.
Also we store them in file data to avoid recomputing them when emitting
alias redirect pages.
Fixes#904
Note: given how currently the markdown/html transformers are ordered
this doesn't really work.
Given pages A and nested/B which has an alias Z, here's the order which
currently happens:
md-transformers(A) => html-transformers(A) =>
md-transformers(B) => html-transformers(B)
Since the nested/Z slug will get added when md-transformers(B) are run,
but the slugs are used by html-transformers(A) when resolving it's
links - the link [[Z]] in A will still 404
A fix for this is to split the parser into two stages - first apply the
md-transformers to all files, and only then apply html-transformers to
all files.
I did just that in a different commit, which is needed for this one to
work correctly.
A final breadcrumb has an empty href, linking to the current page, but
the relative url normalization method missed those, making the link
appear broken in search previews and popovers.
Fixes#1690