Explicit URL slugs

[srid]

In its current state, neuron infers the URL slug (/foo.html) directly from the note filename (./foo.md). When using title IDs (./Foo bar.md), however, its corresponding slug will have whitespace replaced by an underscore (/Foo_bar.html).

Now, the problem is that when you rename "Foo bar.md" to "Something else.md" (and change references elsewhere), the published URL would change too, which is generally not a good idea (for SEO, etc.)

One way to address this problem is to let the individual notes explicitly specific their URL slug, in the YAML metadata. So, for example, the "Foo bar.md" note would contain the following Markdown:

---
date: 2020-12-02
slug: foobar
---

Foo and bar are ...

The "slug" metadata field should instruct neuron to generate /foobar.html as output, whilst continue to use "Foo bar" as the zettel (title) ID and to allow [[Foo bar]] as the linking format. Neuron should also make sure that final slugs don't conflict with zettel IDs or with other slugs.

[hazelweakly]

How does this relate to the various ways to link things now? Does it enable having a URL that stays consistent but being able to rename the title without changing links? That is, given...

aff49fde.md with contents

---
date: 2020-12-02
slug: foobar
---

# Foo Bar Title

Foo and bar are ...

afc09fee.md with contents:

---
date: 2020-12-21
---

- [[Foo Bar Title]]
- [[aff49fde]]
- [A custom foobar title](./aff49fde.md)
- [[foobar]]

How do those all relate to each other and change if any one item changes?

• Foo Bar Title changed to New Foo Bar Title: url same, only the ``[Foo Bar Title]]` link in the list changed?
• foobar slug changed to foobar-concept slug: url changes, foobar link changes?
• etc

Is [[foobar]] even allowed?

[srid]

There seems to be some misunderstanding in your examples. Those two notes don't use title IDs (they use random IDs). You must link to it as [[aff49fde]]; and [[Foo Bar Title]] is a broken link, because there is no file named "Foo Bar Title.md".

Slugs and links have no relationship whatsoever. Links are still based on filenames. With this proposal, we provide an option to dissociation filenames from slugs.

So, conceptually, there are four things:

1. Filename
2. Zettel ID, is always the same as filename but without the extension
3. Link target, which is the same as Zettel ID (or filename if you using non-wikilinks)
4. Slug, which -- in its current state -- is the same as Zettel ID with whitespace replaced with underscore

In this proposal, we change (4) by making it overridable by the user at a per-note level. Slug is only used in publishing, in determining the .html filename (and for a links in the generated .html elsewhere).

[srid]

In short, changing the slug should not affect existing links in Markdown. Only renaming the filenames will (continue to) require you to change the linking references.

[srid]

Incidentally, this would also support using (auto-generated, during file creation) UUIDs as URL slugs, while still using human readable filenames (i.e., title IDs). As in:

---
slug: b158e635-3f22-4d8f-98b6-36976983e691
---

# Title ...

[hazelweakly]

Ok, great. That's what I thought; I should've clarified the links that I thought were broken.

Allowing overriding of the slug seems like a reasonable step to me.

[srid]

Example

• Source: https://github.com/srid/srid.ca/blob/master/imported/Linux%20logs%20from%20previous%20boot.md
• Published: https://www.srid.ca/last-boot-logs.html

Incidentally, I use a small script to manually sync that subset of my private Zettelkasten marked to be published.

[srid]

Implemented in master: #483