built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

i'm confused with this PR. "the alias resolves to the same simplified slug as the source" means you have the same alias as the file name?

In this case can you just remove the alias?

i'm confused with this PR. "the alias resolves to the same simplified slug as the source" means you have the same alias as the file name?

In this case can you just remove the alias?

There is an underlying issue with permalinks and aliases:

• Duplicate aliases cause issues.
• Setting the permalink to one of the aliases causes issues.
• Aliases pointing to an existing file cause issues.

I have made a PR in the past to align what a permalink is and what aliases are with Obsidian Publish, but they have since changed the definitions. What makes it worse is that what aliases are is not even consistent between Obsidian and Obsidian Publish.

Anyway, we should probably address the issue raised in the PR a little differently. Namely, we should de-duplicate the links we get from the frontmatter. So the combination of the note's path, the aliases of that note, and the permalink of that note should contain no duplicates.

i'm confused with this PR. "the alias resolves to the same simplified slug as the source" means you have the same alias as the file name?

In this case can you just remove the alias?

If the alias is the same as the file name, removing it would be simple. But there’s no reliable way to verify this, and if they do happen to match, the page ends up in an infinite redirect loop, making it completely inaccessible. That’s why I think it would be good to add a small safeguard to prevent this issue.

In my case, I accumulate the current file path in the aliases so that even if I rename or move the file, the old path remains accessible. Since this has to be recorded before the move happens, the file path and the slug can become the same — which is why I applied this patch.

Anyway, we should probably address the issue raised in the PR a little differently. Namely, we should de-duplicate the links we get from the frontmatter. So the combination of the note's path, the aliases of that note, and the permalink of that note should contain no duplicates.

This makes sense, but we will sacrifice build time then.

Anyway, we should probably address the issue raised in the PR a little differently. Namely, we should de-duplicate the links we get from the frontmatter. So the combination of the note's path, the aliases of that note, and the permalink of that note should contain no duplicates.

This makes sense, but we will sacrifice build time then.

To be fair, this check can be done in its entirely during the frontmatter parsing. So impact on build time is negligible.